16 ms·

F# is gaining independence from .NET

212 points by sidcool 6y ago

29athrowaway 6y ago
F# is a great language, but the .NET community never embraced it.
- hvidgaard 6y ago
  It's a real shame, but not unexpected. The vast majority of programmers I meet in the wild simply do not have training in FP and by the time they decide to learn it (if they do), it's hard to unlearn "traditional" thinking. If we want to steer programming in that direction, we should teach functional programming before "traditional" programming. However, even if we manage to do that I'm not convinced that it will make a different. People think procedural and it seems that the abstraction of first order functions is hard.
  - catmanjan 6y ago
    As a .NET developer I don't see any reason to use F# professionally. C#/CPP are tools just like a hammer, F# is a different hammer, it doesn't seem to offer advantages in my field other than being different...
    - xupybd 6y ago
      The functional hammer can be a little easier to reason about. So you can understand your application a little more.
      - dleslie 6y ago
        It's possible to write functional C# code, as well.
        pharmakom 6y ago
        It’s possible but it’s just not the same.
        xupybd 6y ago
        Yeah you can. I find it a little more clunky. Many of the things I prefer are just syntactic sugar. But if I'm honest I really like syntactic sugar. On top of that I find functional first languages are great for forcing you to learn functional styles that you can later user in languages like C#. C# is a brilliant language and I wouldn't knock it. I'd use that as a first option at work but on a hobby project I'm going to play with F#.
        paavohtl 6y ago
        Ehh, not really. It depends on how you define functional programming. C# supports first class functions, tuples, some form of pattern matching and LINQ extensions support basic FP collection operations like map (Select), filter (Where) and fold (Aggregate). But I think that's just scratching the surface compared to a "real" FP language: - F# has function composition operators - F# functions are curried and support automatic partial application - F# variables and data structures are immutable by default - F# has powerful global HM type inference - F# uses option & result monads over exceptions and null - F# has algebraic data types with exhaustiveness checking These capabilities make writing code in F# a very different experience from C#. Some of these can be added to C# as features, but many things are fundamental parts of language design that are hard to change afterwards.
        dleslie 6y ago
        That stinks of microallocations from enormous stacks of closures, boxing and similar.
    - freeone3000 6y ago
      It allows you to envision your application as a series of data transforms, instead of a list of steps. This allows much more proximal abstractions for tasks involving data manipulation.
      - dleslie 6y ago
        You can treat your application as a series of data transforms with C#, as well.
        freeone3000 6y ago
        It's.. not as nice. LINQ gets halfway, but, you end up getting back to procedural modeling soon. With sufficient discipline and structure, and liberal use of LINQ and lambdas, you can mostly get there, but it lacks the purity of pure functional.
        dleslie 6y ago
        And in the process you've incurred a devastating amount of micro-allocations. When using Unity with an older version that doesn't have incremental GC this is a serious problem. Does F# avoid that?
        freeone3000 6y ago
        Oh, god no. Performance even on fairly trivial number crunching tasks is half of C#, nevermind anything where GC is important or you'd consider writing it native. It's not a performant language, that's not the point.
        moonchild 6y ago
        That's not a fundamental limitation, though. Implementations of SML (f# is effectively an ML implementation), OCaml, and Haskell are all quite performant.
    - sfg 6y ago
      https://ericsink.com/entries/fsharp_chasm.html https://ericsink.com/entries/fsharp_chasm.html
  - andi999 6y ago
    I think one problem is (was?) winforms is not available in f#. (which is c# unique selling point i. m. h. o.)
    - beyon 6y ago
      Are you thinking of something else than winforms? I believe winforms and WPF has always been usable but not with the visual designer tooling in visual studio. UWP has been trickier though to my knowledge.
      - andi999 6y ago
        I probaby meant the visual designer tooling. (Which is a big point in using Visual studio)
  - dleslie 6y ago
    I'm a long-time Emacs user, Scheme fan, functional programming advocate ... Who uses C# in his day job. For quite a long time F# simply wasn't ready, and by the time it was C# had already become an industry behemoth. But more critically, it's not a language that's officially supported by Unity. That's enough for it not to be a wise choice to be betting a project on it where there are dozens of jobs on the line, and families that could be impacted. I can't help but think that this concern isn't simply isolated to Unity software development; where else has the decision been made to not use F# on account of it not enjoying as much industry support as C#?
    - xupybd 6y ago
      I can't say that I've ever known anyone who uses Unity professionally but if that's your line of work it would be a big factor.
    - pjmlp 6y ago
      Sitecore, SharePoint, all the GUI designers for Forms, WPF, UWP, WinUI, EF (Core), WCF, gRPC, upcoming Code Generators.
  - dmitriid 6y ago
    I've done FP (several years of Erlang), and I use FP daily in my work (since most languages support FP to varying degrees). I see no point in F# other than "well, it's a nice-ish ML for .NET", and the article does nothing to help with that (file order? really? that's what you're going for as the first point to make about a language?) .
    - KurtMueller 6y ago
      Well, now it's also a "nice-ish ML" for javascript, thanks to Fable.
- zerr 6y ago
  Agree, although C# is constantly evolving.
  - foepys 6y ago
    That certainly is playing a huge part in it. C# is importing more and more F# features so people aren't really inclined to switch.
- lymitshn 6y ago
  Yep, wish JVM had it too, and no Scala doesn't count.
  - moonchild 6y ago
    Frege? (https://github.com/Frege/frege https://github.com/Frege/frege)
  - sideeffffect 6y ago
    Oh yes it does count. Scala can be a nice functional language, with a powerful module system. Although I miss type providers, enforced lack of cycles and other nice things, like syntax: https://contributors.scala-lang.org/t/scala-3-very-impressive-it-can-replace-python-i-think/4768/17 https://contributors.scala-lang.org/t/scala-3-very-impressiv...
- pjmlp 6y ago
  When the mothership makes all the shiny toys only for VB.NET, C# and C++, that is bound to happen.
ipiz0618 6y ago
The love for F# is justified because it's really a clean language with a well-defined core library. The one bad thing about it is that the documentation is really insufficient and confusing to people who don't already know .NET. If this improves it will definitely be welcome be more devs and companies.
- KurtMueller 6y ago
  I've spent the past 3 months or so working with F# with zero .net experience - I love the language alot but yeah, you will eventually end up learning C# (not that that's a bad thing) if you want to use its extensive and powerful ecosystem. If you look at the MS documentation for .net, none of the examples are in F#. I guess that's okay since it probably wouldn't be idiomatic F#... but still, the docs have examples in C#, VBA, and one other language (I think it might be C) but no examples in F#.
  - billfruit 6y ago
    Similar experience with Clojure, as well, one needs to know java to be reasonably productive with it.
    - cutler 6y ago
      I've been productive with Clojure for years and without needing anything from Java other than, say, a date library.
      - Scarbutt 6y ago
        Not everyone is writing toy personal projects.
