I recently gave an internal talk at my work about the similarities of F# compared to JS. It was generally well received, and I would like to conver...
For further actions, you may consider blocking this person and/or reporting abuse
Nice article, flawed by quite a few minor grammar errors and spelling/typing mistakes - as in "Patern" in the Pattern Matching subtitle. As well, you don't mention the availability of the backwards pipe "<|" in the pipe/composition. Also, your description of List's, Array's, and Sequence's as somewhat equivalent to JavaScript List's isn't really correct. First, pure Sequence's have no memorization/storage unless used with Seq.cache, in which case they have a backing store of a growable DotNet List array (not the same as a F# List) or are generated from other forms of backing store such as List or Array by using "toSeq"; they also are quite execution time inefficient due to many nested function calls as they are implemented with DotNet iterators, nor are they able to be directly indexed in O(1) time as they can only have a particular index "chased" through the link chain. Secondly, F# List's are linked (non-lazy) lists and thus aren't memory use efficient as the link means they consume up to 50% memory overhead (for the case of a List of numbers) (They also shouldn't be used as if they were lazy lists as in Haskell since that can cause stack overflows). Thirdly, Array's are the most efficient in terms of execution and memory use for many uses as they are directly indexed regions of (heap) memory and can be equivalent to JavaScript primitive number array's for newer > ES5 JavaScript. Finally, it should be noted that JavaScript List's have a couple of uses - loosely equivalent to array's when numerically indexed, but more equivalent to a F# Map (actually more like a mutable hashed DotNet Dictionary) when associatively indexed by a non-numeric or sparsely indexed.
Thanks for the feedback Gordon
Wow fantastic addition! Thank you.
Awesome article, good thing you made it a blog! Small typo
List.distiNct. Woah never looked into async with fsharp, looks weird when compared to C#. I love how currying is integrated and composition is through operators, can’t wait for TC39 to move pipe operator into ES :). Thanks for writing this.Yes can't wait for the pipe operator to be in ES too, will be game changer!
Very nice write up, I was originally looking at F# when working for a client with .NET and it looked really wonderful especially the fabel compiler. However i settled on purescript because of things like HKTs though i wonder if you can simulate them in F# like in TS for example ?
those posts on thinking functionally and functional design are excellent :)
Apparently there are ways to simulate HKTs in F#, but seems to be beyond my knowledge on why HKTs are needed anyways. Maybe one day I will understand them.
Nice article. Even more than the other languages you listed, F# is based on OCaml. You might even say that it is OCaml for .NET + OO and C#-compatibility features.
Very nice!
Great article! I'm currently learning Elm and this was very interesting considering how similar it is to F#. Elm is a lot more minimal though. Thanks for the comparison to js too, of course :)
Elm is a great language for generating client side web pages and particularly good for learning programming (purely functionally) as it has greatly reduced complexity. However, due to the enforcement of this simplicity, it has some limitations that Fable (a F# transpiler to JavaScript) doesn't have and by using the Fable Elmish interface library for React, is almost as easy to use while providing much enhanced capabilities if one needs them.
Glad you liked it 🙂
"In F#, all functions are curried automatically". That's not right. F# equivalent should be
let add(x,y) = x + yThat looks like a function that takes one tuple as an argument and destructures it, and since JS does not really have tuples - it does not seem equivalent to me.
Especially since in F# you can do
let add(x,y)(z,a) = x + y + z + aBut correct me if I'm wrong.
Nice article. Thank you for sharing.
Might be worth adding a reference to anonymous records in the Records/Objects section: devblogs.microsoft.com/dotnet/anno... .