This is almost completely down to Go's type terrible system and is more proof that Google should have improved SML/CML (StandardML/ConcurrentML) implementations/libraries rather than create a new language. They'd have a simpler and more powerful language without all the weirdness they've added on (eg, generics being elegant and simple rather than a tacked-on abomination of syntax that Go has).
Go user for ten years and I don’t know what happened, but this year I hit some internal threshold with the garbage type system, tedious data structures, and incessant error checking being 38% of the LoC. I’m hesitant to even admit what language I’m considering a full pivot to.
Java 21 is pretty damn nice, 25 will be even nicer.
For your own application code, you don't have to use exceptions you can write custom Result objects and force callers to pattern match on the types (and you can always wrap library/std exceptions in that result type).
Structured Concurrency looks like a banger of a feature - it's what CompletableFuture should've been.
VirtualThreads still needs a few more years for most production cases imo, but once it's there, I truly don't see a point to choose Go over Java for backend web services.
And Java has non-trivial advantage over Go of being arch-independent. So one can just run and debug on Mac Arm the same deployment artifact that runs on x86 server.
Plus these days Java GC has addressed most of the problems that plagued Java on backend for years. The memory usage is still higher than with Go simply because more dynamic allocations happens due to the nature of the language, but GC pauses are no longer a significant problem. And if they do, switching to Go would not help. One needs non-GC language then.
go can ship as a static exe, can't be simpler to deploy, until java has this built-in, I'll stick with go for my cross platform choice
If you're building tools that need to be deployed to machines, Go/Rust with their static binaries make a lot of sense. But for backend web services, it's hard not to go with Java imo.
fwiw - My favorite language is Rust, but Async Rust has ruined it for me.
Yeah, async Rust is needlessly difficult. I can't quite put my finger on it but having to sift through 10+ crates docs definitely left a very sour taste when I had to modernize one tokio 0.1 app to a 1.x one.
I do love Rust a lot as well but most of the time I am finding myself using either Elixir or Golang.
And if you want even cleaner and simpler syntax, while getting the benefits of the JVM, then Kotlin is a nice "step up" from there!
My company is trying to force Kotlin as the default, but I just prefer modern Java tbh. Kotlin is a very nice language, and I'd be fine with writing it, but modern Java just seems like it has "caught up" and even surpassed Kotlin in some features lately.
I like the idea behind Go, but I feel physical pain everytime I have some sort of `go mod` behaviour that is not immediately obvious. Import/Export is so easy, I still don't get how you can fuck it up.
I found Golang to be a gateway drug to Rust for me.
If you want strong control and very unforgiving type system with even more unforgiving memory lifetime management so you know your program can get even faster than corresponding C/C++ programs, then Rust is a no-brainer.
But I did not pick it for the speed, though that's a very welcome bonus. I picked it for the strong static typing system mostly. And I like having the choice to super-optimize my program in terms of memory and speed when I need to.
Modelling your data transformations with enums (sum types) and Result/Option was eye-opening and improved my programming skills in all other languages I am using.
> you know your program can get even faster than corresponding C/C++ programs
As mentioned, I didn't go to Rust for the performance alone so I didn't track the articles that tried to prove the claim. The stated logic was that due to having more info to work with the toolchain could optimize away, quite aggressively so, many things, to the point of the code becoming lighter-weight than C.
Whether that's true or not, I make no claims. Not a compiler developer.
And yeah I'd be quite content with 1-2% margin compared to C as well.
Here is an example of Rust implementation being faster than C.
Discussions on HN of that post at the time more or less debunked the title's claim, from what I recall.
Hat tip! Here is the original HN discussion: https://news.ycombinator.com/item?id=43381512
Another thing about that library, like so many "Rust wins" that we are seeing: There is loads of unsafe code.
Yeah that was the one. I too left it unconvinced that Rust can get measurably faster than C, for what it's worth. But as said in another comment, even being 1-2% around the same ballpark is a huge win already and it would be enough for me.
OCaml is underrated IMO. It's a systems language like Go with a simple runtime but functional with a great type system and probably best error handling out of any language I've used (polymorphic variants).
Call me when they figure they should include UTF-8 strings by default. And stop having several low-level string libraries flying around.
OCaml needs more coherence and unity. It offers too much choice.
OCaml and Go are not considered systems programming languages, in part due to having required heavy runtimes and garbage collection.
So they're scripting languages?
Scripting languages would be (usually interpreted) languages for doing small snippets of code. Examples would be bash, Applescript, python, etc.
Application languages are generally managed/GC'd languages with JITs or AOT compilation for doing higher-performance apps. Examples would be Java, Go, Ocaml, Haskell, etc.
System languages are generally concerned with portability, manual memory layout, and direct hardware access as opposed to managed APIs. Examples would be C/C++, Rust, Zig, Pascal, etc.
Traditionally,
Scripts are programs that carry out a specific task and then exit. If failure occurs, it is usually on the operator to fix the issue and run the script again. I agree that bash, AppleScript, Python, etc. are geared towards these types of programs.
Applications are programs with interfaces (not necessary graphical, but can be) that are used interactively. If failure occurs, the software usually works with the user to address the problem. It's not completely unheard of to use Go here, but I wouldn't call that its strength.
Systems are "forever"-running programs to provide foundational services other programs. If failure occurs, the software usually does its best to recover automatically. This is what Go was designed for – specifically in the area of server development. There are systems, like kernels, that Go wouldn't be well suited for, but the server niche was always explicit.
Your pet definitions are fine too – it is a perfectly valid take – but know that's not what anyone else is talking about.
Raku? Unison? Qi? Don't tell me it's something boring like C# ;)
Caught me, C#. Library quality has improved a lot in ten years, the language feels modern, and one of Go's biggest advantages, single binary cross-compile, is way less relevant now that dotnet standard installs easily on every OS I care about. I was prototyping some code that needed to talk to OpenAI, Slack, and Linear and the result was.. fast and extremely readable inline async code. I've interacted with these APIs in Go as well and by comparison, ultra clunky.
We're a video game studio as well using C#, and while game programmer != backend programmer, I can at least delegate small fixes and enhancements out to the team more easily.
“Game studio” suggests you made the right choice, but the advantages you mention apply to rust and typescript too. Both those alternatives are data race free, unlike go, c# c++ and java. (Typescript is single threaded and gc’ed. Together, those properties mean it doesn’t need a borrow checker.)
As you mentioned "improvement of existing language," I'd like to mention that Haskell has green threads that most probably are lighter (stack size 1K) than goroutines (minimum stack size 2K).
Haskell also has software transactional memory where one can implement one's own channels (they are implemented [1]) and atomically synchronize between arbitrarily complex reading/sending patterns.
[1] https://hackage.haskell.org/package/stm-2.5.3.1/docs/Control...
In my not so humble opinion, Go is a library in Haskell from the very beginning.