xupybd 6y ago
I'm learning F# now. The language is nice but pulling dependencies into the interactive shell is proving difficult. After a few attempts I found I could use #r to pull in dependencies. Then I found where the NuGet packages were hiding in my home dir. Finally I could reference the Fsharp.Data.dll! Then XML type provider not found.... Frustrating when I just want to play around.
- orra 6y ago
  Cough: https://docs.microsoft.com/en-us/dotnet/fsharp/tools/fsharp-interactive/#referencing-packages-in-f-interactive https://docs.microsoft.com/en-us/dotnet/fsharp/tools/fsharp-... Should be a bit easier!
  - xupybd 6y ago
    Thank you! Gah lots to learn.
    - orra 6y ago
      :-). F# tooling (e.g IDE support) is infuriatingly not as good as C#. Yet at the same time, the tooling is pretty decent, especially for a functional language.
  - KurtMueller 6y ago
    I've been using F# 5.0's new features with dotnet interactive notebooks and the experience, when working correctly, is pretty nice. Dotnet interactive notebooks still has some rough edges to smooth out (and it's currently only available to VS Code Insiders) but, eventually, I think the new syntax coupled with dotnet interactive notebooks will make it a lot easier for people to try out F# and work through some problems/examples.
stinos 6y ago
I like F# a lot but never used it past toy projects. Are there open source examples of decent Elmish WPF based production applications?
rishav_sharan 6y ago
Love the idea behind the game engine for Xelmish https://github.com/ChrisPritchard/Xelmish https://github.com/ChrisPritchard/Xelmish Its made on top of monogame and should have a battle tested core. But the lack of knowledge/adoption for Xelmish is disappointing.
- freeqaz 6y ago
  Thanks for sharing this. I loved using XNA for many years!
have_faith 6y ago
> In F# the order of the files matter. I didn’t quite understand this section and it seems very counterintuitive can someone elaborate a little?
- danyx 6y ago
  In an F# project file (and thus also in all editor support), the referenced F# source files have an order. Files can only see types, values etc defined in files above them (and the same within files, with some caveats). This sounds really weird and annoying but turns out to have some surprising benefits (because it limits the mental/real search space for definitions as well). In practice it's just something that is surprising at first, then totally fine.
  - Kinrany 6y ago
    This guarantees that there are no cycles, but there are more ergonomic ways to do that. And the change would be backwards compatible. I wish languages didn't insist on preserving quirks like this one.
  - scns 6y ago
    That is pretty nice for testing, since it removes the need for depency injection, or am i mistaken?
    - ben509 6y ago
      All DI libraries can be ripped out and replaced with a bog standard main method, and it doesn't even require much skill. Most of what it's doing for you is stuff like "foo = new Foo(); bar = new Bar(foo, 33);" So there's no strict "need" for them, they help with (and enable) complexity. What F#'s aversion to cyclic dependencies does forces you to break cycles of types referring to types referring to types. The way you do that is by writing a generic function that avoids referring to a concrete type. Because it's generic, such a function is inherently easier to test by means of a simple stub value.
    - piaste 6y ago
adenozine 6y ago
If F# ever got something akin to Scala Native, or Kotlin Native, I think it'd do really well. In my limited understanding of the F# ecosystem, I don't believe there are a lot of voices calling towards a multiplatform future beyond the NET world. Fable is cool, but native is a must-have for a lot of people, myself included. The docs are bad but not inexcusably so, it's a nice project within MS, I get it. The underlying machinery leaks a little into the language, things like "discard" are irritating but not unforgivable. And it's not just running native, I know NET nerds will want to tell me about corert or native or whatever it's called, but that doesn't solve the issue. F# has a weak core, it's not like Clojure where I have this wide array to choose from regardless of the platform. I can choose NET or Fable and the development experience varies wildly between those two environments, in my limited experience. All in all, I think F# will live a medium-length life. Without solving the native problem and moving beyond NET, I don't see it flourishing in many important niches. If I was going to adopt a new language, it'd probably be Nim over F#, etc.
- cies 6y ago
  Isn't F# pretty much OCaml.NET? So if you want native, you may also go with OCaml (or ReasonML if you prefer curly-delimited code blocks). For frontend dev't I really like Elm lately. (the article makes many refs to Elmish, the Elm-on-F# project).
  - adenozine 6y ago
    Yes! Ocaml is quite good. Concurrency is kinda poor, but it's coming along. I am glad that Elm has influenced so many ecosystems. I wouldn't touch it with a ten foot pole because of the author, but I think the ideas of the project are invaluable and long overdue.
    - toolslive 6y ago
      concurrency is excellent in OCaml (Lwt, async, ....) it's just paralllelism that's a problem. multi core ocaml will eventually fix that.
amir734jj 6y ago
Parser combinator libraries written in F# are phenomenal. All these libraries can be used along side C# in a project. Yes, .NET developers haven't embraced F# but I love C# and hate over complicatedness of Haskell so using F# is a pure joy for me.
danyx 6y ago
I also like F# a lot and have used it professionally for 3 years now. I wrote down my own take on learning F# in a post "What I wish I knew when I learned F#" http://danielbachler.de/2020/12/23/what-i-wish-i-knew-when-learning-fsharp.html http://danielbachler.de/2020/12/23/what-i-wish-i-knew-when-l.... Maybe this is a helpful additional perspective for some.
- qwantim1 6y ago
  Would you have if it weren’t supported by Microsoft?
  - danyx 6y ago
    Sure, we used Elm as well. But it sometimes helps in getting buy-in that MS is behind F# to some degree.
- phillipcarter 6y ago
  This is an excellent blog post! Thanks for writing it.
JaggerJo 6y ago
Complaining about bad docs isn’t really fair IMHO. Compared to Swift F# has excellent documentation. Would be interesting to know what F# is compared with in this case. Is there a language thats known for excellent docs ? One thing you can’t pass on when talking about fsharp in the community. If you have a question just ask on twitter or slack. You’ll get an answer in minutes.
- 7331 6y ago
  > Is there a language thats known for excellent docs ? They're pretty good for PHP + Rust.
- Zababa 6y ago
  > Is there a language thats known for excellent docs ? In my experience the Rust docs are great, there's a good mix of types as documentation, high level explanations and examples, with easy access to the source code. Here's an example with the HashMap [1]. There's also the Rust Book [2], which is great because it provides beginners with somewhere to start (F# seems to currently lack this). The situation is pretty much the same with Elixir, great docs [3] and something to get people started [4]. [1]: https://doc.rust-lang.org/std/collections/struct.HashMap.html https://doc.rust-lang.org/std/collections/struct.HashMap.htm... [2]: https://doc.rust-lang.org/book/ https://doc.rust-lang.org/book/ [3]: https://hexdocs.pm/elixir/List.html https://hexdocs.pm/elixir/List.html [4]: https://elixir-lang.org/getting-started/introduction.html https://elixir-lang.org/getting-started/introduction.html
- dnautics 6y ago
  Is there a language thats known for excellent docs ? Elixir. Main docs: https://hexdocs.pm/elixir/Kernel.html https://hexdocs.pm/elixir/Kernel.html Here's a (3rd party) library's docs. I recommend also checking out "guides" in the upper left corner: https://hexdocs.pm/oban/Oban.html https://hexdocs.pm/oban/Oban.html
- Smaug123 6y ago
  > Is there a language that's known for excellent docs ? Mathematica's documentation is extremely good (reference.wolfram.com).
toolslive 6y ago
Since they came out, I've been craving type providers like Smeagol The Ring.
notretarded 6y ago
More leetcode trash. If you're not using a functional programming language you're "doing it rong". Still yet to see practical advantages of using F# which don't result in convoluted, abstruse code... besides unit conversion for a calculator app
DanielBMarkham 6y ago
"...If you are sold with F# there is one important point to highlight. Do not treat F#, just another language with different syntax especially if you are familiar with Python, Ruby, JavaScript, C#, etc. You have to embrace functional programming as a paradigm...." I want to provide a little nuance around this, because I'd give the opposite advice. Because F# is based on OCAML and an extremely popular IDE/framework, it is first and foremost a teaching language. In my opinion, for what it's worth, the biggest mistake other F# coders make is running off into Haskell-land and trying to drag the rest of the community with them. Yes, pure FP is love and goodness, joy and love, but that's not the place to start with your average coder who just wants to see what's cool. Fable and Elmish are I learned functional programming by reading a lot of OCAML books and the only(!) F# book out at the time. I coded like shit. I couldn't help it; I came from a strong OO background. But then I figured out that instead of coding everything perfectly, it was more important to finish a little bit at a time, then take a look at functional smells, things like mutation. Sometimes I could fix these smells, sometimes I couldn't. Over time I found I could fix all of them. At that point I was a functional programmer. I love these high-level F# frameworks, and like I said it's the best way to get folks involved, but wow, folks are going to create some programming disasters using them. Yes, this happens all the time withe every new thing, but functional messes are an order-of-magnitude worse than imperative/OO ones. Good luck, guys! The destination is worth the journey.
- pydry 6y ago
  >functional messes are an order-of-magnitude worse than imperative/OO ones Why so?
  - DanielBMarkham 6y ago
    Symbol/Semantic leakage. In imperative/OO, I'm organizing as I go using well-established and understood paradigms. In functional programming, you're making these paradigms as you go along, or at least you should be. If you come in with an "I'm going to kick some ass by making these classes to solve my problem" attitude, you're already headed down the OO track whether you realize it or not. Then, sure as night follows day, you or somebody else starts using a functional paradigm, say HoF. There's nothing wrong with any of that. As a professional, you want to be good in multiple paradigms. The problem is that you're mixing them all up, whether you realize it or not (Most of the time, programmers don't realize it) And now, every piece of code can go down two entirely separate tracks as you suss out your architecture. Not only is that not going to work, it's going to make debugging and maintenance a nightmare. This is very, very similar to how good C++ shops work. You've got to tightly limit the way you solve problems in order for all of the programmers involved to be to reason about the code.
yen223 6y ago
Are there any startups or companies using F# in production?
- Weebs 6y ago
  As others have alluded to, it's more common in FinTech (ex: Jane Street and Quicken Loans). There also seems to be a number of front end devs using Fable + React.
- reverseblade2 6y ago
  This one does https://resoptima.com/ https://resoptima.com/
- JackMorgan 6y ago
  I just left a team that was using F# as our language for all new code. We built shrinkwrap banking software and found it a much better alternative to C#. We were the market leaders in that space, most of the worlds big banks runs code we wrote in F#. I think F# is an improvement to C# just like how C# was an improvement to VB.NET, which was an improvement to VB6. However, it's not really a hill I'd die on, frankly new co-workers complaining about missing curly braces gets really old after the first day. Ultimately most programmers just don't care about using the best tools, and would still be happy using VB6 if the industry as a whole hadn't moved them along kicking and screaming into C#. If I'm working alone, I'll choose the best tools for the job, and I tend to think F# in modern dotnet core is one of the best tools for backend servers out there. It's much more coherent then Scala, less mushy at large codebase size than Clojure, very performant, and has great libraries like aspnet core, and compiles so much faster than Haskell and has an incredible wealth of better libraries. I also prefer a more functional style than Kotlin, Go, Java, or C# provide, because for me that means fewer unit tests to get the same confidence. There's plenty annoying with the language, but it's a great hybrid with reasonable tradeoffs. My elevator pitch typically is: with F# I need to write fewer unit tests to get the same confidence I'd need elsewhere, and that means more time programming.
- decafninja 6y ago
  Jet did, but they're now dead...or do they still live on inside of the greater Walmart (Labs?) organization?
FpUser 6y ago
>"You have to embrace functional programming as a paradigm." Why would I embrace/commit to any particular paradigms? I would use whatever I believe is best suitable for particular task. All those are just tools like a screwdriver. They're here to work for us, not the other way around.
- reverseblade2 6y ago
  Sure, but functional programming requires some discipline and restrictions for a greater good. It's certainly a choice though.
  - FpUser 6y ago
    >"Sure, but functional programming requires some discipline and restrictions for a greater good" I do not care about some generic "greater good". It does not exist. In my context "greater good" is delivering products while satisfying business and technical constraints of a given customer/s to a reasonable degree.
gdsdfe 6y ago
F# on the JVM would be a game changer
- Scramblejams 6y ago
  I think the same thing about F# on Golang, for those tasks where GC latency matters.
josteink 6y ago
> As you can see FSF offers mentorship programs That made me blink. And then I found out they meant the F# software foundation, not the Free software foundation. It seems like a very obvious misunderstanding to make, and IMO they should avoid causing it by using another abbreviation than this one which is already very well established in programming circles.
- reverseblade2 6y ago
  I guess they don't. It's my mistake and I have just fixed it.
jayonsoftware1 6y ago
Is their a good F# book that will teach functional programing. Every F# book i see are trying to teach the syntax.
- reverseblade2 6y ago
  I am the author of the post and author of this https://www.udemy.com/course/learning-functional-programming-with-f/ https://www.udemy.com/course/learning-functional-programming... Don't be deceived by low rating. It's low because people expected a course on syntax. Also other continuations are as below: https://www.udemy.com/course/functional-application-designing/ https://www.udemy.com/course/functional-application-designin... https://www.udemy.com/course/end-to-end-real-world-application-development-with-f/ https://www.udemy.com/course/end-to-end-real-world-applicati... And if you have any questions find me from @OnurGumusDev on twitter and I will gladly help
  - jayonsoftware1 6y ago
    Thanks. Bought the course. Looking forward to learning.
- KurtMueller 6y ago
  F# For Fun and Profit has a lot of blog posts on how to think functionally and how to use F# for domain modeling. Compositional IT has a lot of good blog posts on how they use F# to solve real world problems. Kit Eason's Stylish F# is a good book.
- deleted 6y ago
  [deleted]
kingdomcome50 6y ago
Okay. I don't want to go too far off topic here but the OP is about F# so I'm certain many enthusiasts will be here, and I have been waiting for this moment to get an answer to a very specific question regarding Elmish: What is the point of the Elm architecture? I cannot figure out why the `model`, `view`, `update` architecture is preferable to its OOP counterpart. That is, simply defining an interface for each of the above where `IView` and `IUpdate` each contain a single method with the appropriate parameters. That is objectively[0] cleaner! The current recommendation is to create these ungodly unions for handling the view/update logic. It feels ridiculous and really starts to gum up your modules with implementation logic that is _entirely_ unrelated. FP and OOP each provide different (opposite) faculties when dealing with the expression problem. FP says[1], "I want to optimize for adding new _behavior_ to the same pieces of data" (one can add functions that operate on the same data without needing to recompile). OOP says[2], "I want to optimize for adding new _data_ with the same kinds of behavior" (one can add classes encapsulating different data that have the same operations without needing to recompile). How does the above square with an architecture built around a set of _single_ functions that operate on different (changing) pieces of data? The Elm architecture seems to have chosen the exact wrong paradigm (and its associated semantics) for optimizing change! You aren't adding behavior as you build out your application in this architecture. You are adding _data_! The "behavior" is defined exactly one time (in the signatures of the `view` and `update` functions) and doesn't change. I must be missing something... is this really just so we can say "the complier will let us know if we forgot to handle a case"? That seems like a pretty hefty trade-off if you ask me. F# has this beautiful multi-paradigm capability and, in this case, it's been woefully ignored. [0] Okay fine maybe not objectively, but it certainly seems preferable to modularize this logic. [1][2] I get it. They don't actually say anything, but the general approach to the EP remains true for most cases.
- reverseblade2 6y ago
  OP here, it's a great question indeed! Now let's forget about elm/elmish but we are to write a stateful application. It doesn't have to be a web app, just any application needs to hold some state. And that state should be modifiable (Not to mention we will have side-effects as well.) in order to do something useful but we also want to stay on the Functional programming realm to get benefit from things like immutability and other functional goodies. So you see these two goals are contradictory. How FP tackles this state problem? One solution is to use actors and agents. And that's precisely what elmish is. Unlike the conventional apps where you mutate the state directly, an agent in F# is a recursive call which can await for further messages. So just like Flip Flop holds the state in memory, an agent hold the state in a recursive function. And how is this connected to elmish? Let's see how elmish v2 is implemented: https://github.com/elmish/elmish/blob/5330f52153d5181923bb3cb065436748dc38231e/src/program.fs#L90 https://github.com/elmish/elmish/blob/5330f52153d5181923bb3c... You can see an agent there and that's the core of elmish. So basically elm and elmish is a way to handle state changes in a functional manner along with side effect support via commands. I cannot emphasis importance of elmish, because not only it helps for isolating the state functionally but it helps you to keep your business logic separate from UI. So you don't end up messing your code like you use React hooks or context.
ilaksh 6y ago
How does this compare to BuckleScript or Reason?
- KurtMueller 6y ago
  Both BuckleScript and Reason target javascript and Reason Native targets mobile as well. F# targets .net, javascript, and the Xamarin library targets mobile (although I haven't tried it yet). They're all typed ml languages.
  - ilaksh 6y ago
    I know all of that. Obviously I was asking about using F# to create web applications versus using BuckleScript or Reason.
- francisl 6y ago
  The equivalent is fable [1]. The major difference I would say, is that you are required to use botnet alongside of node. (dotnet to compile to JS, then node to bundle with wepback or anything else) Also, you can use the same language to build high performance backend with giraffe [2] (better than node). And build performant native application with fabulous [3]. There is an experimental typescript compilation. Which will be great, because it will make using F# less hostile in an environment where the winner takes all. [1] https://fable.io https://fable.io [2] https://github.com/giraffe-fsharp/Giraffe https://github.com/giraffe-fsharp/Giraffe [3] https://fsprojects.github.io/Fabulous https://fsprojects.github.io/Fabulous
karmakaze 6y ago
I've played with F#, OCaml, Haskell, Scala and Clojure. F# was by far the 'sweet spot' for me in terms of being able to translate my thoughts into a working functionally structured program. I hope many more are exposed to F# and that the good first experience is the norm (not currently from my experience).
- KurtMueller 6y ago
  Me too :). I think it hits the sweet spot for me between being as readable, expressive, and low ceremony as Ruby/Python but also type safe.
  - karmakaze 6y ago
    And the trade-off of type inference and 'you have to hint here' vs compile speed is also well worth it. Like other comments here, I usually add local names or types to signatures 'for readability' (esp. to future me).
