Fight me. As a classical software engineer, I hate Go, but in this new era it wins so easily. For web, at least. The subjective stuff about how the language feels is all out the window now.
There's no good way to resolve these kinds of debates. I don't think AI changes much. It thinks in the same sorts of ways we do, just faster, so things humans find hard or unproductive can also be hard and unproductive for AI too. There are a few exceptions where it's able to reason fast enough that things which would be dumb for humans (like reading raw assembly or bytecode) are no big deal for AI. But mostly it's the same.
The parent did mention:
> ...and is simple to deploy.
Also, my experience with Java programs is that the memory overhead is even higher than Go (where it's a ~2x of what the program holds as heap due to the GOGC=100 default).
./gradlew installDist # build the app for deployment
rsync -avz --delete build/install/my-app/ user@host:my-app/
But in reality most software isn't deployed by copying binaries around. You'd want it to be at minimum run by systemd or kubernetes, for example. And if you want a Docker container then it's pretty easy. Your framework probably configures it out of the box:
./gradlew dockerBuild
The reason it's not harder in the end is that the above takes cares of many annoying details that crop up in real deployment, like knowing what CPU and CPU extensions does the host have? Can you deploy incrementally without recopying the whole thing or does that not matter?
The above is for servers, but it's not really harder for CLI tools either. Fat JARs exist. If the user doesn't have a JVM, once again, they can install one easily from their package manager and then it's done - no need to create and distribute half a dozen binaries for all the different OS and CPU combinations that are out there.
But if you want to make AOT compiled binaries and get lower memory usage too, there is GraalVM which can do both. You've got the choice.
Note how the above debate isn't changed by AI in any way. Their weaknesses remain weaknesses, their strengths remain strengths. I wouldn't personally use Go because of its poor feature set and debugging support (errors don't reliably create stack traces). But the arrival of LLMs changes nothing about these preferences and choices. At most you can talk about token efficiency, in theory, but the attempts to measure the real world impact of that don't seem to have yielded decisive evidence.
And compared to Go, the production observability is very good.
I also use Clojure and can observe my running app with a full REPL.
Can you give some examples where Go is lacking and Java is great? (Ideally builtin things, and if not builtin, then things where Go doesn't have an externally developed alternative).
> I also use Clojure and can observe my running app with a full REPL.
Does this work with other JVM languages, like Java, too?
This debate in particular is easy to resolve: there is no “best“ language for all use cases and I agree LLMs have not changed that. The best language for a scenario depends entirely on the scenario, so talking about best languages without a scenario in mind is completely the wrong discussion.
I've never written a general program in my life. I've written a bunch of specific ones, though. What I care about is which language is best for writing this specific program. Why do I care about which language is best at writing a program that I'm not trying to write?
As a quite well seasoned software engineer working many years with Java, C#, PHP etc. both in complex calculation systems and webservices, go-lang just feels superior in so many aspects. While I might still fare better in say Java is purely a function of me spending much more time in it.
So I see your point in myself and agree and agree. (I just don't hate go, I think we need to give it a chance)
```
...
bla, err := doSomething(...);
if err != nil {
...
}
...
```
...
...
err = do_someting(&bla, ...);
if err != 0 {
...
}
...
It's not that different
No. I’m sick of flame wars, and I already was before LLMs turned everyone even more insufferable. You can fight yourself in your own corner, if you like. Never thought I’d miss emacs VS vim.
Use whatever language you want, I couldn’t give less of a shit. I have no desire to waste time on a dick-measuring competition, and that’s doubly true because people in these fights are measuring other people’s dicks.
> As a classical software engineer, (…) The subjective stuff about how the language feels is all out the window now.
Subjective stuff never mattered to people who take no pride in doing proper work. That hasn’t changed because of LLMs, it only shone a brighter light on those people.
I do agree the comment came off strong and for that I apologise to the person above. I meant to make a general criticism, not condemn any particular individual.
AI + smaller docker images made me look at it again.
The fact I can test/build concurrently and much faster than rust, off the same repo without messing with sccache and worktrees, make it easily the winner for many web/self-contained scenarios.
You also get very easy parallelism in Goroutines, excellent ecosystem, and one of the best performance profilers in any programming language, pprof.
I’ve done pretty low-level C++ and Fortran in the past, but these days I’m honestly mostly used Python with either NumPy or CuPy for calculations, so not very low-level at all. My code is pretty performance-sensitive though, so unless the main operations can be framed neatly in terms of NumPy or CuPy primitives, one had to drop down to low level.
Do you know how the Go library support is for typical scientific computing stuff, e.g. matrix diagonalization, sparse matrices, or handing off such calculations to CUDA (or other GPU frameworks)? Is there a strong numerics community in Go these days, or would you have to implement most of what you need yourself?
https://github.com/gonum/gonum
For sparse, I think the best is still Intel's sparse libraries for MKL on CPU, it's just not a workload that runs well on GPU compared to dense SGEMM. You can call it via CGo.
For GPU offloading, there should be a decent amount of CUDA bindings available for Go right now, but I'm not as familiar in that front since I'm building my own GPU compute runtime in Vulkan, but it's still very much an experimental work in progress right now.
Yeah, my understanding is also that working with sparse matrices inherently requires heavy branching, which translates badly to GPU. I usually do everything I can via dense matrices via CUDA, but switch to sparse matrices on CPU if I run out of VRAM…
I think Go's compile times are great for the AI age, but that "pretty fast runtime" is not.
Go is close enough on runtime for all reasonable purposes.
Even better don't throw away the frameworks, learn to use JIT caches and hot code reloading tools, and you can even debug, edit and continue from the comfort of an IDE, doing several useful actions.