This is still another loophole and the companies which exploit the program and workers (small consulting firms, not big tech per se) are still going to exploit this.
After reading Careless People, I would be more surprised if Meta was _not_ doing these things. The company is amoral/immoral in the truest "responsibility to shareholders" (number go up) way. It needs to be made to lose everything.
I’m confused about the assertion that green threads perform badly. 3 of the top platforms for high concurrency servers use or plan to use green threads (Go, Erlang, Java). My understanding was that green threads have limitations with C FFI which is why lower level languages don’t use them (Rust). Rust may also have performance concerns since it has other constraints to deal with.
Green threads have issues with C FFI mostly due to not being able to preempt execution, when the C thing is doing something that blocks. This is a problem when you have one global pool of threads that execute everything. To get around it you essentially need to set up a dedicated thread pool to handle those c calls.
Which may be fine - go doesn't let the user directly create thread pools directly but do create one under the hood for ffi interaction.
The problem is when C calls expect to be on a particular thread. Either the main event thread, in a GUI context, or the same thread as some related previous call.
Different languages give different level of control over that. There are languages with one main thread pool and perhaps some specialized ones that users don't have control over. Go would be an example of this.
It is also possible for languages to make user creatable thread pools - possibly even with affinity to cores, allowing fibers to run only on a single thread. Crystal is coming along that path. So far it seems to be coming around fairly nicely but I havn't had to battle the GC in anger yet.
This post does a fantastic job of laying out the reasoning and implementation of various concurrency methods and their trade-offs. It is one of the rare nuanced views on async/await vs green threads. Plus it makes the links between CPS, delimited continuations and effects, thus generalizing concurrency into one of several possible "stackful" operations.
I think the _only_ thing the author didn't cover about concurrency is that "waiting for one of several things to complete" is a powerful primitive for concurrency that very few platforms provide direct access to. I.e. most async event loops are powered by OS primitives that allow such "heterogenous selects" and they are used under the hood but not exposed. I think Go's select, Tokio's equivalent, ConcurrentMLs/Racket more powerful choice
operator. All of these allow expressing some nice patterns that other languages make impossible (sad Promise.race) or not user facing (cancellation in structured concurrency)
Racket is related to LISP and already has a mature GUI implementation that uses native widgets on Windows and MacOS, and on Linux goes to GTK3 or falls back to GTK2.
https://docs.racket-lang.org/gui/index.html
It is used to create their full featured teaching IDE.
It is worth looking at before re-inventing the stack.
reply