Shadonototro 6y ago
it doesn't matter, it can't compile to a native executable just like C#, it's dotnet after all, same engine
boxed 6y ago
I am writing some elm now and I'm not extremely happy. How does elmish compare in practice? Elm has very good error messages and is mostly fast but it's also annoyingly limited.
dang 6y ago
Related from 2 months ago: https://news.ycombinator.com/item?id=25305650 https://news.ycombinator.com/item?id=25305650 2017 https://news.ycombinator.com/item?id=15578592 https://news.ycombinator.com/item?id=15578592 2016 https://news.ycombinator.com/item?id=11771266 https://news.ycombinator.com/item?id=11771266
Scramblejams 6y ago
I learn a lot by reading others' code. Can anyone recommend a a project or two that is small enough for a newcomer to wrap their minds around, that also exemplifies what makes a high quality F# codebase?

212 points by sidcool 6y ago

29athrowaway 6y ago

F# is a great language, but the .NET community never embraced it.

hvidgaard 6y ago
It's a real shame, but not unexpected. The vast majority of programmers I meet in the wild simply do not have training in FP and by the time they decide to learn it (if they do), it's hard to unlearn "traditional" thinking. If we want to steer programming in that direction, we should teach functional programming before "traditional" programming. However, even if we manage to do that I'm not convinced that it will make a different. People think procedural and it seems that the abstraction of first order functions is hard.
- catmanjan 6y ago
  As a .NET developer I don't see any reason to use F# professionally. C#/CPP are tools just like a hammer, F# is a different hammer, it doesn't seem to offer advantages in my field other than being different...
  - xupybd 6y ago
    The functional hammer can be a little easier to reason about. So you can understand your application a little more.
    - dleslie 6y ago
      It's possible to write functional C# code, as well.
      - pharmakom 6y ago
        It’s possible but it’s just not the same.
      - xupybd 6y ago
        Yeah you can. I find it a little more clunky. Many of the things I prefer are just syntactic sugar. But if I'm honest I really like syntactic sugar. On top of that I find functional first languages are great for forcing you to learn functional styles that you can later user in languages like C#. C# is a brilliant language and I wouldn't knock it. I'd use that as a first option at work but on a hobby project I'm going to play with F#.
      - paavohtl 6y ago
        Ehh, not really. It depends on how you define functional programming. C# supports first class functions, tuples, some form of pattern matching and LINQ extensions support basic FP collection operations like map (Select), filter (Where) and fold (Aggregate). But I think that's just scratching the surface compared to a "real" FP language: - F# has function composition operators - F# functions are curried and support automatic partial application - F# variables and data structures are immutable by default - F# has powerful global HM type inference - F# uses option & result monads over exceptions and null - F# has algebraic data types with exhaustiveness checking These capabilities make writing code in F# a very different experience from C#. Some of these can be added to C# as features, but many things are fundamental parts of language design that are hard to change afterwards.
        dleslie 6y ago
        That stinks of microallocations from enormous stacks of closures, boxing and similar.
  - freeone3000 6y ago
    It allows you to envision your application as a series of data transforms, instead of a list of steps. This allows much more proximal abstractions for tasks involving data manipulation.
    - dleslie 6y ago
      You can treat your application as a series of data transforms with C#, as well.
      - freeone3000 6y ago
        It's.. not as nice. LINQ gets halfway, but, you end up getting back to procedural modeling soon. With sufficient discipline and structure, and liberal use of LINQ and lambdas, you can mostly get there, but it lacks the purity of pure functional.
        dleslie 6y ago
        And in the process you've incurred a devastating amount of micro-allocations. When using Unity with an older version that doesn't have incremental GC this is a serious problem. Does F# avoid that?
        freeone3000 6y ago
        Oh, god no. Performance even on fairly trivial number crunching tasks is half of C#, nevermind anything where GC is important or you'd consider writing it native. It's not a performant language, that's not the point.
        moonchild 6y ago
        That's not a fundamental limitation, though. Implementations of SML (f# is effectively an ML implementation), OCaml, and Haskell are all quite performant.
  - sfg 6y ago
    https://ericsink.com/entries/fsharp_chasm.html https://ericsink.com/entries/fsharp_chasm.html
