I think a "before" comparison would've really helped with this example. I'd also argue a state machine approach has the added benefit of allowing you to enter the sequence at any point. If you use `Co.Seq` to e.g. build a form flow, it'd be hard to test or serialize into the middle of the sequence.
There may be something interesting here but it's pretty hard to bite into.
Since it has to be transpiled into the severely limited language JavaScript, is it worth it at all? F# for instance should have been a functional language but it turns out to be just some lipstick on the pig of procedural object soup, since the .NET runtime isn't actually capable of anything else. Is the situation any better here?
CIL has had functional languages in mind since its inception, particularly because of explicit tailcall support.
If anything, it provides all the low-level building blocks the JVM lacks that enable efficient lowering strategy (even if F# does so relatively conservatively and does not push .NET like it could have).
Interesting to see a project from Giuseppe's Github here on HN.
FP for browser apps is a lot of fun for us lately, but we picked Elm. The rationale: the absence of runtime errors is really sweet when your code runs in the browser (no need to collect browser console output in a central location in order to know what goes wrong).
Lately I've used Gleam with the Lustre framework (which is inspired by Elm). The coolest thing is that one can do server rendered components with it also. It is a very young ecosystem but the community is great!
Yeah, that’s exactly what I’m wondering. I was confused by the same name, so when I did a search, it only came up with a language for system integration and not what I remembered. Thankfully it resurfaced again.
Is it though?