Max Krohn, a programmer who created IcedCoffeeScript, writes about async control flow, error handling, and Bitcoin key storage.
HN links it when discussing async control flow and callback hell; commenters say IcedCoffeeScript predates ES async features and still prefer its syntax over typical promises.
1. In open source, everyone plays lip service to how you can just fork things, but nobody wants to do the hard, infinite work of building a new ecosystem. You'll just rediscover the exact thing that burned evancz out.
2. Elm's stance on sync vs async ffi isn't a big deal. A fork is like when there was that IcedCoffeeScript spin off on CoffeeScript: https://maxtaco.github.io/coffee-script/ -- it's more of a gimmick in what is already a tiny ecosystem.
3. Last I checked there was "elm-janitor" for managing patches and getting them into core Elm as an end user or something. Dunno what came of it, but I think it goes back to only a handful of people are going to use something like that. And there are already Elm-inspired languages with ~0 users out there. The hard part is ecosystem.
It's not like Javascript where you can launch something like preact (react but smaller) and get 38k github stars. It's not going to be rewarding.
Also IcedCoffeeScript
http://maxtaco.github.io/coffee-script/
It's just CoffeeScript with await and defer keywords, essentially.
I personally would never touch toffeescript/coco and friends as they differ too much for CoffeeScript, which already segregates the JS userbase enough. I figure IcedCoffeeScript is the lesser evil for compile-time control flow as it's not adding a bunch of other changes to the language that users have to understand to contribute to a project written in it. Another issue with these CS spinoffs is; what if the main contributor says "Fuck it" and bails? CS itself is big enough to have a lot of talented contributors. What happens when CS moves over to CS 2.0 ie. coffeescript redux? Do these spinoffs need to recoded?
That being said I probably won't use Iced either, as much as I want to... Maybe I'm all wrong about this? Maybe this userbase segregation crap is not as big a deal as I may think.
I very much like this model, but I wonder how necessary it is when we have IcedCoffeescript [1], ES6 generators + co [2], and ES7 async/await [3] as viable ways of managing async control flow within mostly synchronous-looking code, all as dialects of languages that have strong adoption.
I actually think generators + co is a really strong model. Async/await gives you a slight bit of sugar, but I've realized that if you stick with generators, you can wrap your generators to allow you to `yield` more than just promises, effectively giving you something like (untyped) scoped continuations [4].
[1] https://maxtaco.github.io/coffee-script/
[2] https://github.com/tj/co
[3] http://masnun.com/2015/11/11/using-es7-asyncawait-today-with-babel.html
[4] http://blog.paralleluniverse.co/2015/08/07/scoped-continuations/
Oh yeh sorry I didn't mean to give the impression I thought you were wrong. I 100% agree with you.
I remember the first time I experienced "callback hell" (2016, for me, but I'm sure it was a huge problem for others before then) when I was doing some JavaScript stuff implementing Keybase's library for GPG support - I learned they'd built a whole separate JavaScript thing called IcedCoffeeScript[1] specifically to add await/defer support to get rid of those huge callback pyramids.
1. http://maxtaco.github.io/coffee-script/
Just transform it to continuation-passing style[1] and call/cc is no problem (neither are non-local exits). Granted your compiled code will be somewhat large and not much like 'regular' code in the language. That can be solved by doing selective CPS transform (IcedCoffeeScript[2] does this), but that gets slightly less straightforward.
Compiling continuations to a dynamic language is actually really easy.
--
1: https://en.wikipedia.org/wiki/Continuation-passing_style
2: http://maxtaco.github.io/coffee-script/
This is how I've been writing Iced Coffeescript for years. I still believe it's a major improvement over the typical promise syntax.
And to make the error handling even cleaner, check out the errify/errorCallback pattern:
http://maxtaco.github.io/programming/2014/09/18/handling-errors-in-iced-coffee-script/
https://www.npmjs.com/package/errify
https://github.com/nextorigin/express-rendertype/blob/master/src/fancy.coffee