Rust's concurrency model vs. Go's concurrency model (kerkour.com)

"Sorry, you have been blocked. You are unable to access kerkour.com"

I was really hoping for a more insightful contrast of the two. I'm probably biased by reading a lot about Rust, but this seemed to be another article covering the basics of "what is userspace scheduling" and seemingly ending with "function coloring is bad".

I'd love to see more impactful reviews in the future, like how Go can do certain things that Rust can't, due to a more proactive/integrated runtime, or what kind of bugs Rust does catch, like data races or other subtle concurrency bugs possible in Go.

The article seemed well written, but I'd love to see more in-depth or technical reviews. I'm probably just not the right audience.

If one goroutine uses 2 KiB stack, then 10,000 goroutines use 20,000 KiB, right? Not 20,000 MiB.

> If you are developing in Python or C# you may already know the big cost of async/await: function coloring[1] where sync function can't call async function and vice versa.

[1] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

>> You can call a blue function from within a red one.

C#'s threadpool can handle 1M tasks, Elixir with BEAM can handle 1M tasks too (with more effort but still) and Rust can handle joining 1M futures, or even 1M tasks.

I wonder if Go can handle 1M goroutines within reasonable memory footprint :)

https://news.ycombinator.com/item?id=40435220

[flagged]

> If you are developing in Python or C# you may already know the big cost of async/await: function coloring where sync function can't call async function and vice versa.

The "blue can't call red" property -- the plot climax of the original function coloring article -- only applies to JS. Other languages can call async functions from sync functions using some sort of "block on" or "wait for" API. The function coloring problem is still annoying, but it's not a fundamental limitation like it is in JS.