4 ms·

What are you looking for in the 2 languages? Here are some of my thoughts: Golang * Development speed: Golang wins by far. It's closer to Python in that regar

What are you looking for in the 2 languages? Here are some of my thoughts: Golang * Development speed: Golang wins by far. It's closer to Python in that regard, but with strong typing. * Very nice multi-threading via Go routines and channels. Impressive semantics in simple syntax, requiring no synchronization mechanism on the user side. * Large garbage collector penalty. Rust * Complete language with build system, crate, docs hosting. * A lot more performance compared to Golang, on par with C++. * Doctests (!). * Slow to learn, slow to compile (probably not a deal-breaker, especially if you focus on microservices). Concerning what would be a good usecase for Rust vs Golang, check this out: https://discord.com/blog/why-discord-is-switching-from-go-to-rust https://discord.com/blog/why-discord-is-switching-from-go-to...

tofuahdude 4y ago
How "large" is the garbage collector penalty? My understanding is that the Go GC is significantly more efficient than for example JS's mark/sweep approach. Apples to oranges for sure, but I am interested in better understanding how expensive the Go GC is vs Rust performance.
- masklinn 4y ago
  Go’s GC is not efficient, it is responsive. That is, it trades throughput (and performances, and efficiency) for small pauses and concurrency.
- mihaigalos 4y ago
  Check out the discord article I posted in the original reply. If I interpret the graphs correctly, I see: Golang: * baseline 20% cpu + spikes to 35% once the GC runs. * response times of about 1ms + spikes up to 10ms. Rust: * baseline 12% cpu + flat, no spiking. * response times of 20us + flat, no spiking (!). In terms of scaling, I interpret the results in favor of Rust. My reasoning is the more you run the GC, the bigger the penalty.
  - tofuahdude 4y ago
    Just read that article; very informative. The TLDR is that, especially during GC, P99s and response times are notably worse in Go than Rust. Makes sense.
  - jhgb 4y ago
    The question here is how much can you disambiguate between the impact of GC and the impact of differently written code plus differently optimizing compiler backend (where Go is still very simple but Rust uses LLVM). If for example the Go code used goroutines and channels in those places where the rewritten Rust code uses asynchronous operations, that alone may account for substantial differences in performance.
  - lossolo 4y ago
    Posting links to his blog post is misleading in 2022. The issue they mention in their blog was fixed so it's not an issue now.
    - mihaigalos 4y ago
      That's interesting. Would like to read about the solution more. Do you have a reference?
masklinn 4y ago
> Very nice multi-threading via Go routines and channels. Impressive semantics in simple syntax, requiring no synchronization mechanism on the user side. Except for all the times they are required and Go doesn’t tell you: https://eng.uber.com/data-race-patterns-in-go/ https://eng.uber.com/data-race-patterns-in-go/ Go’s fundamental semantics are standard not-safe shared-memory multi threading. It provides an mpmc queue as a built-in out of necessity (since no generics originally, which would have made for an awkward situation), but really the only thing that’s notable about it is `select`, not `go` or `chan`. In in some ways `go` is even a downgrade from other languages: you can’t get a handle on the goroutine and thus have to muck around with side-channels to even know that a subroutine has terminated let alone get its result.
- philosopher1234 4y ago
  >In in some ways `go` is even a downgrade from other languages: you can’t get a handle on the goroutine and thus have to muck around with side-channels to even know that a subroutine has terminated let alone get its result. You sound like you don't know why they explicitly refuse to add the ability to get a handle on the goroutine. If you do know, you are misleading people by omitting it.
