5 ms·

To me, the greatest advantage of Go is the build time, which is almost instant. So you get the joy of programming like in Python/Js, being able to test very qui

To me, the greatest advantage of Go is the build time, which is almost instant. So you get the joy of programming like in Python/Js, being able to test very quickly your code, without having to deal with stupid errors coming from type mismatch or function parameters. Plus, you get the performance of a compiled language, with a simple syntax. Sure, you get just slightly better results with C/C++/Rust, but then you deal with complicated OS level calls, memory and library deployment issues (problems fixed by Go). Yes, a few benchmarks show C#/Java almost as fast, but at the price of a highly optimized syntax not seen in any average programmer. An average guy get superb performance with Go without complications from day 1. And absent object oriented features are quickly forgotten.

maleldil 5y ago
> C/C++/Rust, but then you deal with complicated OS level calls What OS-level calls are you doing in C++/Rust that you aren't in Go? > library deployment issues (problems fixed by Go) How is Go's library tooling better than Cargo? I believe Go's is strictly worse, with its URL-based imports and how it deals with major versions.
- Thaxll 5y ago
  I think OP is talking about single binary with no dependencies here. As for go mod, yes it's not perfect but it's as powerful as Cargo. https://golang.org/ref/mod https://golang.org/ref/mod
throwaway894345 5y ago
> So you get the joy of programming like in Python/Js, being able to test very quickly your code Ironically the canonical Python type checker, code formatter, etc take ages to run on even small code bases.
- bobbylarrybobby 5y ago
  I think a lot of that is that Python doesn't launch a server that handles code analysis/formatting requests, so every time you want to do another round of things-to-do-on-save, they all have to do be done more or less from scratch (some info can be cached between runs, but if you're launching a Python process that's like 100ms right there...). I imagine if there were a Python code server that handled formatting and type checking without ever shutting down, it would be quite speedy.
  - bombela 5y ago
    I have some sort of python language server running with neovim to highlight type errors. This is definitively not fast to add errors. But being asynchronous it's palatable.
  - MapleWalnut 5y ago
    Mypy provides a server to help with this called dmypy: https://mypy.readthedocs.io/en/stable/mypy_daemon.html https://mypy.readthedocs.io/en/stable/mypy_daemon.html
- wbobeirne 5y ago
  Check out https://github.com/microsoft/pyright https://github.com/microsoft/pyright, it's pretty snappy if you don't mind some JS in your ecosystem.
ryandvm 5y ago
C#/Java are almost as fast, but not for immediate execution environments. If you have one off invocations of the code, Go executables will beat the pants off Java as you wait for the JVM to fire up and for HotSpot to kick in.
- ed25519FUUU 5y ago
  Maybe fast in principle but rarely in practice. I’ve never once worked in a Java codebase that started up shorter than 5 or 10 seconds.
- throwaway894345 5y ago
  I've heard smart people argue convincingly that the JVM doesn't actually take long to fire up, and that this is something of a myth. It may take a bit of time for the JIT to optimize, but that shouldn't impact basic CLI tools (un-JIT-ed code is basically just interpreted code, and that runs quickly enough). I'd be curious to hear from people who have looked into this.
  - kaba0 5y ago
    For smallish programs, a recent JVM will start up in 100ms. This is enough to make some CLI tools (like eg. git, with many separate invocations that return almost instantly) slightly bad to use, but longer running CLI tools are perfectly fine with it. There is also Graal to AOT compile classes and that way the startup time is truly negligible. What actually increases JVM startup time is class loading, as it has to do byte code validation and the like for each new class. This is only apparent for largish frameworks though. As for JIT, there is no much point for short-lived programs. Like, most python scripts are run without that and people write prod code in it.
