Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
The Unison language [1] also has a very interesting effect system.
[1] https://github.com/unisonweb/unison
I don't really know much about this area, but there's a language literally called Lawvere.
https://github.com/jameshaydon/lawvere
Rust first has Erlang-like behavior with "colorless" I/O and green threads, and all of that was proven to be unfit for a systems programming language, and scrapped before 1.0:
https://github.com/rust-lang/rfcs/blob/0806be4f282144cfcd55b...
> for such a small piece of work
Don't take the example too literally, some functions calls can be here.
Running computations in parallel is often valuable. Or run computations in parallel with waiting for external resource - why does not the code in the article compute something while waiting for a, b and c?
Anyways, if async functions are so good, why not have all functions async?
The article says this a kind of "documentation" that tells you what functions can wait for some external data and what functions are "pure computation". If it was so, it would be OK. Such a documentation could be computed automatically based on the called function implementations and developer is hinted: "these two functions you call are both async, consider waiting for both in parallel". In reality, the async / await implementations prevent the non-async functions from becoming async without code change and rebuild. This restriction is just a limitation of how async / await is implemented, not something useful.
As other commenter says, the article "embraces a defect introduced for BC reasons as if it's sound engineering. It really isn't."
When my code is called by a 3rd party library, I can not change my code to async. That's the most unpleasant property of today's async / await. What yesterday was quick computation tomorrow can become a network call. For example, I may want to bodies of rarely used functions to only load when called first time (https://github.com/avodonosov/pocl).
The article suggest we have to decide upfront, at the top-level of the application / call stack, which parts can be implemented with as waiting blocks and which should never wait for anything external. This is not practical.
> It's almost always faster to do them in parallel if possible.