Hacker News Reader

Comment by kryptonomist | Hacker News Reader

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.

View on HN

> 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.

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.

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.

Mypy provides a server to help with this called dmypy: https://mypy.readthedocs.io/en/stable/mypy_daemon.html

Check out https://github.com/microsoft/pyright, it's pretty snappy if you don't mind some JS in your ecosystem.

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.

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.

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.

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.

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.

I think he was talking more about serverless functions, where 300ms longer for answering an HTTP-request would be pretty long.

See GraalVM: https://quarkus.io/

> 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.

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

Reply on news.ycombinator.com