by bmcniel on 12/8/21, 4:06 AM with 68 comments
by zackmorris on 12/8/21, 4:29 PM
I grew up with cooperative multitasking on Mac OS and used Apple's OpenTransport heavily in the mid-90s before Mac OS X provided sockets. Then I spent several years working on various nonblocking networking approaches like coroutines for games before the web figured out async. I went about as far down the nonblocking IO rabbit hole as anyone would dare.
But there's no there there. After I learned Unix sockets (everything is a stream, even files) it took me to a different level of abstraction where now I literally don't even think about async. I put it in the same mental bin as mutexes, locking IO, busy waiting, polling, even mutability. That's because no matter how it's structured, async code can never get away from the fact that it's a monad. The thing it's returning changes value at some point in the future, which can quickly lead to nondeterministic behavior without constant vigilance. Now maybe my terminology here is not quite right, but this concept is critical to grasp, or else determinism will be difficult to achieve.
I think a far better programming pattern is the Actor model, which is basically the Unix model and piping immutable data around. This is more similar to how Go and Erlang work, although I'm disappointed in pretty much all languages for not enforcing process separation strongly enough.
Until someone really understands everything I just said, I would be very wary of using async and would only use it for porting purposes, never for new development. I feel rather strongly that async is something that we'll be dealing with and cleaning up after for the next couple of decades, at least.
by Zababa on 12/8/21, 9:39 AM
"The Unix library provided with OCaml uses blocking IO operations, and is not well suited to concurrent programs such as network services or interactive applications. For many years, the solution to this has been libraries such as Lwt and Async, which provide a monadic interface. These libraries allow writing code as if there were multiple threads of execution, each with their own stack, but the stacks are simulated using the heap.
The multicore version of OCaml adds support for "effects", removing the need for monadic code here. Using effects brings several advantages:
1. It's faster, because no heap allocations are needed to simulate a stack.
2. Concurrent code can be written in the same style as plain non-concurrent code.
3. Because a real stack is used, backtraces from exceptions work as expected.
4. Other features of the language (such as try ... with ...) can be used in concurrent code.
Additionally, modern operating systems provide high-performance alternatives to the old Unix select call. For example, Linux's io-uring system has applications write the operations they want to perform to a ring buffer, which Linux handles asynchronously."
by bishop_mandible on 12/8/21, 8:46 AM
by crtc on 12/8/21, 8:28 AM
But I haven't seen any public discussions on the future of Rust governance, how to make the core team accountable, or other consequences since.
by ezekiel68 on 12/8/21, 12:53 PM
By the way, using Go as an example is a joke since -- from the early Go bootcamp I attended in 2014, the best practice has been to use a 3rd-party http router (these days: gorilla? httprouter? chi? etc) instead of the one provided in the standard library. Instead of being _told_ what to use, let's get back to being interested enough that we read the docs, take in the reviews & benchmarks, and decide for ourselves.
by pie_flavor on 12/8/21, 4:57 PM
by camdenlock on 12/8/21, 7:32 AM