5 ms·

That's widely incorrect, Rust and C are like 2-5x faster than Go? Go has arguably a better concurrency model, so for some usecases it can work much better, but

That's widely incorrect, Rust and C are like 2-5x faster than Go? Go has arguably a better concurrency model, so for some usecases it can work much better, but for some realtime programming stuff, Go is a no-go ba-dum-tss. For webdev I would never chose Rust over Go, each language has their own advantage.

lionkor 2y ago
Go's concurrency model lets you just access the same mutable variable from multiple goroutines - that kind of "good model" you can also get with C and some implementation of channels and green threads.
- brightball 2y ago
  It still offers good structures to help you be careful in these situations, but you’re right. It’s not as complete of a concurrency model as BEAM languages.
- null_investor 2y ago
  Yes, but having coded in both languages you can see how Go's concurrency system works well with it and fits neatly. Try using async in Rust and you'll see what I mean, it sucks to use it. The same applies to cpp, you'll need years and years of experience to write somewhat decent cpp what you can write in Go with a few weeks learning coroutines, and will still be prone to make mistakes. I've done lots of cpp and can affirm that after decades I'm still not sure if my concurrent solution will run as well as my half-assed Go coroutine code. Go coroutines is a good abstraction that is very fitting to the language, similar to the actor model and the BEAM VM (erlang/elixir). Use the same abstraction in another language (like JVM or C) and you'll see how the devex makes a huge difference.
  - littlestymaar 2y ago
    I'd chose async/await over threads any day, and many people do too, that's why this construct has gained so much popularity in many different languages. Async/await is a rare example in PL design where a new concept is implemented in one language and then adopted by many in the following years. In fact, the “threads are more ergonomic than async/await” seems to be more of an HN meme than a popular opinion in the wild. (And please don't quote What color is your function since it's mostly a rant about callback-based concurrency which everyone agree it sucks).
    - cube2222 2y ago
      > since it's mostly a rant about callback-based concurrency which everyone agree it sucks It really isn’t, it’s a rant about there being two worlds (colors) of functions - async and not async, which don’t compose that well together. I believe Rust is exploring the ability to genericize functions over their asyncness, and I wish them luck in that endeavor. Async/await is, if anything, a tradeoff for performance and ffi over usability. As they are generally stackless and in the case of rust don’t need allocations. With green threads like in Go you’ll generally have to allocate at least a small stack for each goroutine, and you’ll have to fix up things for ffi, but it’s much more straightforward, all functions have the same color (you just write “blocking” code, but the underlying implementation is async), you don’t have an ecosystem split, and you don’t have to war with the type system every other day (as many feel like they’re doing in Rust when writing async). It’s a pretty good point in case that Java just spent a few years making project loom happen, which effectively brings the Go approach to Java. Async/await has its place, especially in very performance-critical code, but its usability is, IMO, miles behind threads. Of course, an ideal world would be green threads with rusts compile-time checking of concurrency safety…
      - dgroshev 2y ago
        I'm not sure what you mean by "don't compose well". You can call sync code from an async function perfectly well. Going the other way around is either very simple in a throwaway code (just use pollster or tokio's block_on), or requires appropriate care (because async means IO and calling a function doing IO means your function now does IO too). I believe what most people are struggling with is having to think about doing IO instead of just doing IO wherever. But that's a feature, not a bug, and an overarching theme in Rust: you need to think what you're doing and how everything will work together. Yes you can't just put an async call somewhere down the stack without changing the signatures, but that's a good thing.
        LtdJorge 2y ago
        I think you mean block_on. Spawn blocking would be for your first use case, calling sync from async.
masklinn 2y ago
> Go has arguably a better concurrency model Go might have a better concurrency implementation, Go’s concurrency model is pretty much just threads and telling you to git gud scrub.
- null_investor 2y ago
  That's true, it's more precise to say that it's an implementation. I'm happy you understood what I meant though. The developer experience on using it is much better than using coroutines in another lang.

lionkor 2y ago

Go's concurrency model lets you just access the same mutable variable from multiple goroutines - that kind of "good model" you can also get with C and some implementation of channels and green threads.

brightball 2y ago
It still offers good structures to help you be careful in these situations, but you’re right. It’s not as complete of a concurrency model as BEAM languages.
null_investor 2y ago
Yes, but having coded in both languages you can see how Go's concurrency system works well with it and fits neatly. Try using async in Rust and you'll see what I mean, it sucks to use it. The same applies to cpp, you'll need years and years of experience to write somewhat decent cpp what you can write in Go with a few weeks learning coroutines, and will still be prone to make mistakes. I've done lots of cpp and can affirm that after decades I'm still not sure if my concurrent solution will run as well as my half-assed Go coroutine code. Go coroutines is a good abstraction that is very fitting to the language, similar to the actor model and the BEAM VM (erlang/elixir). Use the same abstraction in another language (like JVM or C) and you'll see how the devex makes a huge difference.
- littlestymaar 2y ago
  I'd chose async/await over threads any day, and many people do too, that's why this construct has gained so much popularity in many different languages. Async/await is a rare example in PL design where a new concept is implemented in one language and then adopted by many in the following years. In fact, the “threads are more ergonomic than async/await” seems to be more of an HN meme than a popular opinion in the wild. (And please don't quote What color is your function since it's mostly a rant about callback-based concurrency which everyone agree it sucks).
  - cube2222 2y ago
    > since it's mostly a rant about callback-based concurrency which everyone agree it sucks It really isn’t, it’s a rant about there being two worlds (colors) of functions - async and not async, which don’t compose that well together. I believe Rust is exploring the ability to genericize functions over their asyncness, and I wish them luck in that endeavor. Async/await is, if anything, a tradeoff for performance and ffi over usability. As they are generally stackless and in the case of rust don’t need allocations. With green threads like in Go you’ll generally have to allocate at least a small stack for each goroutine, and you’ll have to fix up things for ffi, but it’s much more straightforward, all functions have the same color (you just write “blocking” code, but the underlying implementation is async), you don’t have an ecosystem split, and you don’t have to war with the type system every other day (as many feel like they’re doing in Rust when writing async). It’s a pretty good point in case that Java just spent a few years making project loom happen, which effectively brings the Go approach to Java. Async/await has its place, especially in very performance-critical code, but its usability is, IMO, miles behind threads. Of course, an ideal world would be green threads with rusts compile-time checking of concurrency safety…
    - dgroshev 2y ago
      I'm not sure what you mean by "don't compose well". You can call sync code from an async function perfectly well. Going the other way around is either very simple in a throwaway code (just use pollster or tokio's block_on), or requires appropriate care (because async means IO and calling a function doing IO means your function now does IO too). I believe what most people are struggling with is having to think about doing IO instead of just doing IO wherever. But that's a feature, not a bug, and an overarching theme in Rust: you need to think what you're doing and how everything will work together. Yes you can't just put an async call somewhere down the stack without changing the signatures, but that's a good thing.
      - LtdJorge 2y ago
        I think you mean block_on. Spawn blocking would be for your first use case, calling sync from async.

masklinn 2y ago

> Go has arguably a better concurrency model Go might have a better concurrency implementation, Go’s concurrency model is pretty much just threads and telling you to git gud scrub.

null_investor 2y ago
That's true, it's more precise to say that it's an implementation. I'm happy you understood what I meant though. The developer experience on using it is much better than using coroutines in another lang.