rob74 4y ago
My thoughts on your thoughts: * Go also includes the complete build system, package management (although it wasn't there from the beginning), code documentation, testing and fuzzing. Also the standard library is much more extensive than in Rust ("batteries included"). * Doctests: since you mention them explicitly, Go has those too: https://go.dev/blog/examples https://go.dev/blog/examples * "Large garbage collector penalty": that obviously depends on your application and what you consider acceptable. I would say that in most cases the easier development enabled by having GC is worth it, but YMMV. Here's a discussion on the Go garbage collector: https://news.ycombinator.com/item?id=12042302 https://news.ycombinator.com/item?id=12042302
- mihaigalos 4y ago
  Wow, very nice! I didn't know that. I love how the language is evolving, it also now has generics.
Jyaif 4y ago
> slow to compile In my experience it's the slowest language to compile ever, and the binaries generated are gargantuan. I was super excited to learn Rust, but that excitement is now 100% gone.
- bbojan 4y ago
  I wonder what other languages you have experience with. C++ is obviously not one of them.
- rcxdude 4y ago
  Binary size very much depends on your settings. Rust does not optimise for a small 'hello world' by default, but it's very possible to get small binaries from it if that's a priority for you (for example, the default debug build neither optimizes for size nor strips debug information, as well as statically linking the standard library). Compile times are more sticky problem and most ways to improve it basically involve avoiding certain language features and libraries.
- gg2222 4y ago
  Same. I was about to jump into learning Rust and make it my no.1 language for new projects instead of node.js + TypeScript, but once I learned about the slow compile times I stopped that thought immediately.
  - ModernMech 4y ago
    For me it was a choice between slow compile times now when it’s safe, or unbounded time solving security and stability issues later when it’s critical.

tofuahdude 4y ago

How "large" is the garbage collector penalty? My understanding is that the Go GC is significantly more efficient than for example JS's mark/sweep approach. Apples to oranges for sure, but I am interested in better understanding how expensive the Go GC is vs Rust performance.

masklinn 4y ago
Go’s GC is not efficient, it is responsive. That is, it trades throughput (and performances, and efficiency) for small pauses and concurrency.
mihaigalos 4y ago
Check out the discord article I posted in the original reply. If I interpret the graphs correctly, I see: Golang: * baseline 20% cpu + spikes to 35% once the GC runs. * response times of about 1ms + spikes up to 10ms. Rust: * baseline 12% cpu + flat, no spiking. * response times of 20us + flat, no spiking (!). In terms of scaling, I interpret the results in favor of Rust. My reasoning is the more you run the GC, the bigger the penalty.
- tofuahdude 4y ago
  Just read that article; very informative. The TLDR is that, especially during GC, P99s and response times are notably worse in Go than Rust. Makes sense.
- jhgb 4y ago
  The question here is how much can you disambiguate between the impact of GC and the impact of differently written code plus differently optimizing compiler backend (where Go is still very simple but Rust uses LLVM). If for example the Go code used goroutines and channels in those places where the rewritten Rust code uses asynchronous operations, that alone may account for substantial differences in performance.
- lossolo 4y ago
  Posting links to his blog post is misleading in 2022. The issue they mention in their blog was fixed so it's not an issue now.
  - mihaigalos 4y ago
    That's interesting. Would like to read about the solution more. Do you have a reference?

masklinn 4y ago

> Very nice multi-threading via Go routines and channels. Impressive semantics in simple syntax, requiring no synchronization mechanism on the user side. Except for all the times they are required and Go doesn’t tell you: https://eng.uber.com/data-race-patterns-in-go/ https://eng.uber.com/data-race-patterns-in-go/ Go’s fundamental semantics are standard not-safe shared-memory multi threading. It provides an mpmc queue as a built-in out of necessity (since no generics originally, which would have made for an awkward situation), but really the only thing that’s notable about it is `select`, not `go` or `chan`. In in some ways `go` is even a downgrade from other languages: you can’t get a handle on the goroutine and thus have to muck around with side-channels to even know that a subroutine has terminated let alone get its result.

philosopher1234 4y ago
>In in some ways `go` is even a downgrade from other languages: you can’t get a handle on the goroutine and thus have to muck around with side-channels to even know that a subroutine has terminated let alone get its result. You sound like you don't know why they explicitly refuse to add the ability to get a handle on the goroutine. If you do know, you are misleading people by omitting it.

rob74 4y ago

My thoughts on your thoughts: * Go also includes the complete build system, package management (although it wasn't there from the beginning), code documentation, testing and fuzzing. Also the standard library is much more extensive than in Rust ("batteries included"). * Doctests: since you mention them explicitly, Go has those too: https://go.dev/blog/examples https://go.dev/blog/examples * "Large garbage collector penalty": that obviously depends on your application and what you consider acceptable. I would say that in most cases the easier development enabled by having GC is worth it, but YMMV. Here's a discussion on the Go garbage collector: https://news.ycombinator.com/item?id=12042302 https://news.ycombinator.com/item?id=12042302

mihaigalos 4y ago
Wow, very nice! I didn't know that. I love how the language is evolving, it also now has generics.

Jyaif 4y ago

> slow to compile In my experience it's the slowest language to compile ever, and the binaries generated are gargantuan. I was super excited to learn Rust, but that excitement is now 100% gone.

bbojan 4y ago
I wonder what other languages you have experience with. C++ is obviously not one of them.
rcxdude 4y ago
Binary size very much depends on your settings. Rust does not optimise for a small 'hello world' by default, but it's very possible to get small binaries from it if that's a priority for you (for example, the default debug build neither optimizes for size nor strips debug information, as well as statically linking the standard library). Compile times are more sticky problem and most ways to improve it basically involve avoiding certain language features and libraries.
gg2222 4y ago
Same. I was about to jump into learning Rust and make it my no.1 language for new projects instead of node.js + TypeScript, but once I learned about the slow compile times I stopped that thought immediately.
- ModernMech 4y ago
  For me it was a choice between slow compile times now when it’s safe, or unbounded time solving security and stability issues later when it’s critical.