←back to thread

Why F#?

(batsov.com)
441 points bozhidar | 4 comments | 01 Apr 25 12:34 UTC | HN request time: 0.814s | source
Show context
darksaints ◴[01 Apr 25 18:08 UTC] No.43549778[source]▶
I'm completely convinced that F# (along with Scala, Haskell, and OCaml) adoption has stalled due to having ridiculously bad build systems. More significantly, they are being passed up in favor of Rust, which is a great language but nonetheless a bad fit for a lot of problem domains, simply because Rust has a superior build system. Hell, 80% of the reason I choose Rust over C++ for embedded work is because of the build system.

It baffles me that there are languages with non-profit foundations and are financially backed by multiple corporations which still have bad build systems. It is the most important investment you can make into a programming language.

replies(7): >>43551301 #>>43552671 #>>43554790 #>>43554888 #>>43555737 #>>43556392 #>>43559547 #
1. torginus ◴[02 Apr 25 11:56 UTC] No.43555737[source]▶
My two cents is that F# hasn't received the same care and attention as C# and working with it can be awkward.

At the same time, a lot of the cool features (list comprehension, pattern matching, immutable records) have slowly trickled into c#, giving even less incentive to switch

replies(1): >>43558066 #
2. fodkodrasz ◴[02 Apr 25 15:51 UTC] No.43558066[source]▶
I personally find the way these features were shoehorned into the C# syntax an eyesore, I have quite some C# experience, and I think the language is getting more and more convoluted and noisy, with ever less coherent syntax.

On the other hand many of these features are really convenient and handy in F#. Adding many of the oh-my-gamedev-such-speed features from C# to F# also makes its syntax less pleasant to work with.

Personally I also think that the C# async model is terrible, and was a grave mistake. The F# async model with computation expressions, and explicit control over their execution context was a better approach, and I'm really sorry the hack-something-together to unblock the event loop WPF/frontend-dev usecase won over the more disciplined backend-focused approach.

replies(1): >>43560635 #
3. n4r9 ◴[02 Apr 25 19:36 UTC] No.43560635[source]▶
I have the opposite experience. Being able to write stuff like this is refreshing:

  public record Name(string First, string? Last = null);
  public record Register(Name[] Members);
  ...
  var register = new Register([new("John", "Doe"), new("Neo")])
It probably depends on what you're writing. I'm not using async much at all so I don't feel the pain of it.
replies(1): >>43561069 #
4. fodkodrasz ◴[02 Apr 25 20:21 UTC] No.43561069{3}[source]▶
For me the pain is twofold:

a) it poisons all interfaces it touches (common trait of async in other languages as well)

b) C# async Task -s typically are created in Running state without any easy control over when, where and how they will execute. Controlling these things is far from trivial, and and requires lot of extra effort.

In F# the traditional async block is a builder for an async workflow, and you could then submit this workflow to an executor that is easy to configure for the execute model best suites you, eg. thread pool, single thread with continuations, maximum number of "operations" in flight, etc. The fact that it is not started right away also makes it easy to create your own executors.

Having to deal with backpressure in C# style async is way harder IMO. On the other hand when writing a UI app, always having to submit to an executor might seem inconvenient, and you generally don't have to handle thousands of concurrent requests all reaching out to a (different) backend and avoid DOS-ing it. This is why I wrote that this way made with a frontend-centric approach in my opinion.