Simple and safe implicit async programming model for imperative (JS/Python-like) languages
Posted by thegeleto@reddit | programming | View on Reddit | 6 comments
An article about the implicit async programming model for imperative, JavaScript/Python-like languages: ordinary sequential-looking code can run independent operations concurrently without special syntax: no await, promises, or manual task orchestration. Implemented in CascadaScript, an experimental JavaScript/Python-like language. Unbounded JavaScript and Python will not be able to do this, but with reasonable constraints they may one day get there too. CascadaScript pushes the envelope on how far this model can go.
azhder@reddit
Fun and rare reading about some of the ideas I had for years, but didn't find time to actually put them to practice i.e. creating the language
thegeleto@reddit (OP)
Yes, I think this concurrency model is one of those ideas that feels obvious: ordinary code should run independent work concurrently, and only wait when one operation actually needs another result. I’m sure plenty of people have thought about something similar.
What surprised me is that I couldn’t find languages pushing this exact model for familiar JS/Python-style imperative code. There are some efforts around CPU parallelism, but they still tend to require a lot of annotations. Maybe the obvious implementation approach, using dependency graphs or translating imperative syntax into dataflow code, has hidden pitfalls. I use a combination of several different approaches instead.
azhder@reddit
You can't find them because people who make languages are people who optimize for machines, not human. Think about why someone will zealously claim TypeScript is better to JavaScript? It will come down to TypeScript is for tools (we can discuss the many interpretations of "tools" some other time).
The only thing from ES6 that is still not widely supported by browsers is the proper tail calls (some deliberately calling it optimization). People who were making V8 had an implementation behind flags and soon enough companies that use Node.js started complaining that it would mess up their stack traces due to the replacement code generated behind the scenes. What V8 programmers did was come back to the technical committee and ask for an explicit keyword to opt in / signal the compiler for it.
In the years of me pondering how a language that puts humans first, I've come to like how Haskell does business, with maybe the C/JS curly brace syntax. The async by default is one step, the replacement of the try-catch unwinding is another - I've come to dislike having two critical paths side by side.
thegeleto@reddit (OP)
... On the error-handling side, yes, it’s close in spirit to container-style approaches and promise chains: failure becomes a value/context that propagates instead of unwinding through throw/catch. In Cascada, that error flows through ordinary imperative-looking data and control flow, so you don’t manually unwrap, chain, try, or await everywhere; dependent computations are poisoned and independent work keeps running.
thegeleto@reddit (OP)
The tail-call issue is relevant to this. Async/concurrency has the same kind of tension: the nicer the model becomes for humans writing code, the harder the implementation has to work to preserve debugging, ordering, stack traces, and explainability.
Honestly, from that angle I’m a little surprised async/await made it into the spec and we’re not all still wiring callbacks by hand. It’s a good example that languages can absorb complexity to give humans a better model, but the bill always shows up somewhere. Anyone who has done stack trace archaeology through callbacks, promises, and async frames has seen that bill.
azhder@reddit
It is a self-amplifying vicious circle.
They make languages that are easier for machines, not people. They teach people to think those kinds of languages are the best and only good languages. They make tools that can better parse and understand those languages. They replace people with those tools. They make new languages that are best parsed by the tools that replaced people...
The holy grail of big corporations like Microsoft. I will use M$ as a placeholder/example because it's been there for decades and made languages/tools and evangelized them. The holy grail has been to do the same the automobile industry has. Well, first they had to portray writing code / creating software as an industry, then figure out how to automate it.
For cars, the automation came in full after something over 50 years of them existing. How long has software production as a job existed? Anyways, it isn't a coincidence why there were old jokes like "what if cars were made like software" and "what if car industry developed like software industry".
Those few people that can afford to create "artisanal" programming languages and tools for programmers that create software as a craft, not industry, well, all the best I guess. The rest will more or less have to learn by analogy from the automobile industry.