7 ms·

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/)
        dboreham 4y ago
        Rolling deployment is a hack imho. Adds complexity and hence yet more potential failure modes.
        oauea 4y ago
        Hardly, it's a fantastic guardrail when combined with health checks. You can say "you don't need it", but everyone makes mistakes sometimes. Make those mistakes not matter. You also take backups, right? Same idea.
        dboreham 4y ago
    - galangalalgol 4y ago
      I meant slow to develop in.
      - za3faran 4y ago
        With features like records, pattern matching, enums, and many more, I find it much better than the likes of Python or golang.
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

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/)
        dboreham 4y ago
        Rolling deployment is a hack imho. Adds complexity and hence yet more potential failure modes.
        oauea 4y ago
        Hardly, it's a fantastic guardrail when combined with health checks. You can say "you don't need it", but everyone makes mistakes sometimes. Make those mistakes not matter. You also take backups, right? Same idea.
        dboreham 4y ago
  - galangalalgol 4y ago
    I meant slow to develop in.
    - za3faran 4y ago
      With features like records, pattern matching, enums, and many more, I find it much better than the likes of Python or golang.

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