I really don’t want to be this grumpy old man, but.. can we just stop comparing this two, completely unrelated languages? Where are all the Zig vs Haskell posts? It makes just as much sense. Go is simply not a low-level language, and it was never meant to occupy the same niches as Rust, that makes deliberate design tradeoffs to be able to target those use cases.
With that said, I am all for managed languages (though I would lie if I said that I like Go - would probably be my last choice for almost anything), and thankfully they can be used for almost every conceivable purpose (even for an OS, see Microsoft’s attempts), the GC is no problem for the vast majority of tasks. But we should definitely be thankful for Rust as it really is a unique language for the less often targeted non-GC niche.
You should understand the context a little bit: Shuttle is a company focused on deploying backend applications in Rust. Backend applications (server programs) is precisely the main use-case for Go. It absolutely makes sense for them to compare the two in this context.
Java is an even more common choice for backend development, but fair enough.
My gripe is actually the common, hand-in-hand usage of this “rust’n’go” term, which I’m afraid is more often than not depends on a misconception around Go’s low-levelness, as it was sort of marketed as a systems language.
It is a “systems language”… by the original definition where low-levelness was a side-effect of the times and the primary focus was long-term maintainability and suitability for building infrastructural components.
(Which, in the era of network microservices, is exactly what Go was designed for. Java, Go, and Rust are three different expressions of the classical definition of a “systems language”.)
That said, there has been a lot of misconception because it’s commonly repeated that Go was created “to replace C++ as Google uses it”… which basically means “to replace Python and Ruby in contexts where they can’t scale enough, so you used C++ instead”.
BTW Rob Pike is cited in it where he regrets calling Go a systems language, but that’s probably because he used it in the original sense, and the meaning has drifted.
Go is simply not a low-level language, and it was never meant to occupy the same niches as Rust, that makes deliberate design tradeoffs to be able to target those use cases.
Go was originally designed as a successor to C. The fact that it’s been most successful as a Python replacement was largely accidental. It does (via the unsafe package) support low-level things but, like Rust, tries to make you opt in for the small bits of code that actually need them.
Go was originally designed as a successor to C. The fact that it’s been most successful as a Python replacement was largely accidental. It does (via the unsafe package) support low-level things but, like Rust, tries to make you opt in for the small bits of code that actually need them.
Go had three explicit, publicized design goals from the start; none of them were “be a successor to C”.
They were written relative to the three languages in use at google:
Expressive like c++/python
Fast like java/c++
Fast feedback cycles (no slow compile step) like java/python
Go had three explicit, publicized design goals from the start; none of them were “be a successor to C”.
Rob Pike was pretty explicit that it was intended as a C successor. He said this several times in various things that I heard and read while writing the Go Phrasebook. His goal was to move C programmers to a language with a slightly higher level of abstraction. He sold it to Google relative to their current language usage.
I appreciate that the Go code here is Actually Good™ — it uses proper types, has proper function signatures, and does proper error handling. Thank you!
I do distributed systems and web, and learning Rust made Go an obsolete language as far as I’m concerned. I legit can not think of a use case where I would pick Go over Rust.
Having a team that doesn’t already know Rust is at least one reason I can think of. It takes much less time to get a team up to speed on Go than it does on Rust.
Maybe compilation/test speed (eg. development velocity) is another.
Well, yes. I believe programmers in general and language zealots in particular underestimate how hard it is for a team to ramp up productively in a new language, and overestimate how productive the team will be once they have ramped up. In other words, the productivity bottleneck in programming is seldom the language itself.
Heres a nasty take that I am sure people will hate:
I love Go if I need async, the runtime genuinely helps a lot: even with the slice semantics I despise that allow for interior mutability in unexpected situations.
I love Rust for basically everything else; but I avoid async like the plague.
The Rust toolchain is just so excellent that I always miss it when writing Go, but Go’s async is first class. Rusts feels like pulling teeth.
… and they’re so good at it that people say “I wasn’t aware that Go had async”; nearly all the async stuff just kinda vanishes in go - having a runtime that can suspend a goroutine means you can just write blocking code and not think about it.
I agree that a bare go statement is almost always a code smell - I’d go as far as to compare it to unsafe in rust.
However, I can count on one hand the number of times I’ve needed to use one as an applications developer. For instance, the net/http server is concurrent, but unless you go source-diving through the stdlib you wouldn’t see any concurrency primitives.
Of those times I’ve used one, all have been for parallel-processing a loop - which doesn’t let goroutines outlive the calling function, and provides a straightforward way to propagate errors, and therefore doesn’t break the function-call abstraction.
That’s fair, but bear in mind that asking people to practice structured programming only helps so much, in the same way that asking people to practice memory-safe C++ coding practices only helps so much.
In the end, there’s a reason C only allowed structuredGOTO (i.e. you can’t jump into the middle of another function), rather than the unstructured GOTO of things like assembly language that Dijkstra was writing about. If Go’s big reason for limiting language complexity and leaning on boilerplate is to limit the harm novice team members can cause, then having go instead of some more structured construct is questionable at best.
I ran into a bunch of problems with goroutines and asked around back when I was still writing golang whether it was documented anywhere how to use them as a non-footgun… and after some searching around I was pointed to an obscure webpage with patterns to follow.
Do they? Goroutines are a lightweight, cooperatively scheduled thread. Async/await is a stripped down version of coroutines. Coroutines were originally added to Simula to make writing the interleaving of agents acting on each other straightforward and they come with a bunch of built-in stuff about plumbing data and resuming frames. Even the wimpy async/await version still retains some default plumbing that isn’t completely trivial to do with channels.
It doesn’t have the async keyword but the language is deeply integrated with async I/O. Brad Fitzpatrick once told me “go is my favorite epoll library”.
async fn fetch_lat_long(city: &str) -> Result<LatLong, Box<dyn std::error::Error>> {
let endpoint = format!(
"https://geocoding-api.open-meteo.com/v1/search?name={}&count=1&language=en&format=json",
city
);
let response = reqwest::get(&endpoint).await?.json::<GeoResponse>().await?;
response
.results
.get(0)
.cloned()
.ok_or("No results found".into())
}
The code is a bit less verbose than the Go version. We don’t have to write if err != nil constructs, because we can use the ? operator to propagate errors.
That’s a library choice, not a language issue. Here’s what this would look like in Go with requests:
And that’s with the rust code having a library that seperates out getting a request and parsing the response (with two sets of errors to handle), while you have a go library that does all of that in one call (with one set of errors to handle). If the rust library was more like the go library, you would only have one question mark worth of error handling. If the go library was more like the rust library, you’d have two sets (six lines) of if err != nil ....
Personally I think that more important than the verbosity called out in the quote is that in the rust version you can’t forget to handle the errors, while in the go version you can.
There’s a library called try that can reduce the boilerplate a little. It would look like this:
func get[E any](s []E, i int) (e E, error error) {
if i >= len(s) {
err = fmt.Errorf("out of range"))
return
}
return s[i], nil
}
func getLatLong(city string) (pos *LatLong, err error) {
defer try.Handle(&err)
var response GeoResponse
try.E(requests.
URL("https://geocoding-api.open-meteo.com/v1/search?count=1&language=en&format=json").
Params("name", city).
ToJSON(&response).
Fetch(context.Background()))
loc := try.E1(get(response.Results, 0))
return &loc, nil
}
That said, I don’t think the library will really catch on because Gophers mostly like the boilerplate. It is more verbose, but it’s easy to read and not that hard to type. There was a proposal to add try to the language from the language maintainers, and the community didn’t like it, so it didn’t go anywhere.
Personally I think that more important than the verbosity called out in the quote is that in the rust version you can’t forget to handle the errors, while in the go version you can.
This has become a big Rust talking point, and I can’t understand why. It just doesn’t happen with any significant frequency that people forget to do error handling in real code. If you’re paranoid, there’s a common linter called errcheck that will check it for you, but I haven’t found a need for it. A much better talking point would be that in Go, nothing keeps you from accidentally creating a race condition across Goroutines, which is a real problem.
Incidentally, AFAICT, the Rust code has a security bug. Unless format! is URL specific (I don’t think so?), this would allow query parameters to break out:
let endpoint = format!(
"https://geocoding-api.open-meteo.com/v1/search?name={}&count=1&language=en&format=json",
city
);
This bug isn’t Rust specific, but it just shows that no language can save you from all possible bugs if you do things wrong.
This has become a big Rust talking point, and I can’t understand why.
I mean, I personally have fixed bugs in production go code at a company I was working for that happened as a result of ignoring err… which tends to make me think it matters. Maybe that was exceptional for some reason, but I don’t see any reason to think so.
And yes you’re right about that format statement. I’m certainly not claiming that rust eliminates all bugs, but that doesn’t mean that it isn’t better to have a language that doesn’t have a class of bugs than one that does have that same class.
…that doesn’t mean that it isn’t better to have a language that doesn’t have a class of bugs than one that does have that same class.
All else equal, sure, but all else is never equal 😉 Every benefit carries a cost. It can definitely be the case that the benefits of preventing a class of bugs at the language level are outweighed by the costs required to provide that feature.
Since we are a platform-as-a-service provider, we think that we can contribute the most by showing you how to build a small web service in both languages.
In 99% of cases, everything else being equal, Go works best in this scenario. Main benefit of Rust is memory safety without GC overhead, and it’s almost never worth it if network latencies are present.
I disagree. To me, the main benefit of Rust is that it’s much more unlikely I’ll have to deal with an essential service having gone down at 3AM.
That and the ability to easily expose bindings to tons of languages so I can reuse code are why I use Rust in place of “shell scripts” (actually Python these days) so often. Rust, like Haskell, surfaces as much as possible at compile time but, unlike Haskell, has an ecosystem leaning more toward “fearless upgrades” and less toward pushing the state of the art at the expense of a little API breakage.
My personal experience between the two languages was that CPU/latency differences were small (10-20%) but memory consumption differences were huge (4-5x). Even with the cost of network hops, at a certain scale the OpEx differences can be huge.
based on my own personal (anecdotal) experience, small to medium sized projects take N minutes to compile via rust, and N seconds to compile via go.
after initial compilation, subsequent compilations will still take longer in rust, but it’s much more comparable (both languages do some caching to make things faster here).
If the article authors would provide the source code repositories we could easily measure the how long it would, but based on my personal experience the difference in compile times is huge. Go compile times are usually in the single digit seconds range, except for projects using a lot of Cgo or if they’re very large, like Kubernetes.
Could I politely yes, and … ? Yes, the go compiler is faster, but in my experience, any large go project will use linters, many of them. Linting is slow. The linters catch many errors, like not checking a returned error which the rust compiler requires you to check. I suppose that means you can get an executable quickly, but I feel comparing Go’s compilation speed vs rust without linting doesn’t capture real world usage.
In my experience, the speed of the Go compiler allows you to move quickly during development. And yes, you do spend a few extra seconds linting before committing your code or cutting a release. I don’t typically run the compiler and linter in lock step.
During development, we tend to compile frequently but lint less often. This is especially true if you’re already using VSCode or Goland for incremental linting.
in case the author is reading this, i have a few corrections (i’ll add more via edits as i read):
there is a small typo in the code block under the text “For a start, let’s call these two functions in order and print the result:”: func main() func main()
the link attached for this "Go by Example" article is incorrect, it should point to https://gobyexample.com/time
There’s also a markup typo on the Go Routing section. Look for “Which one you want to use depends on your use case”, that is probably meant to be outside the code snippet.
I really don’t want to be this grumpy old man, but.. can we just stop comparing this two, completely unrelated languages? Where are all the Zig vs Haskell posts? It makes just as much sense. Go is simply not a low-level language, and it was never meant to occupy the same niches as Rust, that makes deliberate design tradeoffs to be able to target those use cases.
With that said, I am all for managed languages (though I would lie if I said that I like Go - would probably be my last choice for almost anything), and thankfully they can be used for almost every conceivable purpose (even for an OS, see Microsoft’s attempts), the GC is no problem for the vast majority of tasks. But we should definitely be thankful for Rust as it really is a unique language for the less often targeted non-GC niche.
i would read a zig vs haskell post
You should understand the context a little bit: Shuttle is a company focused on deploying backend applications in Rust. Backend applications (server programs) is precisely the main use-case for Go. It absolutely makes sense for them to compare the two in this context.
Java is an even more common choice for backend development, but fair enough.
My gripe is actually the common, hand-in-hand usage of this “rust’n’go” term, which I’m afraid is more often than not depends on a misconception around Go’s low-levelness, as it was sort of marketed as a systems language.
It is a “systems language”… by the original definition where low-levelness was a side-effect of the times and the primary focus was long-term maintainability and suitability for building infrastructural components.
(Which, in the era of network microservices, is exactly what Go was designed for. Java, Go, and Rust are three different expressions of the classical definition of a “systems language”.)
That said, there has been a lot of misconception because it’s commonly repeated that Go was created “to replace C++ as Google uses it”… which basically means “to replace Python and Ruby in contexts where they can’t scale enough, so you used C++ instead”.
Great link, thanks!
BTW Rob Pike is cited in it where he regrets calling Go a systems language, but that’s probably because he used it in the original sense, and the meaning has drifted.
Go was originally designed as a successor to C. The fact that it’s been most successful as a Python replacement was largely accidental. It does (via the unsafe package) support low-level things but, like Rust, tries to make you opt in for the small bits of code that actually need them.
Go had three explicit, publicized design goals from the start; none of them were “be a successor to C”.
They were written relative to the three languages in use at google:
Rob Pike was pretty explicit that it was intended as a C successor. He said this several times in various things that I heard and read while writing the Go Phrasebook. His goal was to move C programmers to a language with a slightly higher level of abstraction. He sold it to Google relative to their current language usage.
In that case, I suppose I must defer to your closer experience!
They really dropped the ball on that expressivity part. It’s as expressive as C, which is.. not a good thing.
The article is about a DB-backed microservice. I’m curious whether you feel rust or go is inappropriate for this domain.
I appreciate that the Go code here is Actually Good™ — it uses proper types, has proper function signatures, and does proper error handling. Thank you!
The overlap in use cases for these two languages is way smaller than people seem to think
I do distributed systems and web, and learning Rust made Go an obsolete language as far as I’m concerned. I legit can not think of a use case where I would pick Go over Rust.
Having a team that doesn’t already know Rust is at least one reason I can think of. It takes much less time to get a team up to speed on Go than it does on Rust. Maybe compilation/test speed (eg. development velocity) is another.
You are not wrong, but a team knowing one language and not the other can be used to justify any language :)
Well, yes. I believe programmers in general and language zealots in particular underestimate how hard it is for a team to ramp up productively in a new language, and overestimate how productive the team will be once they have ramped up. In other words, the productivity bottleneck in programming is seldom the language itself.
Heres a nasty take that I am sure people will hate:
I love Go if I need async, the runtime genuinely helps a lot: even with the slice semantics I despise that allow for interior mutability in unexpected situations.
I love Rust for basically everything else; but I avoid async like the plague.
The Rust toolchain is just so excellent that I always miss it when writing Go, but Go’s async is first class. Rusts feels like pulling teeth.
Complaining about Rust async has become something of a bandwagon. I write a small web app in Axum and things are… fine.
What is Go’s async? I wasn’t aware that Go had async.
goroutines and channels are essentially solving the problem async seeks to solve.
… and they’re so good at it that people say “I wasn’t aware that Go had async”; nearly all the async stuff just kinda vanishes in go - having a runtime that can suspend a goroutine means you can just write blocking code and not think about it.
However, an argument can also be made that they’re the
GOTOstatement of concurrency and suffer from the same control flow and maintainability issues.I agree that a bare
gostatement is almost always a code smell - I’d go as far as to compare it tounsafein rust.However, I can count on one hand the number of times I’ve needed to use one as an applications developer. For instance, the net/http server is concurrent, but unless you go source-diving through the stdlib you wouldn’t see any concurrency primitives.
Of those times I’ve used one, all have been for parallel-processing a loop - which doesn’t let goroutines outlive the calling function, and provides a straightforward way to propagate errors, and therefore doesn’t break the function-call abstraction.
I maintain a “pithy” Go style guide, and this is almost verbatim what I recommend in one of the concurrency sections.
This is closely related to a section about API design.
That’s fair, but bear in mind that asking people to practice structured programming only helps so much, in the same way that asking people to practice memory-safe C++ coding practices only helps so much.
In the end, there’s a reason C only allowed structured
GOTO(i.e. you can’t jump into the middle of another function), rather than the unstructuredGOTOof things like assembly language that Dijkstra was writing about. If Go’s big reason for limiting language complexity and leaning on boilerplate is to limit the harm novice team members can cause, then havinggoinstead of some more structured construct is questionable at best.To be fair, structured concurrency is much easier to accomplish (and check for during review) than memory-safe C++.
I ran into a bunch of problems with goroutines and asked around back when I was still writing golang whether it was documented anywhere how to use them as a non-footgun… and after some searching around I was pointed to an obscure webpage with patterns to follow.
With which I’d like to say: 👏🏼
Do they? Goroutines are a lightweight, cooperatively scheduled thread. Async/await is a stripped down version of coroutines. Coroutines were originally added to Simula to make writing the interleaving of agents acting on each other straightforward and they come with a bunch of built-in stuff about plumbing data and resuming frames. Even the wimpy async/await version still retains some default plumbing that isn’t completely trivial to do with channels.
It doesn’t have the async keyword but the language is deeply integrated with async I/O. Brad Fitzpatrick once told me “go is my favorite epoll library”.
I’m guessing they mean channels.
That’s a library choice, not a language issue. Here’s what this would look like in Go with requests:
It’s only longer because there’s no chaining equivalent of
.get(0)in Go.The point about the question mark operator still stands, these three lines of code
Are just the two question marks in this line of rust (not the rest of the code on the line, literally just those two individual characters).
And that’s with the rust code having a library that seperates out getting a request and parsing the response (with two sets of errors to handle), while you have a go library that does all of that in one call (with one set of errors to handle). If the rust library was more like the go library, you would only have one question mark worth of error handling. If the go library was more like the rust library, you’d have two sets (six lines) of
if err != nil ....Personally I think that more important than the verbosity called out in the quote is that in the rust version you can’t forget to handle the errors, while in the go version you can.
There’s a library called try that can reduce the boilerplate a little. It would look like this:
That said, I don’t think the library will really catch on because Gophers mostly like the boilerplate. It is more verbose, but it’s easy to read and not that hard to type. There was a proposal to add
tryto the language from the language maintainers, and the community didn’t like it, so it didn’t go anywhere.This has become a big Rust talking point, and I can’t understand why. It just doesn’t happen with any significant frequency that people forget to do error handling in real code. If you’re paranoid, there’s a common linter called errcheck that will check it for you, but I haven’t found a need for it. A much better talking point would be that in Go, nothing keeps you from accidentally creating a race condition across Goroutines, which is a real problem.
Incidentally, AFAICT, the Rust code has a security bug. Unless
format!is URL specific (I don’t think so?), this would allow query parameters to break out:This bug isn’t Rust specific, but it just shows that no language can save you from all possible bugs if you do things wrong.
I mean, I personally have fixed bugs in production go code at a company I was working for that happened as a result of ignoring err… which tends to make me think it matters. Maybe that was exceptional for some reason, but I don’t see any reason to think so.
And yes you’re right about that format statement. I’m certainly not claiming that rust eliminates all bugs, but that doesn’t mean that it isn’t better to have a language that doesn’t have a class of bugs than one that does have that same class.
All else equal, sure, but all else is never equal 😉 Every benefit carries a cost. It can definitely be the case that the benefits of preventing a class of bugs at the language level are outweighed by the costs required to provide that feature.
In 99% of cases, everything else being equal, Go works best in this scenario. Main benefit of Rust is memory safety without GC overhead, and it’s almost never worth it if network latencies are present.
I disagree. To me, the main benefit of Rust is that it’s much more unlikely I’ll have to deal with an essential service having gone down at 3AM.
That and the ability to easily expose bindings to tons of languages so I can reuse code are why I use Rust in place of “shell scripts” (actually Python these days) so often. Rust, like Haskell, surfaces as much as possible at compile time but, unlike Haskell, has an ecosystem leaning more toward “fearless upgrades” and less toward pushing the state of the art at the expense of a little API breakage.
My personal experience between the two languages was that CPU/latency differences were small (10-20%) but memory consumption differences were huge (4-5x). Even with the cost of network hops, at a certain scale the OpEx differences can be huge.
How did you measure memory consumption?
It’s been long enough that I’ve forgotten the details, and it was a past job. I’m pretty sure I used one of the Datadog memory metrics.
What are build times like for go compared to rust? Is it faster for comparably sized large projects?
based on my own personal (anecdotal) experience, small to medium sized projects take N minutes to compile via rust, and N seconds to compile via go.
after initial compilation, subsequent compilations will still take longer in rust, but it’s much more comparable (both languages do some caching to make things faster here).
moldis our savior.Yes.
If the article authors would provide the source code repositories we could easily measure the how long it would, but based on my personal experience the difference in compile times is huge. Go compile times are usually in the single digit seconds range, except for projects using a lot of Cgo or if they’re very large, like Kubernetes.
Could I politely yes, and … ? Yes, the go compiler is faster, but in my experience, any large go project will use linters, many of them. Linting is slow. The linters catch many errors, like not checking a returned error which the rust compiler requires you to check. I suppose that means you can get an executable quickly, but I feel comparing Go’s compilation speed vs rust without linting doesn’t capture real world usage.
In my experience, the speed of the Go compiler allows you to move quickly during development. And yes, you do spend a few extra seconds linting before committing your code or cutting a release. I don’t typically run the compiler and linter in lock step.
During development, we tend to compile frequently but lint less often. This is especially true if you’re already using VSCode or Goland for incremental linting.
Linting and compiling are completely decoupled. You can do them in parallel if you’d like.
Linters are usually just as fast as the compiler, O(seconds).
in case the author is reading this, i have a few corrections (i’ll add more via edits as i read):
there is a small typo in the code block under the text “For a start, let’s call these two functions in order and print the result:”:
func main() func main()the link attached for
this "Go by Example" articleis incorrect, it should point to https://gobyexample.com/timeThere seems to be a markup issue around:
Unnecessary space between ] and (
Thanks so much for the feedback! We’ve updated the article to address the changes.
yay! thanks for writing it, it was a fun read.
There’s also a markup typo on the Go Routing section. Look for “Which one you want to use depends on your use case”, that is probably meant to be outside the code snippet.