What's the role of Go in a universe where Rust exists?(kristoff.it)
kristoff.it
What's the role of Go in a universe where Rust exists?
https://kristoff.it/blog/why-go-and-not-rust/
54 comments
Well, like everything in life, it's not perfect.
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.
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.
I totally agree. I don't think it is possible to build a perfect language. However I don't think there are many sets of requirements were Go is the best option. However there are many situations where it isn't a terrible option, and maybe that is its secret.
This is a very good point. Basically bounding the worst case can be more valuable than optimizing for a specific use case.
I have worked on a considerable amount of Go code over the last 5 years and I diametrically disagree with almost every single one of your points here. Just wanted to share. Basically take any bullet from that list of what you think about Go and I have the exact opposite opinion, not sure what that means in the end but I found it interesting:
- 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
- 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
Totally agree and very well said. Go just works. I find it insanely easy to read. The comments about the JVM ... no. thank. you. Single no-dependency go binaries are beautiful. Cross compilation and hooks to C when needed are also big wins.
Sorry to hijack your comment about Go, and the thread about Rust. But has google at any point tried using D for anything? Seems like an easy to read language, implements templates and has good portability - wondering why its not gaining traction?
D is amazing. High level AND low level when you need it. The ecosystem is just lacking and doesn't have a big player backing it like go, java, c# etc.
>There are some JVM languages that are better and have similar performance.
How about a single example?
How about a single example?
Java
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)
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)
Can't wait til they complain that Java is too verbose while they're manually writing for loops in GO.
Java is insanely verbose. Fact.
If that's the scale, then Go is archdemon-salesman verbose. Primal-Cosmic Fact.
Its less verbose than Go. Fact.
Do you have anything to back this up?
I haven't done any scientific comparison, but my personal feeling is that Go is terser.
Yes the simplest being writing a loop to filter or map. In go you will be writing full loops and intermediate variables. I'm not going to list the go versions because I'm on mobile.
In Java:
In Java:
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;
}
This is the Java most haven't seen because their experience is with codebases predating the streaming-API, sometimes even generics.
The death of Java will be Scala-written dependencies in the Maven-packages ecosystem ending up as a liability.
The death of Java will be Scala-written dependencies in the Maven-packages ecosystem ending up as a liability.
C# and the CLR
Are you saying that python is better than GO on syntax alone?
Like easier to review code ...?
Like easier to review code ...?
In many ways yes. The high level code it is far easier to review the semantics of the change. With Go I feel like I am too bogged down in all of the unimportant implementation details. (I don't really care how you implemented `map` I don't need to see the 4 lines of that loop)
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.
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.
in all seriousness, but how many golang and python code bases of roughly equally the size have you reviewed and examined?
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...
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...
> With Go I feel like I am too bogged down in all of the unimportant implementation details.
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...
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...
I agree that async creating coloured functions is a compromise. However in practice I don't find it too distracting. At the very least it is less distracting then Go's error handling. (Although IIRC that is going away thankfully)
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.
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.
I'm not looking for a job, but I'm often invited to chat with a company's dev team, and I get a chance to see what they are doing and how they are doing it. The last company I visited was a handful of Physics Ph.D.s. They were writing control software.
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.
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.
I'm not sure one has to be CS major in order to understand Common Lisp. The language has almost no syntax and is multi-paradigm. I bet modern C++ and Rust would be much harder for them compared to CL.
This is all the same reason I and the company I work for use Go. It’s good tool and powerful in hands of smart people.
Great article. I would say my two minor disagreements is that go's fast compilation is not... Typically used for tests, in my opinion the testing discipline in go is low. I would go so far to say that go is neither "a better c++" nor "a better c" but rather "a better python".
The golang stdlib is a little too barebones to be a better python, as well as not ergonomic enough. Faster, yes.
Sorry, I should have specified: a better python for google. Google doesn't generally need all the things in the python stdlib.
It does need a way for their legion of new hires to not trip over themselves and slot into an enterprise-friendly programming mode
It does need a way for their legion of new hires to not trip over themselves and slot into an enterprise-friendly programming mode
Go is good because it’s easy to read and pickup, and it compiles really fast. I would say it’s good for request based services but I don’t think it’s as good as it can be for enterprise code. What I miss most is the lack of sum types to limit state space, which is very useful in business logic.
Go is much easier to learn and get up and running compared to Rust in my experience. It's great for writing servers and multi-threaded applications. Rust can be used to optimize but you'll probably get a lot of mileage out of golang before having to switch.
The other day I read an article about which language C programmers should use, and how Go is better thought of than Rust but that in the end his suggestion is to go for C++ [0].
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?
[0] https://berthub.eu/articles/posts/cpp-rust-go/
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?
[0] https://berthub.eu/articles/posts/cpp-rust-go/
Java developers would surely ask "Why not Java?".
"Go is simple" is the main one and only reason I love Go.
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.
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.
Fully agree.
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.
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.
"The Go compiler is fast."
This was Google's motivation for Go and the reason it was designed the way it was.
This was Google's motivation for Go and the reason it was designed the way it was.
incremental compilation is so slow in rust. it is ridiculous.
it completely ruins my flow
it completely ruins my flow
Most people don't understand what it's like to work on a large C++ or Rust code base. Compilation time is a huge factor in productivity.
That's a wrong question to ask. Rust is the one trying to squeeze in to the already crowded place, not Go.
Golang though excellent lost the plot by having Nil pointers. it means bugs will always exists inside code intentionally or not.
To me Go is competing with JavaScript, not Rust. If you're considering writing a CRUD app in Node.js, you can do it in Go, and it'll be equally easy, and maybe run faster.
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.
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.
[deleted]
sorry. but if you really choose to write a simple CRUD app in go, I feel very sorry for you. Go is terrible for this kind of stuff.
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.
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.
Pity because you don't understand a language is a weird one.
> Let’s avoid tying our identity to a single language and embrace practicality first and foremost.
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.
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.
That fact that we need to prepare in advance to defend learning a new-ish language and then using to build something interesting or useful is a depressing.
Oh well, the PM will make you re-write it in that k8s thingy anyway, because everyone else has it.
Oh well, the PM will make you re-write it in that k8s thingy anyway, because everyone else has it.
Well, if you have an unexplained hatred for typing double colons five times per line of code, as I do, Go allows you to not do that.
Rust::Forces::Them<Colons>::Everywhere::AllTheTime();
Rust::Forces::Them<Colons>::Everywhere::AllTheTime();
Honestly it's certainly not the worst language construct?
It's not the worst, but for me, it is easily the most hated. It's a stupid thing to get hung up on, I know. For some reason my hands don't like to type colons, even though semicolons and shift keys alone are just fine. I just hate typing colons. Feels lazy to adopt a C++ construct when you are trying to produce something to replace C++, anyway.
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++.
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++.
DevOp, Python replacement.
All the things 'hn_asker' said plus a giant ecosystem, huge developer attention, amazing tooling, outstanding support for parallelism, jobs, a good pool of enterprise-grade projects (CockroachDB, all the thinks from HashiCorp, K8S, Docker, etc).
And Gophers!
And Gophers!
Did you read the article?
Yes, yes I did and stand by my comments. Go has done everything my team has asked of it and done it well. It’s a joy and rock solid. I have code deployed all over the world and Go made that manageable in so many ways. Language is personal choice. Choose what works for your set of engineering and devops challenges.
That's not far from what the article says. Your comment sounds like you were being defensive of go from the article.
- 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).