42 ms·

Not sure I agree with Go vs Rust. I think if you would choose Java or Python or C#, then Rust might not be the right choice.

marcosdumay 4y ago
Whatever the absolute merits (or lack of them) of Go, the fact is that if it's a good (enough) option for you, then it's almost certain that some language will fit your problem better than Rust.
pleb_nz 4y ago
I wouldn't group python with java and c# either. Quite different beasts
ntonozzi 4y ago
Go belongs in the exact same bucket as Java and C#.
- galangalalgol 4y ago
  C# sure, but unless you are doing something pretty close to the core purpose of some giant java framework java is slow and verbose
  - tasubotadas 4y ago
    Slow and verbose compared to what?
  - ntonozzi 4y ago
    Java, Go and C# (and node) have very similar performance, e.g. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/.... For all of them, the key to writing high performance code is avoiding allocations and boxing. Go and C# both do this slightly better than Java, but in most domains where these languages are used, this is not a big difference (and this is where you might use C/C++/Rust instead). I've found Go to be more verbose than Java, but I haven't used Go much since generics were released.
  - maleldil 4y ago
    It's amazing how the "Java is slow" myth survives to this day.
    - johnny22 4y ago
      i just read "java is slow" as "java is slow to startup" and that helps. Java is slow(er) to to startup, but once it's going, it's pretty good.
      - maleldil 4y ago
        That doesn't matter if you're writing a REST api. If you're writing a CLI app, then I agree that's a problem.
        dboreham 4y ago
        Sometimes matters, e.g. when you deploy new code.
        oauea 4y ago
        Not really, just do a rolling deployment like you should be doing anyway. No one cares if the new version takes 1 millisecond to start up or 3 seconds because they literally won't notice.
        imtringued 4y ago
        But 3 seconds isn't on the table. It is more like 20-30 seconds on a medium sized app and 8 seconds for a small one.
        bzzzt 4y ago
        If your Java app takes half a minute to initialise it's the app's problem, not Java. Modern Java frameworks have moved from a dynamic deployment model to statically compiled and can start in milliseconds. (for example, see the benchmarks on https://quarkus.io/blog/runtime-performance/ https://quarkus.io/blog/runtime-performance/)
- tptacek 4y ago
  Ergonomically, yes. Logistically, no.
  - mike_hearn 4y ago
    For server binaries they're typically being dropped into Docker containers not scp-d to servers directly, and the moment you go there you can just use jib and get a JVM container easily so there's no difference in logistics. For CLI tools whilst a single binary can be convenient, native-image lets you get those for JVM programs too these days. But it's not always the case that it's enough. In practice you will often hit the need for: a. Cross platform / cross builds. b. A way to easily update them for your users (that isn't "everyone mount this NFS/SMB drive") c. Ability to ship other files e.g. third party libraries written in other languages, config files, data files, readmes ... d. Possibly, avoiding virus scanners and Gatekeeper if you have users on Windows/macOS. Conveyor [1] does support distributing CLI tools (in any language) that can then be updated via apt-get, the Windows package manager or Sparkle on macOS. If your language/runtime supports cross-building then it can do it all from your developer laptop, you don't need each OS to build for. The resulting artifacts are single files (deb, msix/exe, zip) and it supports both self-signing and regular signing if you want that. It provides a few other neat features on Windows: • One click install that immediately adds new tools to every single terminal session without needing restarts. • If you want, silent background updates Chrome-style. If you don't, manually triggered updates. • For JVM apps specifically it automatically configures the Windows terminal to support ANSI escapes, Unicode and other modern features so you can use all the same stuff as on UNIX without needing to futz around with win32 or wrappers. Unfortunately the little default GUI that lets you trigger updates and add CLI tools to your path on macOS isn't officially launched yet, because it only works for JVM apps and not other types of program. But if anyone wants to try it just let me know, it's easy to activate. If you don't need any such features then yes, a single binary can be a bit more convenient than a zip. But the number of situations where it breaks down is pretty high and it's not so hard to handle multiple files. [1] https://hydraulic.software/ https://hydraulic.software/
    - tptacek 4y ago
      I want to be careful not to recapitulate every conversation I've ever had with a JVM person about this. I'm not claiming it's impossible to deploy JVM applications; obviously, tons of people do. I'm just saying people use Go and Rust because they work well in situations where you want to distribute and directly run a simple binary without additional tooling. That's not every situation; obviously, if you can use Docker, there's not much difference between a JVM app and any other kind. Your comment is super interesting, don't let me sound like I'm trying to shoot it down. I'm being deliberately terse to avoid creating receptors for language war antigens to bind to.
- FpUser 4y ago
  Performance wise yes. As for language features - not really. Code in Go would likely have way more LOC
throw14082020 4y ago
Go is in a sweet spot where it is often used to compete with both groups: [Rust, C/C++] and [Node, Python, Ruby, etc]. The reason GP said it is probably because of Garbage collection. I've done a bit of Rust in my job, and there are some basic things that Rust doesn't have going for it: - steep learning curve (this means for the first 6 months, you or your colleagues are unproductive, write bad Rust which your company then builds upon over time). - bad error messages (even though that was a focus for the rust team!) - frustratingly complex for setting up test coverage - Slow analyzer speed (*super laggy* on Clion, though this might be a jetbrains issue) - Slow compilation times (I heard somewhere that "Go just goes". I've also written some Go in my free time, and compilation is fast. Well IMHO, "rust will rust" - it's very slow. Generics can make compilation event slower.) - Verbose. I've seen a just few lines of JS get replaced with hundreds and thousands of Rust.
- alfalfasprout 4y ago
  Unfortunately, I'm inclined to agree. Rust lives in this interesting spot where, on paper, it should be superior to anything... but in practice, it's not a good choice in most cases. It's very easy to ramp up someone in Go that's had a standard CS education and written C/C++ before. It's also simple enough syntax-wise for someone who knows python well enough to understand references, etc. Its stylistic restrictions and not being OOP-first also mean that codebases are generally readable. Compilation is also extremely straight forward. With Rust, I've found even very experienced C++ folks have a long ramp-up period, the development toolchain is slow, and the ecosystem is limited. Sure, for example there are projects to enable Rust usage with CUDA. But few are inclined to actually bother implementing a new BLAS and GPU accelerated tensor library with Rust. I do think 10 years from now Rust will start getting more adoption as the ecosystem and tooling improve. But it's hard to argue with Go where you'll typically get results that are faster or at worst comparable to Java without the OOP design pattern gobbledygook, simple concurrency model, and simple build process. It's "good enough" for 99% of use cases.
  - zozbot234 4y ago
    Go has bad interop with C/C++ and languages that use the C/C++ ABI (including Rust). You can use cgo as a workaround but it's clunky. So that makes an interesting case for other high level, novice-friendly languages like Nim, Crystal or Val/Vale/Vala.

marcosdumay 4y ago

Whatever the absolute merits (or lack of them) of Go, the fact is that if it's a good (enough) option for you, then it's almost certain that some language will fit your problem better than Rust.

pleb_nz 4y ago

I wouldn't group python with java and c# either. Quite different beasts

ntonozzi 4y ago

Go belongs in the exact same bucket as Java and C#.

galangalalgol 4y ago
C# sure, but unless you are doing something pretty close to the core purpose of some giant java framework java is slow and verbose
- tasubotadas 4y ago
  Slow and verbose compared to what?
- ntonozzi 4y ago
  Java, Go and C# (and node) have very similar performance, e.g. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/.... For all of them, the key to writing high performance code is avoiding allocations and boxing. Go and C# both do this slightly better than Java, but in most domains where these languages are used, this is not a big difference (and this is where you might use C/C++/Rust instead). I've found Go to be more verbose than Java, but I haven't used Go much since generics were released.
- maleldil 4y ago
  It's amazing how the "Java is slow" myth survives to this day.
  - johnny22 4y ago
    i just read "java is slow" as "java is slow to startup" and that helps. Java is slow(er) to to startup, but once it's going, it's pretty good.
    - maleldil 4y ago
      That doesn't matter if you're writing a REST api. If you're writing a CLI app, then I agree that's a problem.
      - dboreham 4y ago
        Sometimes matters, e.g. when you deploy new code.
        oauea 4y ago
        Not really, just do a rolling deployment like you should be doing anyway. No one cares if the new version takes 1 millisecond to start up or 3 seconds because they literally won't notice.
        imtringued 4y ago
        But 3 seconds isn't on the table. It is more like 20-30 seconds on a medium sized app and 8 seconds for a small one.
        bzzzt 4y ago
        If your Java app takes half a minute to initialise it's the app's problem, not Java. Modern Java frameworks have moved from a dynamic deployment model to statically compiled and can start in milliseconds. (for example, see the benchmarks on https://quarkus.io/blog/runtime-performance/ https://quarkus.io/blog/runtime-performance/)
tptacek 4y ago
Ergonomically, yes. Logistically, no.
- mike_hearn 4y ago
  For server binaries they're typically being dropped into Docker containers not scp-d to servers directly, and the moment you go there you can just use jib and get a JVM container easily so there's no difference in logistics. For CLI tools whilst a single binary can be convenient, native-image lets you get those for JVM programs too these days. But it's not always the case that it's enough. In practice you will often hit the need for: a. Cross platform / cross builds. b. A way to easily update them for your users (that isn't "everyone mount this NFS/SMB drive") c. Ability to ship other files e.g. third party libraries written in other languages, config files, data files, readmes ... d. Possibly, avoiding virus scanners and Gatekeeper if you have users on Windows/macOS. Conveyor [1] does support distributing CLI tools (in any language) that can then be updated via apt-get, the Windows package manager or Sparkle on macOS. If your language/runtime supports cross-building then it can do it all from your developer laptop, you don't need each OS to build for. The resulting artifacts are single files (deb, msix/exe, zip) and it supports both self-signing and regular signing if you want that. It provides a few other neat features on Windows: • One click install that immediately adds new tools to every single terminal session without needing restarts. • If you want, silent background updates Chrome-style. If you don't, manually triggered updates. • For JVM apps specifically it automatically configures the Windows terminal to support ANSI escapes, Unicode and other modern features so you can use all the same stuff as on UNIX without needing to futz around with win32 or wrappers. Unfortunately the little default GUI that lets you trigger updates and add CLI tools to your path on macOS isn't officially launched yet, because it only works for JVM apps and not other types of program. But if anyone wants to try it just let me know, it's easy to activate. If you don't need any such features then yes, a single binary can be a bit more convenient than a zip. But the number of situations where it breaks down is pretty high and it's not so hard to handle multiple files. [1] https://hydraulic.software/ https://hydraulic.software/
  - tptacek 4y ago
    I want to be careful not to recapitulate every conversation I've ever had with a JVM person about this. I'm not claiming it's impossible to deploy JVM applications; obviously, tons of people do. I'm just saying people use Go and Rust because they work well in situations where you want to distribute and directly run a simple binary without additional tooling. That's not every situation; obviously, if you can use Docker, there's not much difference between a JVM app and any other kind. Your comment is super interesting, don't let me sound like I'm trying to shoot it down. I'm being deliberately terse to avoid creating receptors for language war antigens to bind to.
FpUser 4y ago
Performance wise yes. As for language features - not really. Code in Go would likely have way more LOC

throw14082020 4y ago

Go is in a sweet spot where it is often used to compete with both groups: [Rust, C/C++] and [Node, Python, Ruby, etc]. The reason GP said it is probably because of Garbage collection. I've done a bit of Rust in my job, and there are some basic things that Rust doesn't have going for it: - steep learning curve (this means for the first 6 months, you or your colleagues are unproductive, write bad Rust which your company then builds upon over time). - bad error messages (even though that was a focus for the rust team!) - frustratingly complex for setting up test coverage - Slow analyzer speed (*super laggy* on Clion, though this might be a jetbrains issue) - Slow compilation times (I heard somewhere that "Go just goes". I've also written some Go in my free time, and compilation is fast. Well IMHO, "rust will rust" - it's very slow. Generics can make compilation event slower.) - Verbose. I've seen a just few lines of JS get replaced with hundreds and thousands of Rust.

alfalfasprout 4y ago
Unfortunately, I'm inclined to agree. Rust lives in this interesting spot where, on paper, it should be superior to anything... but in practice, it's not a good choice in most cases. It's very easy to ramp up someone in Go that's had a standard CS education and written C/C++ before. It's also simple enough syntax-wise for someone who knows python well enough to understand references, etc. Its stylistic restrictions and not being OOP-first also mean that codebases are generally readable. Compilation is also extremely straight forward. With Rust, I've found even very experienced C++ folks have a long ramp-up period, the development toolchain is slow, and the ecosystem is limited. Sure, for example there are projects to enable Rust usage with CUDA. But few are inclined to actually bother implementing a new BLAS and GPU accelerated tensor library with Rust. I do think 10 years from now Rust will start getting more adoption as the ecosystem and tooling improve. But it's hard to argue with Go where you'll typically get results that are faster or at worst comparable to Java without the OOP design pattern gobbledygook, simple concurrency model, and simple build process. It's "good enough" for 99% of use cases.
- zozbot234 4y ago
  Go has bad interop with C/C++ and languages that use the C/C++ ABI (including Rust). You can use cgo as a workaround but it's clunky. So that makes an interesting case for other high level, novice-friendly languages like Nim, Crystal or Val/Vale/Vala.