- andi999 6y ago
  I think one problem is (was?) winforms is not available in f#. (which is c# unique selling point i. m. h. o.)
  - beyon 6y ago
    Are you thinking of something else than winforms? I believe winforms and WPF has always been usable but not with the visual designer tooling in visual studio. UWP has been trickier though to my knowledge.
    - andi999 6y ago
      I probaby meant the visual designer tooling. (Which is a big point in using Visual studio)
- dleslie 6y ago
  I'm a long-time Emacs user, Scheme fan, functional programming advocate ... Who uses C# in his day job. For quite a long time F# simply wasn't ready, and by the time it was C# had already become an industry behemoth. But more critically, it's not a language that's officially supported by Unity. That's enough for it not to be a wise choice to be betting a project on it where there are dozens of jobs on the line, and families that could be impacted. I can't help but think that this concern isn't simply isolated to Unity software development; where else has the decision been made to not use F# on account of it not enjoying as much industry support as C#?
  - xupybd 6y ago
    I can't say that I've ever known anyone who uses Unity professionally but if that's your line of work it would be a big factor.
  - pjmlp 6y ago
    Sitecore, SharePoint, all the GUI designers for Forms, WPF, UWP, WinUI, EF (Core), WCF, gRPC, upcoming Code Generators.
- dmitriid 6y ago
  I've done FP (several years of Erlang), and I use FP daily in my work (since most languages support FP to varying degrees). I see no point in F# other than "well, it's a nice-ish ML for .NET", and the article does nothing to help with that (file order? really? that's what you're going for as the first point to make about a language?) .
  - KurtMueller 6y ago
    Well, now it's also a "nice-ish ML" for javascript, thanks to Fable.
