Although I’m glad this article explicitly distinguishes uses of Go and Rust, I still don’t understand why people keep trying to compare these two languages. They clearly have different approaches to different goals.
When we first announced Go, we called it a systems programming language, and I slightly regret that because a lot of people assumed it was an operating systems writing language. What we should have called it is a server writing language, which is what we really thought of it as.
—Rob Pike (Go creator)
Writing client-side applications. The polar opposite of what Go is designed for. In these applications, you have high latency needs, high security requirements, a lot of requirements that don’t come up on the server side.
—Niko Matsakis (Rust dev)
I still don’t understand why people keep trying to compare these two languages.
I think this is very simple. For a long time people dreaded writing C++ and were looking for a(n imperative) language that compiles to native binaries. Then there were (some time apart) Go and Rust [1]. Both languages filled the ‘a more modern language that compiles to native code’-niche. People start to compare them, besides being very different languages.
Besides that, they have overlapping niches where they excel, such as command-line tools.
[1] Of course, there were many other alternatives, such as OCaml, Haskell, D, Ada, etc. But they never attained critical mass.
Obviously, there is no fixed definition. But it’s clear that a language must have an library ecosystem of a certain size, IDE support, documentation, availability of programmers, etc. before any random given company will seriously consider it for their next project.
Whether these are well-justified reasons is another question. Whatsapp used Erlang and was a fraction employee-wise from many social network competitors and created a crazy amount of value (for the owners and shareholders).
How is “Go is easier to build large scale systems in than Python or Ruby” any more subjective than “Rust is easier to understand C++”? If anything, I’d argue that while both are subjective claims, the former is less subjective, just because static typing is widely considered an advantage when it comes to large scale systems.
To your meta comment, I am aping the “What Languages Fix” style of language property identification, which is necessarily subjective.
To the point itself, I think the notion that a language designed from first principles to support the practice of software engineering in large organizations is better at doing so than dynamically-typed, interpreted, prototyping languages like Python and Ruby is about as noncontroversial as subjective claims can be. And, for the record, reliably borne out by the vast majority of experience reports.
And, for the record, reliably borne out by the vast majority of experience reports.
I’ve also seen experience reports suggesting that Ruby and/or Python are the most productive. Unless you can point to a broad study, from an unbiased researcher (spoiler: does not exist), it’s an opinion.
BTW, static vs dynamic typing is the most hilarious “it just is, duh” response ever. That’s the pinnacle of flame war arguments on this topic.
A long time ago, Rust was actually much more similar to Go. Then the Rust developers decided that they didn’t need green threads and didn’t need a garbage collector because “a memory-safe programming language with no runtime!!!111*” is way cooler than “yet another Ocaml rehash, with this one weird type system trick!!!111”.
That and they’re both released by web companies, so web developers have inevitably heard of both.
* no additional runtime beyond what C requires, actually
They were completely right, a memory-safe programming language with no runtime is in fact way cooler than yet another Ocaml rehash. In the specific sense that such a language genuinely didn’t exist and huge amounts of systems software were written in memory-unsafe C and C++ for lack of a better alternative.
Lastly, going back to our story, not all “Why not Rust” questions should be interpreted like in the example above. Sometimes the chilling wind is just in your head and the people asking the dreaded question just want to know your opinion. Let’s avoid tying our identity to a single language and embrace practicality first and foremost. Tribal names like Rustacean or Gopher should be avoided, as they are inherently a marketing tool for inducing stronger branding.
This is the most important insight in the article. Well, I don’t actually have a problem with the terms “Rustacean” or “Gopher”, and I would oppose stigmatizing people who do use those words. But I definitely oppose building a tribal identity around what programming you use, precisely because it should be possible to compare the merits of different languages, or even harshly criticize some programming languages, without that being an attack on the identity of the people who use them. Saying that Rust is in general better than Go, but Go might be better from some specific programming tasks (which is basically my own opinion) should be no more an attack on the identity of programmers than saying that one brand of hammer is better than another brand of hammer in most cases should be be an attack on the identity of carpenters.
Unless you have very specific needs, I feel like the best answer should be; “why not?”. Both languages, (and C#, Java, …) are adequate to build web services. As long as the language is productive to you and your team, this is more important than picking the latest hip language.
The irony here is we have Kay’s vision of networked objects while also caring deeply about the implementation details of those objects, which, we shouldn’t have to care about.
Its a marketing phrase, and states the situation incorrectly and oversimplified, and undercuts the author’s criticism about the “Rust fandom”. C++ has a lot of features, so being “better” overall would be extremely hard to quantify. If I wanted a “better C++”, I’d use a newer C++ standard, and some people even argue if these are “better”.
Many would considering using a terser language with higher-level abstractions and good performance as an alternative to C++.
How can you claim with a straight face that Go is better at concurrency than Java and C# when Go only has green threads, and no user-level control whatsoever on the execution model? That is particularly important for server-side applications where you might need to separate IO-bound tasks from CPU-bound tasks inside the same process.
Go is excellent at writing server-side applications where you need to separate IO-bound and CPU-bound tasks in the same process. The runtime does it all for you, without requiring you to complect your application code with irrelevant details like thread execution models.
complect your application code with irrelevant details like thread execution models.
It’s very disingenous to dismiss threading control as “irrelevant”. If that would be the case, what’s this?
In a web server that simultaneously does some non-blocking and blocking IO (files and the like) and then also some CPU bound stuff, how can the Go scheduler guarantee the web server can function independently and not be interrupted by the scheduler trying to find a thread that isn’t blocked? This is not a terribly complex thing to solve with user-level control on threads and thread pools, but it becomes quite daunting with only green threads and pre-emption.
I’m not saying this can’t be done using green threads but it is difficult. GIven user control on threading you can implement your own runtime for fibers and continuations, but you can’t do that if you only have access to green threads!
I don’t see how the linked issue is relevant. It’s about how Linux does not support non-blocking file I/O, so Go needs a kernel-level thread for each goroutine with a blocking file I/O operation. It’s exactly the same thing in Java and C#: If you want to run tons of file I/O in parallel, you will need tons of kernel-level threads.
It’s also untrue, though; why did Google make a new HTTP/2 implementation in their Go gRPC libraries when, y’know, there’s the Go stdlib? (These days there’s a function you can call that lets you use the Go-native one, but “Performance and features may vary between the two paths. ServeHTTP does not support some gRPC features available through grpc-go’s HTTP/2 server, and it is currently EXPERIMENTAL and subject to change.”)
What Google hands out as open source is often inferior to what they use internally.
I try never to entertain simplistic questions like “why not X?” because they often reinforce an asymmetry of bullshit. They’re not specific and they derail what could be a value q&a into combative zealotry.
If you want an answer other than “because that’s what I chose”, be more specific.
The author culminates with a statement of which is “better”. In programming languages there is no “better”, and to claim such is naive. There is only better “suited” to the particular problem or system to be represented or modeled.
I feel there is a place for both Go and Rust.
Not sure why there is so much comparisons being made between them. Is it just because they are trendy at the same time?
Although I’m glad this article explicitly distinguishes uses of Go and Rust, I still don’t understand why people keep trying to compare these two languages. They clearly have different approaches to different goals.
From the panel Systems Programming Languages in 2014 and Beyond:
I still don’t understand why people keep trying to compare these two languages.
I think this is very simple. For a long time people dreaded writing C++ and were looking for a(n imperative) language that compiles to native binaries. Then there were (some time apart) Go and Rust [1]. Both languages filled the ‘a more modern language that compiles to native code’-niche. People start to compare them, besides being very different languages.
Besides that, they have overlapping niches where they excel, such as command-line tools.
[1] Of course, there were many other alternatives, such as OCaml, Haskell, D, Ada, etc. But they never attained critical mass.
I’m looking at Crystal currently, as a possible contender in this field (GC, native, fast, and expressive). Looks very promising.
What qualifies as critical mass? The languages you cite are all self-sustaining, even if their ecosystems don’t grow at the same speed.
Obviously, there is no fixed definition. But it’s clear that a language must have an library ecosystem of a certain size, IDE support, documentation, availability of programmers, etc. before any random given company will seriously consider it for their next project.
Whether these are well-justified reasons is another question. Whatsapp used Erlang and was a fraction employee-wise from many social network competitors and created a crazy amount of value (for the owners and shareholders).
Critical mass such that people need to write blog posts clarifying “why go and not x”?
Go is faster than Python.
Rust is safer than C, and, once you get the ownership concept down, safer and easier to understand than C++.
(This post is unapologetically in the style of Paul Graham’s ha-ha-only-serious essay “What Languages Fix” which is still a pretty good read.)
Go is faster and easier to build large scale systems in than Python or Ruby.
That’s pretty subjective. Can we stick to quantitatively verified facts instead of playing “my X can beat up your X,” please?
How is “Go is easier to build large scale systems in than Python or Ruby” any more subjective than “Rust is easier to understand C++”? If anything, I’d argue that while both are subjective claims, the former is less subjective, just because static typing is widely considered an advantage when it comes to large scale systems.
It’s not. I should have also replied to the other post, too.
To your meta comment, I am aping the “What Languages Fix” style of language property identification, which is necessarily subjective.
To the point itself, I think the notion that a language designed from first principles to support the practice of software engineering in large organizations is better at doing so than dynamically-typed, interpreted, prototyping languages like Python and Ruby is about as noncontroversial as subjective claims can be. And, for the record, reliably borne out by the vast majority of experience reports.
I’ve also seen experience reports suggesting that Ruby and/or Python are the most productive. Unless you can point to a broad study, from an unbiased researcher (spoiler: does not exist), it’s an opinion.
BTW, static vs dynamic typing is the most hilarious “it just is, duh” response ever. That’s the pinnacle of flame war arguments on this topic.
A long time ago, Rust was actually much more similar to Go. Then the Rust developers decided that they didn’t need green threads and didn’t need a garbage collector because “a memory-safe programming language with no runtime!!!111*” is way cooler than “yet another Ocaml rehash, with this one weird type system trick!!!111”.
That and they’re both released by web companies, so web developers have inevitably heard of both.
* no additional runtime beyond what C requires, actually
They were completely right, a memory-safe programming language with no runtime is in fact way cooler than yet another Ocaml rehash. In the specific sense that such a language genuinely didn’t exist and huge amounts of systems software were written in memory-unsafe C and C++ for lack of a better alternative.
The author had me on board in the first half of the article where he was trying to explain why the oversimplifying “x is better than y” is fanboyism.
Then he proceeds to do the same comparing Go to two other languages without comment and context :facepalm:
Author also didn’t need to use the hypothetical Rust zealot as a plot device.
This is the most important insight in the article. Well, I don’t actually have a problem with the terms “Rustacean” or “Gopher”, and I would oppose stigmatizing people who do use those words. But I definitely oppose building a tribal identity around what programming you use, precisely because it should be possible to compare the merits of different languages, or even harshly criticize some programming languages, without that being an attack on the identity of the people who use them. Saying that Rust is in general better than Go, but Go might be better from some specific programming tasks (which is basically my own opinion) should be no more an attack on the identity of programmers than saying that one brand of hammer is better than another brand of hammer in most cases should be be an attack on the identity of carpenters.
Unless you have very specific needs, I feel like the best answer should be; “why not?”. Both languages, (and C#, Java, …) are adequate to build web services. As long as the language is productive to you and your team, this is more important than picking the latest hip language.
The irony here is we have Kay’s vision of networked objects while also caring deeply about the implementation details of those objects, which, we shouldn’t have to care about.
… unless you’re the one implementing those details…
As a C++ dev, who also uses Rust, this irks me.
Its a marketing phrase, and states the situation incorrectly and oversimplified, and undercuts the author’s criticism about the “Rust fandom”. C++ has a lot of features, so being “better” overall would be extremely hard to quantify. If I wanted a “better C++”, I’d use a newer C++ standard, and some people even argue if these are “better”.
Many would considering using a terser language with higher-level abstractions and good performance as an alternative to C++.
How can you claim with a straight face that Go is better at concurrency than Java and C# when Go only has green threads, and no user-level control whatsoever on the execution model? That is particularly important for server-side applications where you might need to separate IO-bound tasks from CPU-bound tasks inside the same process.
Go is excellent at writing server-side applications where you need to separate IO-bound and CPU-bound tasks in the same process. The runtime does it all for you, without requiring you to complect your application code with irrelevant details like thread execution models.
It’s very disingenous to dismiss threading control as “irrelevant”. If that would be the case, what’s this?
In a web server that simultaneously does some non-blocking and blocking IO (files and the like) and then also some CPU bound stuff, how can the Go scheduler guarantee the web server can function independently and not be interrupted by the scheduler trying to find a thread that isn’t blocked? This is not a terribly complex thing to solve with user-level control on threads and thread pools, but it becomes quite daunting with only green threads and pre-emption.
I’m not saying this can’t be done using green threads but it is difficult. GIven user control on threading you can implement your own runtime for fibers and continuations, but you can’t do that if you only have access to green threads!
I don’t see how the linked issue is relevant. It’s about how Linux does not support non-blocking file I/O, so Go needs a kernel-level thread for each goroutine with a blocking file I/O operation. It’s exactly the same thing in Java and C#: If you want to run tons of file I/O in parallel, you will need tons of kernel-level threads.
Animats’ comment hits on an important advantage of Go that Rust will take a while to achieve.
It’s also untrue, though; why did Google make a new HTTP/2 implementation in their Go gRPC libraries when, y’know, there’s the Go stdlib? (These days there’s a function you can call that lets you use the Go-native one, but “Performance and features may vary between the two paths. ServeHTTP does not support some gRPC features available through grpc-go’s HTTP/2 server, and it is currently EXPERIMENTAL and subject to change.”)
What Google hands out as open source is often inferior to what they use internally.
Oh yeah, I forgot they do that. Then, just whatever parts they were using heavily and needed to work right.
I try never to entertain simplistic questions like “why not X?” because they often reinforce an asymmetry of bullshit. They’re not specific and they derail what could be a value q&a into combative zealotry.
If you want an answer other than “because that’s what I chose”, be more specific.
The author culminates with a statement of which is “better”. In programming languages there is no “better”, and to claim such is naive. There is only better “suited” to the particular problem or system to be represented or modeled.
Ok guys, enough jokes, but seriously , why not C++.
Cuz Flow gave us FoundationDB. It was crazy good on the QA side vs most. Wait, that’s still C++ in a way. ;)
I feel there is a place for both Go and Rust. Not sure why there is so much comparisons being made between them. Is it just because they are trendy at the same time?