What's the role of Go in a universe where Rust exists?
kristoff.it
kristoff.it
- It was very difficult to read. When trying to review the code every detail was left out. While each line was simple it was hard to actually get the high-level picture of what code was doing.
- Very error prone. Maybe it isn't C dangerous but "defaults are useful" is the breeding ground of bugs. The number of outages we had due to trivial Go bugs was embarrassing and time consuming.
- Some simple things are just too hard. Most of these boil down to lack of generics. For example inserting an element into an array needs multiple lines of code.
- Many common functions and buitins have very questionable decisions that are huge footguns. Especially the fmt library. (It tries its absolute hardest not to fail. Instead it just outputs garbage and "succeeds")
I get that it is easy to write, and that each line of code is simple. However I think they went way too far.
I see Go as a slightly higher level C. You get better package management, memory management and interfaces. However C is still way too basic for my preferences.
It is a weird spot though. It is sitting in about 2x C performance. It is unclear what to recommend in that spot as many languages are significantly slower. Rust is probably roughly as productive, but much harder to learn. Most of the interpreted languages are significantly slower.
There are some JVM languages that are better and have similar performance. However there is a memory and startup overhead. However I think they make more sense in the end. JavaScript is also a pretty good choice. It is in roughly the same performance realm but much more productive I think. (Especially TypeScript).
Like easier to review code ...?
Of course with minimal static typing it is easy to miss more "typo" style bugs but those tend to be caught fairly easy in tests and are obvious when they fail.
But then when people praise Python and Rust, getting bogged down with "unimportant implementation details" like specialized async typing and colored functions becomes an absolutely essential and useful aspect of the language.
There's just no accounting for taste...
However if you put N:M threading against 1:1 threading then you can argue about that all day. I think the implementations in Rust and Go are very effectively implementations of each model. The threading model difference is *not* something that I hold against Go.
It is possible for a language to handle some things well but have other downsides that makes me prefer to avoid it.
Python is HELL if you are new to a codebase. Everyone has their own conventions, lack of typing means you need to do a lot of guesswork, dynamic calls break up control flow etc.
Yes, go is more explicit (lack of generics...), but at least its straightforward. Just compare k8s codebase with nomad with your homegrown stuff. It will likely look a bit like the same sauce...
However, after initially intensely disliking the language, I found out that I was surprisingly productive, and that the lack of abstractions made for very readable code. The toolchain and standard library are also very good (coverage, race detector, cross compiler, etc).
Compared to python, I get fewer bugs (no surprises, and compile time instead of runtime) and faster code, and compared to rust, I get readable code. It's strictly better than C / C++ (lack of generics aside until now) , unless you have strong performance constraints (and I'd probably use rust these days anyway).
In the end it's good at some things, not great in any way, not highly appealing but curiously effective.
I think I like it just because it works surprisingly well, even though it initially went against my gut feeling.
How about a single example?
I mean you can argue about the productivity all day but I think I would slightly prefer it. But there are a handful of JVM languages hovering around 2x C performance (after being warmed up)
In Java:
arr.stream().map(SomeClass::someFn).collect(toList())
In Java:
static <T extends Number> T min(T a, T b) {
if (a < b) return a;
return b;
}
The death of Java will be Scala-written dependencies in the Maven-packages ecosystem ending up as a liability.
- Go is easy to read
- Go is much less error prone and encourages good testing habits
- You can build complex things with very simple primitives without relying on magic.
- The fmt library just works
Obviously, this team was really smart, but they were not high power software developers. They weren't ex-kernel developers and they didn't write 3D game engines in their spare time. They were just really smart guys that knew how to program.
They were using go, and I felt like that was a great choice for them. Fast enough performance, comfortable development, and easy enough to understand. This is what I really like about go.
Languages like Haskell and Common Lisp are popular topics here on HN, but they'd be poor choices for a startup made up of domain experts that aren't CS-majors. I'm sure these guys could have learned Rust or even modern C++, but with go they could get started in a language that wouldn't take a year of experience to use correctly.
For my many little personal projects, I like python, but for team projects were there will be a mix of abilities go seems like a good choice.
It does need a way for their legion of new hires to not trip over themselves and slot into an enterprise-friendly programming mode
Interesting observation was that the Rust community had more fanatic followers who believe in Rust and nothing else, whereas the Go community was more relaxed about it.
That makes me wonder: if something had been written in Rust, would a Go, Python, or C++ developer ask why not in their language? Or would they just not care?
I learned Rust in my spare time, and it took me months to get to the point where I could write anything useful at all. I never did feel like I knew the language. I just don't have the spare time and energy to put in such a monumental effort into learning a language. After 2 weeks of Go I knew nearly all the ins and outs of the language. Once you add in sophisticated and strict linting from golangci-lint you just can't go wrong. Code reviews are a breeze and understanding code is a breeze.
For me Go is the ultimate "scratch the itch" language. Knowing C already, I learned everything I needed to know about Go in an hour or two. I see it as a faster and better version of Python, in that it's fairly readable, but unlike Python you can compile to native binaries and deploy on any platform (including Windows) without any fuss.
Personally I don't see it as competing in the same space as Rust. I've dipped my toe into Rust a few times and the language feels like way more effort than it's worth for the sort of glorified shell scripts I want to do in my personal time.
This was Google's motivation for Go and the reason it was designed the way it was.
it completely ruins my flow
But if you're writing a driver, codec, kernel, firmware, or even a library that's supposed to be usable with more than one language, Go is just not a good fit.
On the other hand, if you are about to write a nice daemon that needs to do some difficult stuff and C is a bit too low level for you (or a deadline is pressing), then go might be just be the perfect tool for it.
I use a lot of languages, and golang usually only ever competes with C or C++. For the scripting/CRUD-like stuff i Usually still prefer NodeJS or python.
This is very poignant.
I feel like there a part of us that is attached to a certain language/framework, and we intentionally wear a blindfold to avoid seeing other solutions that are more practical.
Oh well, the PM will make you re-write it in that k8s thingy anyway, because everyone else has it.
Rust::Forces::Them<Colons>::Everywhere::AllTheTime();
There was an opportunity to choose something less C++-like but someone thought "I'm used to doing this because of C++, so I'll keep the double colon" and kept it around. Ok, that's fine, and I'm gonna keep talking trash about Rust, because I'm used to doing it because of C++.
And Gophers!