- jpavel2 5y ago
  I write a variety of CLI tools for my own use in Java. On this low-end Chromebook (Samsung Chromebook 3 with a Celeron N3060 @1.60GHz) I can start the JVM, load the classes for my CLI program, and print a help message, jpavel@penguin:~$ time rcr -h Usage: RCloner <config path> get|put <entry> [args] RCloner <config path> list real 0m0.316s user 0m0.208s sys 0m0.126s in less than 1/3 of a second. And this is with stock openjdk version 1.8.0_302, which doesn't include the startup time improvements of Java 10 & 12. Sure, I wouldn't write utilities meant to be piped one into another, but for standalone CLI tools, the JVM startup time isn't prohibitive at all.

maleldil 5y ago

> C/C++/Rust, but then you deal with complicated OS level calls What OS-level calls are you doing in C++/Rust that you aren't in Go? > library deployment issues (problems fixed by Go) How is Go's library tooling better than Cargo? I believe Go's is strictly worse, with its URL-based imports and how it deals with major versions.

Thaxll 5y ago
I think OP is talking about single binary with no dependencies here. As for go mod, yes it's not perfect but it's as powerful as Cargo. https://golang.org/ref/mod https://golang.org/ref/mod

throwaway894345 5y ago

> So you get the joy of programming like in Python/Js, being able to test very quickly your code Ironically the canonical Python type checker, code formatter, etc take ages to run on even small code bases.

bobbylarrybobby 5y ago
I think a lot of that is that Python doesn't launch a server that handles code analysis/formatting requests, so every time you want to do another round of things-to-do-on-save, they all have to do be done more or less from scratch (some info can be cached between runs, but if you're launching a Python process that's like 100ms right there...). I imagine if there were a Python code server that handled formatting and type checking without ever shutting down, it would be quite speedy.
- bombela 5y ago
  I have some sort of python language server running with neovim to highlight type errors. This is definitively not fast to add errors. But being asynchronous it's palatable.
- MapleWalnut 5y ago
  Mypy provides a server to help with this called dmypy: https://mypy.readthedocs.io/en/stable/mypy_daemon.html https://mypy.readthedocs.io/en/stable/mypy_daemon.html
wbobeirne 5y ago
Check out https://github.com/microsoft/pyright https://github.com/microsoft/pyright, it's pretty snappy if you don't mind some JS in your ecosystem.

ryandvm 5y ago

C#/Java are almost as fast, but not for immediate execution environments. If you have one off invocations of the code, Go executables will beat the pants off Java as you wait for the JVM to fire up and for HotSpot to kick in.

ed25519FUUU 5y ago
Maybe fast in principle but rarely in practice. I’ve never once worked in a Java codebase that started up shorter than 5 or 10 seconds.
throwaway894345 5y ago
I've heard smart people argue convincingly that the JVM doesn't actually take long to fire up, and that this is something of a myth. It may take a bit of time for the JIT to optimize, but that shouldn't impact basic CLI tools (un-JIT-ed code is basically just interpreted code, and that runs quickly enough). I'd be curious to hear from people who have looked into this.
- kaba0 5y ago
  For smallish programs, a recent JVM will start up in 100ms. This is enough to make some CLI tools (like eg. git, with many separate invocations that return almost instantly) slightly bad to use, but longer running CLI tools are perfectly fine with it. There is also Graal to AOT compile classes and that way the startup time is truly negligible. What actually increases JVM startup time is class loading, as it has to do byte code validation and the like for each new class. This is only apparent for largish frameworks though. As for JIT, there is no much point for short-lived programs. Like, most python scripts are run without that and people write prod code in it.
jpavel2 5y ago
I write a variety of CLI tools for my own use in Java. On this low-end Chromebook (Samsung Chromebook 3 with a Celeron N3060 @1.60GHz) I can start the JVM, load the classes for my CLI program, and print a help message, jpavel@penguin:~$ time rcr -h Usage: RCloner <config path> get|put <entry> [args] RCloner <config path> list real 0m0.316s user 0m0.208s sys 0m0.126s in less than 1/3 of a second. And this is with stock openjdk version 1.8.0_302, which doesn't include the startup time improvements of Java 10 & 12. Sure, I wouldn't write utilities meant to be piped one into another, but for standalone CLI tools, the JVM startup time isn't prohibitive at all.