zerr 6y ago
Agree, although C# is constantly evolving.
- foepys 6y ago
  That certainly is playing a huge part in it. C# is importing more and more F# features so people aren't really inclined to switch.
lymitshn 6y ago
Yep, wish JVM had it too, and no Scala doesn't count.
- moonchild 6y ago
  Frege? (https://github.com/Frege/frege https://github.com/Frege/frege)
- sideeffffect 6y ago
  Oh yes it does count. Scala can be a nice functional language, with a powerful module system. Although I miss type providers, enforced lack of cycles and other nice things, like syntax: https://contributors.scala-lang.org/t/scala-3-very-impressive-it-can-replace-python-i-think/4768/17 https://contributors.scala-lang.org/t/scala-3-very-impressiv...
pjmlp 6y ago
When the mothership makes all the shiny toys only for VB.NET, C# and C++, that is bound to happen.

ipiz0618 6y ago

The love for F# is justified because it's really a clean language with a well-defined core library. The one bad thing about it is that the documentation is really insufficient and confusing to people who don't already know .NET. If this improves it will definitely be welcome be more devs and companies.

KurtMueller 6y ago
I've spent the past 3 months or so working with F# with zero .net experience - I love the language alot but yeah, you will eventually end up learning C# (not that that's a bad thing) if you want to use its extensive and powerful ecosystem. If you look at the MS documentation for .net, none of the examples are in F#. I guess that's okay since it probably wouldn't be idiomatic F#... but still, the docs have examples in C#, VBA, and one other language (I think it might be C) but no examples in F#.
- billfruit 6y ago
  Similar experience with Clojure, as well, one needs to know java to be reasonably productive with it.
  - cutler 6y ago
    I've been productive with Clojure for years and without needing anything from Java other than, say, a date library.
    - Scarbutt 6y ago
      Not everyone is writing toy personal projects.

