11–20 of 71 posts
Why has Rust struggled so much with this, where Go has succeeded from the start with its language-level “goroutine” concept and runtime? Maybe it just wasn’t a focal area for the original Rust designers?
zero cost abstraction and no gc
Why has Rust struggled so much with this, where Go has succeeded from the start with its language-level “goroutine” concept and runtime? Maybe it just wasn’t a focal area for the original Rust designers?
"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."
Why has Rust struggled so much with this, where Go has succeeded from the start with its language-level “goroutine” concept and runtime? Maybe it just wasn’t a focal area for the original Rust designers?
It's extremely challenging to make async that is usable without introducing a garbage collector or a whole lot of runtime overhead. A better comparison would be between the Rust and C++ paths to async - C++ also spent years designing their async system, and the end result is divisive at best.
Why has Rust struggled so much with this, where Go has succeeded from the start with its language-level “goroutine” concept and runtime? Maybe it just wasn’t a focal area for the original Rust designers?
zero cost abstraction and no gc
OCaml is currently going through something similar, with some solutions in sight. The "motivation" part of the eio ( https://github.com/ocaml-multicore/eio ) documentation is a great introduction: "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…
OCaml is currently going through something similar, with some solutions in sight. The "motivation" part of the eio ( https://github.com/ocaml-multicore/eio ) documentation is a great introduction: "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…
How does programming with "effects" actually work? I've read the linked page, and I understand the advantages they're claiming, but I don't see any explanation of what effects actually are .
Why has Rust struggled so much with this, where Go has succeeded from the start with its language-level “goroutine” concept and runtime? Maybe it just wasn’t a focal area for the original Rust designers?
But this practically requires some kind of garbage collection and a fat runtime.
I think it was a good decision on the Rust team to abandon this and go for a low level systems programming language. Otherwise it would've been just another Go-like language that isn't really usable in low level systems programming.
Implementing portable async language features without a fat runtime or garbage collection is novel work so it's no wonder that it's taking its own sweet time to reach maturity.
On a somewhat unrelated note: What consequences did the Rust mod team resignation lead to? The last thing I heard was the blog post: https://blog.rust-lang.org/inside-rust/2021/11/25/in-respons... 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.
On a somewhat unrelated note: What consequences did the Rust mod team resignation lead to? The last thing I heard was the blog post: https://blog.rust-lang.org/inside-rust/2021/11/25/in-respons... 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.
Good riddance, lmao.