Hacker News new | ask | show | jobs
by JohnDeHope 1620 days ago
I'd like a language that, as much as possible, insulated me from async worries. I'm thinking of how garbage collection helps me forget about memory allocations. I don't want to have to pepper my code with 'async' and 'await' hints everywhere. I'd prefer to not have to figure out the syntax incantation for marshaling data across threads. If I'm not mistaken Go is the closest to this?
6 comments

Couple suggestions:

* Ponylang. Pure Actor model. Static typing to enforce safe concurrent semantics in almost all respects. Plus ORCA GC. Upshot: high performance, and type theory grounded guarantees of no deadlocks, no livelocks, and no data races. Chief downsides are that MS Research has hired its founder, and it's a fledgling language/community.

* Elixir. Kinda Actor modelish. Dynamic typing, solid community. Someone else has posted about it.

* Raku. Someone else has posted about it. Chief downsides are that it's got slow single core performance and small community. Upsides include ease of use for multi core code. `start` schedules a lambda or function or statement on a virtual thread. cf Go's `go`. No `async`.

A small, but growing community, I'd say :-)
Go quite literally has a syntax incantation for marshaling data across threads (channels). The novelty of Go is that it's language-level as opposed to library-level. It's nice, but in practice I don't think it makes a huge amount of difference.

Java also has some basic thread synchronization primitives built into the language. It's way easier than you probably think. And it gets even more interesting with the upcoming project loom, which gives you the same programming model for lightweight and real threads.

Async programming is a pox on the industry. It's very useful in rare situations that require extremely high performance, but for general business processing, function coloring adds a ton of accidental complexity.

You might want to have a look at the Raku Programming Language (https://raku.org). It doesn't parallelize automatically, but only if you hint at it being ok, or if you are explicit (in this case using the `.hyper` method):

The millionth prime number using 1 CPU:

    $ raku -e 'say (1..Inf).grep(*.is-prime).skip(999999).head'
    15485863
    real 0m5.515s
Using whatever CPU cores are available (using `.hyper`):

    $ raku -e 'say (1..Inf).hyper(batch => 10000).grep(*.is-prime).skip(999999).head'
    15485863
    real 0m2.036s
In my experience, Elixir (I haven't used Erlang much, so can't comment on that too) is the first language that removed async concerns. With the lightweight thread approach and message passing, things can get "embarrassingly parallel" very easily.
Raku is closer.
Haskell tries to automatically multithread code, along with providing support for it in its standard library.
This is a myth, it does not do it automatically.