xupybd 6y ago

I'm learning F# now. The language is nice but pulling dependencies into the interactive shell is proving difficult. After a few attempts I found I could use #r to pull in dependencies. Then I found where the NuGet packages were hiding in my home dir. Finally I could reference the Fsharp.Data.dll! Then XML type provider not found.... Frustrating when I just want to play around.

orra 6y ago
Cough: https://docs.microsoft.com/en-us/dotnet/fsharp/tools/fsharp-interactive/#referencing-packages-in-f-interactive https://docs.microsoft.com/en-us/dotnet/fsharp/tools/fsharp-... Should be a bit easier!
- xupybd 6y ago
  Thank you! Gah lots to learn.
  - orra 6y ago
    :-). F# tooling (e.g IDE support) is infuriatingly not as good as C#. Yet at the same time, the tooling is pretty decent, especially for a functional language.
- KurtMueller 6y ago
  I've been using F# 5.0's new features with dotnet interactive notebooks and the experience, when working correctly, is pretty nice. Dotnet interactive notebooks still has some rough edges to smooth out (and it's currently only available to VS Code Insiders) but, eventually, I think the new syntax coupled with dotnet interactive notebooks will make it a lot easier for people to try out F# and work through some problems/examples.

stinos 6y ago

I like F# a lot but never used it past toy projects. Are there open source examples of decent Elmish WPF based production applications?

rishav_sharan 6y ago

Love the idea behind the game engine for Xelmish https://github.com/ChrisPritchard/Xelmish https://github.com/ChrisPritchard/Xelmish Its made on top of monogame and should have a battle tested core. But the lack of knowledge/adoption for Xelmish is disappointing.

freeqaz 6y ago
Thanks for sharing this. I loved using XNA for many years!

have_faith 6y ago

> In F# the order of the files matter. I didn’t quite understand this section and it seems very counterintuitive can someone elaborate a little?

danyx 6y ago
In an F# project file (and thus also in all editor support), the referenced F# source files have an order. Files can only see types, values etc defined in files above them (and the same within files, with some caveats). This sounds really weird and annoying but turns out to have some surprising benefits (because it limits the mental/real search space for definitions as well). In practice it's just something that is surprising at first, then totally fine.
- Kinrany 6y ago
  This guarantees that there are no cycles, but there are more ergonomic ways to do that. And the change would be backwards compatible. I wish languages didn't insist on preserving quirks like this one.
- scns 6y ago
  That is pretty nice for testing, since it removes the need for depency injection, or am i mistaken?
  - ben509 6y ago
    All DI libraries can be ripped out and replaced with a bog standard main method, and it doesn't even require much skill. Most of what it's doing for you is stuff like "foo = new Foo(); bar = new Bar(foo, 33);" So there's no strict "need" for them, they help with (and enable) complexity. What F#'s aversion to cyclic dependencies does forces you to break cycles of types referring to types referring to types. The way you do that is by writing a generic function that avoids referring to a concrete type. Because it's generic, such a function is inherently easier to test by means of a simple stub value.
  - piaste 6y ago

adenozine 6y ago

If F# ever got something akin to Scala Native, or Kotlin Native, I think it'd do really well. In my limited understanding of the F# ecosystem, I don't believe there are a lot of voices calling towards a multiplatform future beyond the NET world. Fable is cool, but native is a must-have for a lot of people, myself included. The docs are bad but not inexcusably so, it's a nice project within MS, I get it. The underlying machinery leaks a little into the language, things like "discard" are irritating but not unforgivable. And it's not just running native, I know NET nerds will want to tell me about corert or native or whatever it's called, but that doesn't solve the issue. F# has a weak core, it's not like Clojure where I have this wide array to choose from regardless of the platform. I can choose NET or Fable and the development experience varies wildly between those two environments, in my limited experience. All in all, I think F# will live a medium-length life. Without solving the native problem and moving beyond NET, I don't see it flourishing in many important niches. If I was going to adopt a new language, it'd probably be Nim over F#, etc.

cies 6y ago
Isn't F# pretty much OCaml.NET? So if you want native, you may also go with OCaml (or ReasonML if you prefer curly-delimited code blocks). For frontend dev't I really like Elm lately. (the article makes many refs to Elmish, the Elm-on-F# project).
- adenozine 6y ago
  Yes! Ocaml is quite good. Concurrency is kinda poor, but it's coming along. I am glad that Elm has influenced so many ecosystems. I wouldn't touch it with a ten foot pole because of the author, but I think the ideas of the project are invaluable and long overdue.
  - toolslive 6y ago
    concurrency is excellent in OCaml (Lwt, async, ....) it's just paralllelism that's a problem. multi core ocaml will eventually fix that.

amir734jj 6y ago

Parser combinator libraries written in F# are phenomenal. All these libraries can be used along side C# in a project. Yes, .NET developers haven't embraced F# but I love C# and hate over complicatedness of Haskell so using F# is a pure joy for me.

danyx 6y ago

I also like F# a lot and have used it professionally for 3 years now. I wrote down my own take on learning F# in a post "What I wish I knew when I learned F#" http://danielbachler.de/2020/12/23/what-i-wish-i-knew-when-learning-fsharp.html http://danielbachler.de/2020/12/23/what-i-wish-i-knew-when-l.... Maybe this is a helpful additional perspective for some.

qwantim1 6y ago
Would you have if it weren’t supported by Microsoft?
- danyx 6y ago
  Sure, we used Elm as well. But it sometimes helps in getting buy-in that MS is behind F# to some degree.
phillipcarter 6y ago
This is an excellent blog post! Thanks for writing it.

JaggerJo 6y ago

Complaining about bad docs isn’t really fair IMHO. Compared to Swift F# has excellent documentation. Would be interesting to know what F# is compared with in this case. Is there a language thats known for excellent docs ? One thing you can’t pass on when talking about fsharp in the community. If you have a question just ask on twitter or slack. You’ll get an answer in minutes.

7331 6y ago
> Is there a language thats known for excellent docs ? They're pretty good for PHP + Rust.
Zababa 6y ago
> Is there a language thats known for excellent docs ? In my experience the Rust docs are great, there's a good mix of types as documentation, high level explanations and examples, with easy access to the source code. Here's an example with the HashMap [1]. There's also the Rust Book [2], which is great because it provides beginners with somewhere to start (F# seems to currently lack this). The situation is pretty much the same with Elixir, great docs [3] and something to get people started [4]. [1]: https://doc.rust-lang.org/std/collections/struct.HashMap.html https://doc.rust-lang.org/std/collections/struct.HashMap.htm... [2]: https://doc.rust-lang.org/book/ https://doc.rust-lang.org/book/ [3]: https://hexdocs.pm/elixir/List.html https://hexdocs.pm/elixir/List.html [4]: https://elixir-lang.org/getting-started/introduction.html https://elixir-lang.org/getting-started/introduction.html
dnautics 6y ago
Is there a language thats known for excellent docs ? Elixir. Main docs: https://hexdocs.pm/elixir/Kernel.html https://hexdocs.pm/elixir/Kernel.html Here's a (3rd party) library's docs. I recommend also checking out "guides" in the upper left corner: https://hexdocs.pm/oban/Oban.html https://hexdocs.pm/oban/Oban.html
Smaug123 6y ago
> Is there a language that's known for excellent docs ? Mathematica's documentation is extremely good (reference.wolfram.com).

toolslive 6y ago

Since they came out, I've been craving type providers like Smeagol The Ring.

notretarded 6y ago

More leetcode trash. If you're not using a functional programming language you're "doing it rong". Still yet to see practical advantages of using F# which don't result in convoluted, abstruse code... besides unit conversion for a calculator app

DanielBMarkham 6y ago

"...If you are sold with F# there is one important point to highlight. Do not treat F#, just another language with different syntax especially if you are familiar with Python, Ruby, JavaScript, C#, etc. You have to embrace functional programming as a paradigm...." I want to provide a little nuance around this, because I'd give the opposite advice. Because F# is based on OCAML and an extremely popular IDE/framework, it is first and foremost a teaching language. In my opinion, for what it's worth, the biggest mistake other F# coders make is running off into Haskell-land and trying to drag the rest of the community with them. Yes, pure FP is love and goodness, joy and love, but that's not the place to start with your average coder who just wants to see what's cool. Fable and Elmish are I learned functional programming by reading a lot of OCAML books and the only(!) F# book out at the time. I coded like shit. I couldn't help it; I came from a strong OO background. But then I figured out that instead of coding everything perfectly, it was more important to finish a little bit at a time, then take a look at functional smells, things like mutation. Sometimes I could fix these smells, sometimes I couldn't. Over time I found I could fix all of them. At that point I was a functional programmer. I love these high-level F# frameworks, and like I said it's the best way to get folks involved, but wow, folks are going to create some programming disasters using them. Yes, this happens all the time withe every new thing, but functional messes are an order-of-magnitude worse than imperative/OO ones. Good luck, guys! The destination is worth the journey.

pydry 6y ago
>functional messes are an order-of-magnitude worse than imperative/OO ones Why so?
- DanielBMarkham 6y ago
  Symbol/Semantic leakage. In imperative/OO, I'm organizing as I go using well-established and understood paradigms. In functional programming, you're making these paradigms as you go along, or at least you should be. If you come in with an "I'm going to kick some ass by making these classes to solve my problem" attitude, you're already headed down the OO track whether you realize it or not. Then, sure as night follows day, you or somebody else starts using a functional paradigm, say HoF. There's nothing wrong with any of that. As a professional, you want to be good in multiple paradigms. The problem is that you're mixing them all up, whether you realize it or not (Most of the time, programmers don't realize it) And now, every piece of code can go down two entirely separate tracks as you suss out your architecture. Not only is that not going to work, it's going to make debugging and maintenance a nightmare. This is very, very similar to how good C++ shops work. You've got to tightly limit the way you solve problems in order for all of the programmers involved to be to reason about the code.

yen223 6y ago

Are there any startups or companies using F# in production?

Weebs 6y ago
As others have alluded to, it's more common in FinTech (ex: Jane Street and Quicken Loans). There also seems to be a number of front end devs using Fable + React.
reverseblade2 6y ago
This one does https://resoptima.com/ https://resoptima.com/
JackMorgan 6y ago
I just left a team that was using F# as our language for all new code. We built shrinkwrap banking software and found it a much better alternative to C#. We were the market leaders in that space, most of the worlds big banks runs code we wrote in F#. I think F# is an improvement to C# just like how C# was an improvement to VB.NET, which was an improvement to VB6. However, it's not really a hill I'd die on, frankly new co-workers complaining about missing curly braces gets really old after the first day. Ultimately most programmers just don't care about using the best tools, and would still be happy using VB6 if the industry as a whole hadn't moved them along kicking and screaming into C#. If I'm working alone, I'll choose the best tools for the job, and I tend to think F# in modern dotnet core is one of the best tools for backend servers out there. It's much more coherent then Scala, less mushy at large codebase size than Clojure, very performant, and has great libraries like aspnet core, and compiles so much faster than Haskell and has an incredible wealth of better libraries. I also prefer a more functional style than Kotlin, Go, Java, or C# provide, because for me that means fewer unit tests to get the same confidence. There's plenty annoying with the language, but it's a great hybrid with reasonable tradeoffs. My elevator pitch typically is: with F# I need to write fewer unit tests to get the same confidence I'd need elsewhere, and that means more time programming.
decafninja 6y ago
Jet did, but they're now dead...or do they still live on inside of the greater Walmart (Labs?) organization?

FpUser 6y ago

>"You have to embrace functional programming as a paradigm." Why would I embrace/commit to any particular paradigms? I would use whatever I believe is best suitable for particular task. All those are just tools like a screwdriver. They're here to work for us, not the other way around.

reverseblade2 6y ago
Sure, but functional programming requires some discipline and restrictions for a greater good. It's certainly a choice though.
- FpUser 6y ago
  >"Sure, but functional programming requires some discipline and restrictions for a greater good" I do not care about some generic "greater good". It does not exist. In my context "greater good" is delivering products while satisfying business and technical constraints of a given customer/s to a reasonable degree.

gdsdfe 6y ago

F# on the JVM would be a game changer

Scramblejams 6y ago
I think the same thing about F# on Golang, for those tasks where GC latency matters.

josteink 6y ago

> As you can see FSF offers mentorship programs That made me blink. And then I found out they meant the F# software foundation, not the Free software foundation. It seems like a very obvious misunderstanding to make, and IMO they should avoid causing it by using another abbreviation than this one which is already very well established in programming circles.

reverseblade2 6y ago
I guess they don't. It's my mistake and I have just fixed it.

jayonsoftware1 6y ago

Is their a good F# book that will teach functional programing. Every F# book i see are trying to teach the syntax.

reverseblade2 6y ago
I am the author of the post and author of this https://www.udemy.com/course/learning-functional-programming-with-f/ https://www.udemy.com/course/learning-functional-programming... Don't be deceived by low rating. It's low because people expected a course on syntax. Also other continuations are as below: https://www.udemy.com/course/functional-application-designing/ https://www.udemy.com/course/functional-application-designin... https://www.udemy.com/course/end-to-end-real-world-application-development-with-f/ https://www.udemy.com/course/end-to-end-real-world-applicati... And if you have any questions find me from @OnurGumusDev on twitter and I will gladly help
- jayonsoftware1 6y ago
  Thanks. Bought the course. Looking forward to learning.
KurtMueller 6y ago
F# For Fun and Profit has a lot of blog posts on how to think functionally and how to use F# for domain modeling. Compositional IT has a lot of good blog posts on how they use F# to solve real world problems. Kit Eason's Stylish F# is a good book.
deleted 6y ago
[deleted]

kingdomcome50 6y ago

Okay. I don't want to go too far off topic here but the OP is about F# so I'm certain many enthusiasts will be here, and I have been waiting for this moment to get an answer to a very specific question regarding Elmish: What is the point of the Elm architecture? I cannot figure out why the `model`, `view`, `update` architecture is preferable to its OOP counterpart. That is, simply defining an interface for each of the above where `IView` and `IUpdate` each contain a single method with the appropriate parameters. That is objectively[0] cleaner! The current recommendation is to create these ungodly unions for handling the view/update logic. It feels ridiculous and really starts to gum up your modules with implementation logic that is _entirely_ unrelated. FP and OOP each provide different (opposite) faculties when dealing with the expression problem. FP says[1], "I want to optimize for adding new _behavior_ to the same pieces of data" (one can add functions that operate on the same data without needing to recompile). OOP says[2], "I want to optimize for adding new _data_ with the same kinds of behavior" (one can add classes encapsulating different data that have the same operations without needing to recompile). How does the above square with an architecture built around a set of _single_ functions that operate on different (changing) pieces of data? The Elm architecture seems to have chosen the exact wrong paradigm (and its associated semantics) for optimizing change! You aren't adding behavior as you build out your application in this architecture. You are adding _data_! The "behavior" is defined exactly one time (in the signatures of the `view` and `update` functions) and doesn't change. I must be missing something... is this really just so we can say "the complier will let us know if we forgot to handle a case"? That seems like a pretty hefty trade-off if you ask me. F# has this beautiful multi-paradigm capability and, in this case, it's been woefully ignored. [0] Okay fine maybe not objectively, but it certainly seems preferable to modularize this logic. [1][2] I get it. They don't actually say anything, but the general approach to the EP remains true for most cases.

reverseblade2 6y ago
OP here, it's a great question indeed! Now let's forget about elm/elmish but we are to write a stateful application. It doesn't have to be a web app, just any application needs to hold some state. And that state should be modifiable (Not to mention we will have side-effects as well.) in order to do something useful but we also want to stay on the Functional programming realm to get benefit from things like immutability and other functional goodies. So you see these two goals are contradictory. How FP tackles this state problem? One solution is to use actors and agents. And that's precisely what elmish is. Unlike the conventional apps where you mutate the state directly, an agent in F# is a recursive call which can await for further messages. So just like Flip Flop holds the state in memory, an agent hold the state in a recursive function. And how is this connected to elmish? Let's see how elmish v2 is implemented: https://github.com/elmish/elmish/blob/5330f52153d5181923bb3cb065436748dc38231e/src/program.fs#L90 https://github.com/elmish/elmish/blob/5330f52153d5181923bb3c... You can see an agent there and that's the core of elmish. So basically elm and elmish is a way to handle state changes in a functional manner along with side effect support via commands. I cannot emphasis importance of elmish, because not only it helps for isolating the state functionally but it helps you to keep your business logic separate from UI. So you don't end up messing your code like you use React hooks or context.

ilaksh 6y ago

How does this compare to BuckleScript or Reason?

KurtMueller 6y ago
Both BuckleScript and Reason target javascript and Reason Native targets mobile as well. F# targets .net, javascript, and the Xamarin library targets mobile (although I haven't tried it yet). They're all typed ml languages.
- ilaksh 6y ago
  I know all of that. Obviously I was asking about using F# to create web applications versus using BuckleScript or Reason.
francisl 6y ago
The equivalent is fable [1]. The major difference I would say, is that you are required to use botnet alongside of node. (dotnet to compile to JS, then node to bundle with wepback or anything else) Also, you can use the same language to build high performance backend with giraffe [2] (better than node). And build performant native application with fabulous [3]. There is an experimental typescript compilation. Which will be great, because it will make using F# less hostile in an environment where the winner takes all. [1] https://fable.io https://fable.io [2] https://github.com/giraffe-fsharp/Giraffe https://github.com/giraffe-fsharp/Giraffe [3] https://fsprojects.github.io/Fabulous https://fsprojects.github.io/Fabulous

karmakaze 6y ago

I've played with F#, OCaml, Haskell, Scala and Clojure. F# was by far the 'sweet spot' for me in terms of being able to translate my thoughts into a working functionally structured program. I hope many more are exposed to F# and that the good first experience is the norm (not currently from my experience).

KurtMueller 6y ago
Me too :). I think it hits the sweet spot for me between being as readable, expressive, and low ceremony as Ruby/Python but also type safe.
- karmakaze 6y ago
  And the trade-off of type inference and 'you have to hint here' vs compile speed is also well worth it. Like other comments here, I usually add local names or types to signatures 'for readability' (esp. to future me).

Shadonototro 6y ago

it doesn't matter, it can't compile to a native executable just like C#, it's dotnet after all, same engine

boxed 6y ago

I am writing some elm now and I'm not extremely happy. How does elmish compare in practice? Elm has very good error messages and is mostly fast but it's also annoyingly limited.

dang 6y ago

Related from 2 months ago: https://news.ycombinator.com/item?id=25305650 https://news.ycombinator.com/item?id=25305650 2017 https://news.ycombinator.com/item?id=15578592 https://news.ycombinator.com/item?id=15578592 2016 https://news.ycombinator.com/item?id=11771266 https://news.ycombinator.com/item?id=11771266

Scramblejams 6y ago

I learn a lot by reading others' code. Can anyone recommend a a project or two that is small enough for a newcomer to wrap their minds around, that also exemplifies what makes a high quality F# codebase?