Remix clone Hacker News

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

▲ fodkodrasz a day ago | parent [-]

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.

▲ n4r9 a day ago | parent [-]

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.

	▲	fodkodrasz a day ago \| parent [-]
		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.