Why Go and Rust are not competitors(dave.cheney.net)
dave.cheney.net
Why Go and Rust are not competitors
http://dave.cheney.net/2015/07/02/why-go-and-rust-are-not-competitors
12 comments
No, they meant Go was intended as a systems language. Rob Pike:
http://commandcenter.blogspot.com/2012/06/less-is-exponentia...
> I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.
> We—Ken, Robert and myself—were C++ programmers when we designed a new language to solve the problems that we thought needed to be solved for the kind of software we wrote. It seems almost paradoxical that other C++ programmers don't seem to care.
Read the whole thing if you have time - Pike talks about how they were trying to write a language that filled a role similar to C and C++. So they came up with a compiled, statically typed language.
http://commandcenter.blogspot.com/2012/06/less-is-exponentia...
> I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.
> We—Ken, Robert and myself—were C++ programmers when we designed a new language to solve the problems that we thought needed to be solved for the kind of software we wrote. It seems almost paradoxical that other C++ programmers don't seem to care.
Read the whole thing if you have time - Pike talks about how they were trying to write a language that filled a role similar to C and C++. So they came up with a compiled, statically typed language.
I've read that and I disagree with your interpretation.
Google was using C++ in the "systems management" of their datacenters. Rob Pike is using a Google-idiosyncratic definition of "systems".
I do believe that Google did use C++ for many classic low-level scenarios (e.g. writing custom Linux device drivers, failover code, etc) but they were also using C++ for "high-level" systems orchestrations and batch jobs. It's the "high-level" uses of C++ that that Rob Pike successfully addressed with Golang.
I'm saying a large percentage of programmers outside the Google bubble think of "systems" as low-level stuff like realtime embedded, low-latency device drivers, etc that require zero-cost abstractions. Rob Pike did not design Go's semantics & runtime for those use cases.
Google was using C++ in the "systems management" of their datacenters. Rob Pike is using a Google-idiosyncratic definition of "systems".
I do believe that Google did use C++ for many classic low-level scenarios (e.g. writing custom Linux device drivers, failover code, etc) but they were also using C++ for "high-level" systems orchestrations and batch jobs. It's the "high-level" uses of C++ that that Rob Pike successfully addressed with Golang.
I'm saying a large percentage of programmers outside the Google bubble think of "systems" as low-level stuff like realtime embedded, low-latency device drivers, etc that require zero-cost abstractions. Rob Pike did not design Go's semantics & runtime for those use cases.
I don't think Rust is designed for those use cases either, honestly.
You don't think Rust is suitable for writing device drivers or realtime stuff? Why is that?
Well, no, that's not what I said. I said it's not designed for those use-cases -- if Go is 'designed for systems programming at Google', then Rust is 'designed for systems programming at Mozilla', which if anything is further from the metal than a lot of what happens at Google. I think Rust made a lot of design decisions that probably makes it better for those use cases than Go. But there have been people who have tried to write low-level OS code in Rust and found some significant pain points:
http://scialex.github.io/reenix.pdf
Now, some people who know a lot more about Rust than I do have said these are problems that can be solved in Rust, and I have no reason to disbelieve them. But I don't think writing that sort of stuff was a design focus of the language, compared to writing the sort of large user-space applications that are currently written in C and C++.
http://scialex.github.io/reenix.pdf
Now, some people who know a lot more about Rust than I do have said these are problems that can be solved in Rust, and I have no reason to disbelieve them. But I don't think writing that sort of stuff was a design focus of the language, compared to writing the sort of large user-space applications that are currently written in C and C++.
Fun story about the history of that paper:
We used to think Rust needed a runtime to be safe, so it had one. There was an attribute, #[no_std], which would not link in the runtime, and also get rid of the standard library. As such, the decision was made for std that it should just panic on OOM, because you'd be clearly writing an application, and generally, you don't even seen OOM in that use-case.
Fast forward a few years, and we remove the runtime, and suddenly, it's not impossible to use std to build things like operating systems. So now, people use it this way, and see that it might not be well-suited to that purpose.
So in some ways, the claims put forth by that paper are historical accidents. Which doesn't mean that they're not interesting, or valid, it's just that an additional possibility came up, which challenged a design assumption.
We absolutely do care about the lowest-level case with Rust, and had a number of discussions at the workweek (Mozilla all-hands, full week of meetings) to talk about how to improve the "I'm writing a kernel" case with Rust.
We used to think Rust needed a runtime to be safe, so it had one. There was an attribute, #[no_std], which would not link in the runtime, and also get rid of the standard library. As such, the decision was made for std that it should just panic on OOM, because you'd be clearly writing an application, and generally, you don't even seen OOM in that use-case.
Fast forward a few years, and we remove the runtime, and suddenly, it's not impossible to use std to build things like operating systems. So now, people use it this way, and see that it might not be well-suited to that purpose.
So in some ways, the claims put forth by that paper are historical accidents. Which doesn't mean that they're not interesting, or valid, it's just that an additional possibility came up, which challenged a design assumption.
We absolutely do care about the lowest-level case with Rust, and had a number of discussions at the workweek (Mozilla all-hands, full week of meetings) to talk about how to improve the "I'm writing a kernel" case with Rust.
I think what matters is: outside the organization where the certain language was invented what is the the most users use it for.
Aka: outside Google what is Go used for? Mostly web related project and low level IO, databases, data stores, etc.; based on the popular Go projects on Github, if somebody has time it would be good to see some stats on this
outside Mozilla what is Rust used for? This is a more tricky question because the most programmers I know of do not consider a language for anything before 1.0. Rust 1.0 just got released recently so they have years to go to have relevant stats about the usage patterns.
Aka: outside Google what is Go used for? Mostly web related project and low level IO, databases, data stores, etc.; based on the popular Go projects on Github, if somebody has time it would be good to see some stats on this
outside Mozilla what is Rust used for? This is a more tricky question because the most programmers I know of do not consider a language for anything before 1.0. Rust 1.0 just got released recently so they have years to go to have relevant stats about the usage patterns.
Just to be clear: it would not be possible to attempt to write that paper in Go. That is what people mean.
That one single statement "systems programing language" bit Go more than anything probably as far as expectations and the number of words generated in blog posts talking about Go.
It was funny that the first response to "Oh but it can't compete with C" was "Well, we meant systems programming language to be more like back-end web servers not your traditional systems programming..." Now, had that come from other people I might have believed, but I cannot imagine Ken and Rob had no idea what a systems programming language was and just got a little confused.
But based on that blog post it is clear that they did want a better C or better C++.
In the end they did a mini-pivot and instead got a better Python|Node.js|Ruby + types + better concurrency + easier_dependencies_and_deployment, which worked out pretty well. So they see a lot of developers from those ecosystem jumping to them. But anyone familiar with an advanced type system (Java, C#, C++, ...) might not get as excited about. interface{} as void* -- yeah no thanks, this is not 1999 anymore.
It was funny that the first response to "Oh but it can't compete with C" was "Well, we meant systems programming language to be more like back-end web servers not your traditional systems programming..." Now, had that come from other people I might have believed, but I cannot imagine Ken and Rob had no idea what a systems programming language was and just got a little confused.
But based on that blog post it is clear that they did want a better C or better C++.
In the end they did a mini-pivot and instead got a better Python|Node.js|Ruby + types + better concurrency + easier_dependencies_and_deployment, which worked out pretty well. So they see a lot of developers from those ecosystem jumping to them. But anyone familiar with an advanced type system (Java, C#, C++, ...) might not get as excited about. interface{} as void* -- yeah no thanks, this is not 1999 anymore.
It's not remarkable to me that Ken and Rob would consider whatever language all that stuff in /usr/bin is written in to be a system language. "The language that runs in supervisor mode" seems like a pretty narrow definition.
> they were trying to write a language that filled a role similar to C and C++
... as used in Google, ie not necessarily the low-level stuff that drives a network card, but more the high-level systems (as in, server software) like the one that powers dl.google.com (see the famous rewrite by Brad Fitzpatrick). This is not a task that was necessarily best suited to C nor C++, so they wanted a better language for this.
... as used in Google, ie not necessarily the low-level stuff that drives a network card, but more the high-level systems (as in, server software) like the one that powers dl.google.com (see the famous rewrite by Brad Fitzpatrick). This is not a task that was necessarily best suited to C nor C++, so they wanted a better language for this.
I don't think it is a big surprise. C++ programmers like features that Go does not have. Ruby/Python guys like out of the box performance that Ruby/Python does not have. :)
A good summary of Go here:
https://news.ycombinator.com/item?id=9267211
As a systems language Go is ok, as a business domain language Go is subpar based on the current state of the language. CSP makes Go great for Ruby/Python guys because these features (channels, go routines) solves lots of problems those languages do not have a great solution to.
A good summary of Go here:
https://news.ycombinator.com/item?id=9267211
As a systems language Go is ok, as a business domain language Go is subpar based on the current state of the language. CSP makes Go great for Ruby/Python guys because these features (channels, go routines) solves lots of problems those languages do not have a great solution to.
It seems pretty straightforward to me. Rust fits into more or less the niche of C and C++: a low-level systems programming language with minimal runtime dependencies (no garbage collection, smallish standard library), which happen to also be useful properties for realtime and other perfromance-critical software.
Go, on the other hand, fits more into Java's niche: an opinionated mid-level garbage collected language designed for application programming or mid-level systems stuff (i.e. web servers), with concurrency baked into the language design (though Go's concurrency design is much more to my liking than Java's).
Go, on the other hand, fits more into Java's niche: an opinionated mid-level garbage collected language designed for application programming or mid-level systems stuff (i.e. web servers), with concurrency baked into the language design (though Go's concurrency design is much more to my liking than Java's).
I mostly agree with your analysis. As someone who is doing web development in Rust, what should I fear of missing from a language like Go or Java? Is it just an ecosystem thing? Java is a more popular option for web server development over C++, but I don't know why.
C and C++ were a mess when Java appeared.
C was standardized in 1989 and in the early 90's it was still easier to port K&R code than ANSI C.
C++ only got standardized in 1998, two years after Java appeared. Each compiler supported different parts of the standard, had vendor specific libraries and suffered from C like APIs.
Java was a good enough C++ that one could expect with would have the same behavior in every system.
Also the Java 1.0 networking libraries were already miles ahead of anything one could find for C and C++, and its SDK was free in the days we paid for compilers.
C was standardized in 1989 and in the early 90's it was still easier to port K&R code than ANSI C.
C++ only got standardized in 1998, two years after Java appeared. Each compiler supported different parts of the standard, had vendor specific libraries and suffered from C like APIs.
Java was a good enough C++ that one could expect with would have the same behavior in every system.
Also the Java 1.0 networking libraries were already miles ahead of anything one could find for C and C++, and its SDK was free in the days we paid for compilers.
For Java, you get some very excellent tooling, a slowly evolving language, a battle-tested and mature virtual machine, comprehensive API, first-order parametric polymorphism, and a number of useful frameworks with tons of community support.
For Go, you get an opinionated language/build system, decent tooling that is quickly evolving, no higher-kinded types, very systems-oriented API, ability to target multiple platforms without a VM, and also a number of useful frameworks.
In short, and this is just MHO, I would rather build a systems-oriented app with Go than with Java, and I would rather build a webapp with Java than with Go. It's not clear to me that, as a language, Go can capture bizlogic complexity the same way Java could in a webapp. Also, it's definitely clear to me that I would rather deploy a native binary than a vm + bytecode for systems-heavy tasks, like automating maintenance of a database cluster, and Go is excellent for that.
For Go, you get an opinionated language/build system, decent tooling that is quickly evolving, no higher-kinded types, very systems-oriented API, ability to target multiple platforms without a VM, and also a number of useful frameworks.
In short, and this is just MHO, I would rather build a systems-oriented app with Go than with Java, and I would rather build a webapp with Java than with Go. It's not clear to me that, as a language, Go can capture bizlogic complexity the same way Java could in a webapp. Also, it's definitely clear to me that I would rather deploy a native binary than a vm + bytecode for systems-heavy tasks, like automating maintenance of a database cluster, and Go is excellent for that.
Compared to Go or Java you're not missing much - I'm not sure what the state of Rust's generics is these days but at the very least they're not far behind Java's. Compared to a higher-level functional language you're missing higher-kinded types that would let you do things like http://typelevel.org/blog/2013/10/18/treelog.html . See what you end up doing for "cross-cutting concerns" - things like logging, auth, transactions - as those are the kind of thing you need a higher-level language to handle elegantly.
The big thing you're missing compared to the mid-level languages you mention is garbage collection. Rust makes manual memory management much easier than C++, but it's still never going to be quite as easy as the "just make objects and don't worry about it" that you get in a garbage-collected language.
The big thing you're missing compared to the mid-level languages you mention is garbage collection. Rust makes manual memory management much easier than C++, but it's still never going to be quite as easy as the "just make objects and don't worry about it" that you get in a garbage-collected language.
Specifically about C++ v Java for web development, I think the answer lies in reflection. C++ doesn't allow member introspection at runtime like Java. Many web technologies and their supporting stacks leverage reflection heavily.
Look at Spring MVC. Both it and Spring in general are reflection machines. This provides a lot of easy work that's relatively safe even with duck typing.
Look at Spring MVC. Both it and Spring in general are reflection machines. This provides a lot of easy work that's relatively safe even with duck typing.
Is Rust really suitable for web development? I am genuinely asking.
For server development I think it might be a good choice, but for application code itself it seems like more of a pain to program in than an advantage.
For server development I think it might be a good choice, but for application code itself it seems like more of a pain to program in than an advantage.
I think Rust has promise as a web dev language. Here's a quick list of the key libraries currently in the ecosystem[1].
Up until now, I've only ever used interpreted, dynamic languages for web development. In contrast, Rust offers me a tight memory footprint (no silly things like unicorn-worker-killer), high performance (the average response time for most of my Rails apps is 150ms), and a slew of static guarantees about types (no "undefined method for nil:NilClass") and memory safety. It also has some really cool things like sanitary macros and syntax extensions that have allowed me to build out a fairly simple yet robust ORM similar to ActiveRecord in look and feel.
I may be forcing a square peg into a circle hole; all my current work is experimental.
Can you clarify on the difference between "server development" and "application code"? In this context, I've always considered those terms to be the same.
Edit: I think I understand what you mean by application code — business logic code? Reasonable concerns. I don't have much to say yet (I'm just doing framework stuff now in preparation for real applications), but here's a demo of my aforementioned ORM in action[2].
[1] http://arewewebyet.com/
[2] https://gist.github.com/SkylerLipthay/9015e6c79859e7dc8709
Up until now, I've only ever used interpreted, dynamic languages for web development. In contrast, Rust offers me a tight memory footprint (no silly things like unicorn-worker-killer), high performance (the average response time for most of my Rails apps is 150ms), and a slew of static guarantees about types (no "undefined method for nil:NilClass") and memory safety. It also has some really cool things like sanitary macros and syntax extensions that have allowed me to build out a fairly simple yet robust ORM similar to ActiveRecord in look and feel.
I may be forcing a square peg into a circle hole; all my current work is experimental.
Can you clarify on the difference between "server development" and "application code"? In this context, I've always considered those terms to be the same.
Edit: I think I understand what you mean by application code — business logic code? Reasonable concerns. I don't have much to say yet (I'm just doing framework stuff now in preparation for real applications), but here's a demo of my aforementioned ORM in action[2].
[1] http://arewewebyet.com/
[2] https://gist.github.com/SkylerLipthay/9015e6c79859e7dc8709
If garbage collection is ok for your use case, a garbage collected language (Java, Go, etc) will most certainly make your life easier than with Rust.
Rust is good for extending Python, Ruby, etc stuff. More safe than C.
Rust is good for extending Python, Ruby, etc stuff. More safe than C.
Rust seems like an excellent choice for performance sensitive parts of your web application, especially client side. Right now asm.js / WASM do not contain a garbage collector, so most other choices would involve shipping up a large run time with your app. Unity can get away with that -- you probably can't.
Server side you have many more good choices, but Rust does have a nice FFI story in both directions.
Whether you want to write your entire app in Rust is a different question. I'd want to get more experience with Rust before answering that question -- writing a performance sensitive portion in Rust first would go a long way to answering that question.
Server side you have many more good choices, but Rust does have a nice FFI story in both directions.
Whether you want to write your entire app in Rust is a different question. I'd want to get more experience with Rust before answering that question -- writing a performance sensitive portion in Rust first would go a long way to answering that question.
Probably mostly depends on the libraries and frameworks that will appear? The SQL query->data->template pipe isn't very reliant on the language as long as it can manipulate "data" reasonably well.
Nobody wants to code C++ for webservers because of the risk (PayPal not included) but Rust doesn't have that issue.
Nobody wants to code C++ for webservers because of the risk (PayPal not included) but Rust doesn't have that issue.
Actually, some people use C++, with an OKCupid framework.
https://github.com/okws/okws
https://github.com/okws/okws
I used Rust to optimize performance in a hot spot for our Python web-app. I am a Rust newbie, and this was my first encounter with the language, so my opinion may not have much value. But I found Rust to be unsuitable for web-development.
The fact that Rust requires that you think about memory management made it feel less expressive and less productive. The strictness of the compiler also got in the way of "productivity". There's nothing wrong with that strictness, but in the domain of web-development where productivity and expressiveness is often more valued than raw performance Rust doesn't feel like the optimal tool.
To use Rust for web-development feels like a premature optimization.
I think for web-development, it's probably more productive to use Ruby/Python/etc... and call Rust externally to optimize hot spots.
The fact that Rust requires that you think about memory management made it feel less expressive and less productive. The strictness of the compiler also got in the way of "productivity". There's nothing wrong with that strictness, but in the domain of web-development where productivity and expressiveness is often more valued than raw performance Rust doesn't feel like the optimal tool.
To use Rust for web-development feels like a premature optimization.
I think for web-development, it's probably more productive to use Ruby/Python/etc... and call Rust externally to optimize hot spots.
I think with C++ it is much easier to shoot yourself in the foot, but overall, I think it's probably mostly just ecosystem between the C++ and Java.
Having tried both Rust and Go, I think I'd much prefer Go for simple web dev stuff because of all the ecosystem around it, but for most other things prefer rust.
Having tried both Rust and Go, I think I'd much prefer Go for simple web dev stuff because of all the ecosystem around it, but for most other things prefer rust.
> I think with C++ it is much easier to shoot yourself in the foot property
Go solves this by not allowing you to have a foot in the first place, instead encouraging you to walk on your hands and write blog posts elaborating why everybody should do this.
Go solves this by not allowing you to have a foot in the first place, instead encouraging you to walk on your hands and write blog posts elaborating why everybody should do this.
I can't imagine there being a huge difference between Rust and Go both being quite new.
Java and in particular the JVM has a massive ecosystem which ranges from small libraries through to major infrastructure components e.g. databases, big data, enterprise, middleware, integration etc. And the fact that the biggest and best companies are using it means you can leverage some high quality components e.g. Twitter, Netflix, IBM. That said all of the above isn't mandatory for 90% of websites most people build.
As for why Java is popular for web server deployment. Not having to worry about memory management, having a less complex feature set and excellent performance are the key features I can think of.
Java and in particular the JVM has a massive ecosystem which ranges from small libraries through to major infrastructure components e.g. databases, big data, enterprise, middleware, integration etc. And the fact that the biggest and best companies are using it means you can leverage some high quality components e.g. Twitter, Netflix, IBM. That said all of the above isn't mandatory for 90% of websites most people build.
As for why Java is popular for web server deployment. Not having to worry about memory management, having a less complex feature set and excellent performance are the key features I can think of.
> I can't imagine there being a huge difference between Rust and Go both being quite new.
This is a failure of your imagination. The linked article points out some of the differences, but there are many others. This topic has been endlessly discussed, and I'm kind of sick of repeating it, but I have written several posts on this matter and you can hunt them down if you wish.
This is a failure of your imagination. The linked article points out some of the differences, but there are many others. This topic has been endlessly discussed, and I'm kind of sick of repeating it, but I have written several posts on this matter and you can hunt them down if you wish.
yes they ARE competitors.
They are both used where people would use C or C++ to get more performances , especially by developers who would normally use a scripting language like ruby or python for their 'website'. Never heard a "why we moved from Java to Go story", heard plenty of infrastructure rewriting from ruby/python/nodejs to Go. People stuck in enterprise Java/C# ain't going to move a 10-15 yo infrastructure to the latest hype,they'll stick to the JVM or the CLR which offers plenty of choice already.
These (former) devs might have used Rust instead of Go though Rust doesn't come with a big webapp related ecosystem yet (it will).
In this space (compile to executable - statically typed yet still expressive languages without manual memory management) there are basically 4/5 languages in competition : Go, Rust, Nim, D and Crystal. One of them will be the 'C++ for suckers of the next 10 years' and will be incredibly successful as the demand is quite high. So Go is definitely in competition with others in that space.
Now let's the competition begin.
They are both used where people would use C or C++ to get more performances , especially by developers who would normally use a scripting language like ruby or python for their 'website'. Never heard a "why we moved from Java to Go story", heard plenty of infrastructure rewriting from ruby/python/nodejs to Go. People stuck in enterprise Java/C# ain't going to move a 10-15 yo infrastructure to the latest hype,they'll stick to the JVM or the CLR which offers plenty of choice already.
These (former) devs might have used Rust instead of Go though Rust doesn't come with a big webapp related ecosystem yet (it will).
In this space (compile to executable - statically typed yet still expressive languages without manual memory management) there are basically 4/5 languages in competition : Go, Rust, Nim, D and Crystal. One of them will be the 'C++ for suckers of the next 10 years' and will be incredibly successful as the demand is quite high. So Go is definitely in competition with others in that space.
Now let's the competition begin.
> They are both used where people would use C or C++ to get more performances , especially by developers who would normally use a scripting language like ruby or python for their 'website'.
Rust is definitely not generally used by people who would otherwise use a scripting langauge.
There are dozens of languages with the same target audience as Go (with a similar or better maturity level); there are very few languages with the same target audience as Rust (suitable for embedded systems sans libc) with the maturity of Rust.
Rust is definitely not generally used by people who would otherwise use a scripting langauge.
There are dozens of languages with the same target audience as Go (with a similar or better maturity level); there are very few languages with the same target audience as Rust (suitable for embedded systems sans libc) with the maturity of Rust.
> Rust is definitely not generally used by people who would otherwise use a scripting language.
I fail to see why pythonists or rubyist couldn't use Rust. On the contrary Rust has more semantics that are closer to these languages than Go has.
I fail to see why pythonists or rubyist couldn't use Rust. On the contrary Rust has more semantics that are closer to these languages than Go has.
"On the contrary Rust has more semantics that are closer to these languages than Go has."
Uh... goodness gracious no. Going from Python to Go is a bit of a learning experience, and you might lose some features you're used to while gaining some new ones you're not very used to, but it's not too big a deal. Going from Python to Rust is halfway as hard as going from Python to Haskell. Radically different philosophies, radically different semantics (GC to no GC is shocking enough, but Rust takes "no GC" to new heights of foreignness).
The first program a Pythonista writes in Go will pretty much work. The first program a Pythonista writes in Rust will explode into a half-page compiler error discussing concepts they've never heard of before.
None of this is a criticism of Rust... I applaud Rust for getting itself a good distance away from Python! In 40 years I think "imperative languages with no built-in ownership concepts" will be regarded in much the same way we regard line numbers today... "How did you ever use that? Are you serious? Who would ever think that was a good idea?" (Well, you had to be there...) But in the meantime, it's no contest... Go is way closer to Python than Rust is, and yeah, to some extent I personally consider that a criticism of Go. (I like Go for work, but to some extent I see it as a last-generation final refinement of its ideas, whereas Rust is a one of the first usable languages of the next generation. Both have their place. I suppose that doubles as my own explanation of why they aren't competitors, or at least, not direct competitors.)
Uh... goodness gracious no. Going from Python to Go is a bit of a learning experience, and you might lose some features you're used to while gaining some new ones you're not very used to, but it's not too big a deal. Going from Python to Rust is halfway as hard as going from Python to Haskell. Radically different philosophies, radically different semantics (GC to no GC is shocking enough, but Rust takes "no GC" to new heights of foreignness).
The first program a Pythonista writes in Go will pretty much work. The first program a Pythonista writes in Rust will explode into a half-page compiler error discussing concepts they've never heard of before.
None of this is a criticism of Rust... I applaud Rust for getting itself a good distance away from Python! In 40 years I think "imperative languages with no built-in ownership concepts" will be regarded in much the same way we regard line numbers today... "How did you ever use that? Are you serious? Who would ever think that was a good idea?" (Well, you had to be there...) But in the meantime, it's no contest... Go is way closer to Python than Rust is, and yeah, to some extent I personally consider that a criticism of Go. (I like Go for work, but to some extent I see it as a last-generation final refinement of its ideas, whereas Rust is a one of the first usable languages of the next generation. Both have their place. I suppose that doubles as my own explanation of why they aren't competitors, or at least, not direct competitors.)
IMHO 'C++ for suckers of the next 10 years' will still be C++ (and I would love to be proved wrong).
>Rust and Go are both touted as memory safe. While this statement is absolutely true, both languages will not tolerate unsafe memory access, what is more important is that the world will not tolerate any new language which is not memory safe. It just so happens that Go and Rust are the first two languages to emerge after decades of evidence that in the real world, programmers as a whole, cannot safely manage memory manually.
This is extremely misleading.
Go and Rust are not at all "memory safe" in the same way.
And Go and Rust the "first two languages" in this regard? Hardly.
Rust maybe, because it uses a novel approach, but there's absolutely nothing special in Go's "memory safety" approach compared to Java (and Scala, Clojure), C#, D, Haskell, etc.
This is extremely misleading.
Go and Rust are not at all "memory safe" in the same way.
And Go and Rust the "first two languages" in this regard? Hardly.
Rust maybe, because it uses a novel approach, but there's absolutely nothing special in Go's "memory safety" approach compared to Java (and Scala, Clojure), C#, D, Haskell, etc.
You took it the wrong way. Dave didn't say that Go's GC was special, of course garbage collectors have been around for decades. The key takeaway:
> what is more important is that the world will not tolerate any new language which is not memory safe.
Because of that, both Go and Rust, as a new languages, are not memory unsafe. Go's safety is boring, sure, but it's still a feature of the language.
So both languages are memory safe in that they are not memory unsafe, big whoop. That's Dave's point. All new languages have this, and even though they're commonly compared with this metric, the metric itself is useless for new languages.
> what is more important is that the world will not tolerate any new language which is not memory safe.
Because of that, both Go and Rust, as a new languages, are not memory unsafe. Go's safety is boring, sure, but it's still a feature of the language.
So both languages are memory safe in that they are not memory unsafe, big whoop. That's Dave's point. All new languages have this, and even though they're commonly compared with this metric, the metric itself is useless for new languages.
>Rust and Go are both touted as memory safe. While this statement is absolutely true
Duh?
>So both languages are memory safe in that they are not memory unsafe
This is more accurate statement imo. Saying Go is memory safe [1] is like saying a lamb is safe among a heard of hungry lions.
[1] http://www.pl-enthusiast.net/2014/07/21/memory-safety/
Duh?
>So both languages are memory safe in that they are not memory unsafe
This is more accurate statement imo. Saying Go is memory safe [1] is like saying a lamb is safe among a heard of hungry lions.
[1] http://www.pl-enthusiast.net/2014/07/21/memory-safety/
From that article, safe Go prevents: buffer overflow, use after free, use of uninitialized memory, illegal free, access to undefined memory. The only thing it misses is null pointer dereference. (OOM errors are not possible to prevent in turing-complete languages.)
I don't agree with your analogy. A lamb among lions is clearly very unsafe, but Go isn't unsafe; you just agreed with me on this. Your analogy fits better to C/C++. The lamb could theoretically survive, but it's very unlikely; just as unlikely as a C/C++ program with no memory bugs.
I don't agree with your analogy. A lamb among lions is clearly very unsafe, but Go isn't unsafe; you just agreed with me on this. Your analogy fits better to C/C++. The lamb could theoretically survive, but it's very unlikely; just as unlikely as a C/C++ program with no memory bugs.
Yes I do generally agree with you. I went a bit overboard - somewhat HN pushes me over the edge sometimes :-(
Lamb metaphore would not do Go the justice indeed. I do like Go, but also do not like some opinion which oversimplify reality.
Lamb metaphore would not do Go the justice indeed. I do like Go, but also do not like some opinion which oversimplify reality.
Again, how are those "the first" after people stopped tolerating new unsafe languages?
We hadn't had a new memory unsafe language catching on (or released from some major vendor) since what? C++? It was pretty much standard by the time Java was out. Heck, there were mainstream Smalltalk in the 90s, with IBM support, IDE's et al.
So Smalltalk, Java, VB (up to 6), C# and others all all languages that predated Go and Rust in memory safety, and came out in an era memory safety was de rigeur.
We hadn't had a new memory unsafe language catching on (or released from some major vendor) since what? C++? It was pretty much standard by the time Java was out. Heck, there were mainstream Smalltalk in the 90s, with IBM support, IDE's et al.
So Smalltalk, Java, VB (up to 6), C# and others all all languages that predated Go and Rust in memory safety, and came out in an era memory safety was de rigeur.
Just adding Ada, Modula-2, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, Turbo Pascal, Quick Pascal, Delphi, Eiffel, ... to your safety list.
It is incredible how two decades of C and C++ becoming mainstream, change the perception of all existing alternatives.
It is incredible how two decades of C and C++ becoming mainstream, change the perception of all existing alternatives.
Go and Rust are the first two to emerge after decades of evidence. Other languages emerged during those decades. :)
It was Java which took non-manual memory management to the mainstream. Lisp takes credit for inventing garbage collection.
Basic dialects and Clipper, just to cite two examples with reference counting.
Smalltalk was also becoming mainstream before Java entered into the picture.
Smalltalk was also becoming mainstream before Java entered into the picture.
Visual Basic was pretty mainstream before Java. As I recall, it had something along the lines of reference counting for memory management.
So I've written a few things in Rust, none in Go, but I've looked through Go's syntax.
Everything that can be written in Go can be written in Rust. However, Go would be much more simpler for things, ie. right now, a web server. On the other end, some critical performance things or microprocessors, etc., written in Rust cannot be written in Go.
They each have a purpose, and while there is some overlap, the purpose is very different. Go is geared more towards developer simplicity. Inevitably, Go will be a more popular language because of the simplicity. Similar to Ruby and Python. I also see Rust becoming a much more mature language that will take many C and c++ programmers over the next few years. It takes time, 1.0 was only released 7 weeks ago.
In the end, I see both of these languages growing more and sticking around for awhile. Especially with large corporate backings (Google, Mozilla) and growing communities.
I think I will probably learn both eventually.
Everything that can be written in Go can be written in Rust. However, Go would be much more simpler for things, ie. right now, a web server. On the other end, some critical performance things or microprocessors, etc., written in Rust cannot be written in Go.
They each have a purpose, and while there is some overlap, the purpose is very different. Go is geared more towards developer simplicity. Inevitably, Go will be a more popular language because of the simplicity. Similar to Ruby and Python. I also see Rust becoming a much more mature language that will take many C and c++ programmers over the next few years. It takes time, 1.0 was only released 7 weeks ago.
In the end, I see both of these languages growing more and sticking around for awhile. Especially with large corporate backings (Google, Mozilla) and growing communities.
I think I will probably learn both eventually.
> Go competes for mindshare [with those who] have lost patience with the high deployment costs of JVM based languages
This is repeated so often, but I genuinely don't understand the underlying point. At Snowplow we have to deploy Scala, Java, JRuby and Go, amongst other things.
Scala/Java: build a fatjar containing all dependencies using sbt-assembly, upload to Bintray and then deploy onto servers which have a recent JVM.
JRuby: build a fatjar containing all dependencies using warble, upload to Bintray and then deploy onto servers which have a recent JVM.
Go: build a binary containing all dependencies with godep for each relevant server architecture, upload to Bintray and then deploy onto servers.
Yes, Go doesn't need a JVM installed, but on the flipside I have to build a version for each relevant server architecture. And then there's the software where I have to export GOMAXPROCS=`nproc` in a wrapper script...
This is repeated so often, but I genuinely don't understand the underlying point. At Snowplow we have to deploy Scala, Java, JRuby and Go, amongst other things.
Scala/Java: build a fatjar containing all dependencies using sbt-assembly, upload to Bintray and then deploy onto servers which have a recent JVM.
JRuby: build a fatjar containing all dependencies using warble, upload to Bintray and then deploy onto servers which have a recent JVM.
Go: build a binary containing all dependencies with godep for each relevant server architecture, upload to Bintray and then deploy onto servers.
Yes, Go doesn't need a JVM installed, but on the flipside I have to build a version for each relevant server architecture. And then there's the software where I have to export GOMAXPROCS=`nproc` in a wrapper script...
The JVM, CLR, Frameworks, Runtimes, app servers, configurations, etc. _ARE_ the problem. We're tired of all that crap all the time. Compile to an executable and xcopy the executable to an arbitrary server. Ideally, nothing to configure outside of the application itself.
Go fits that bill nicely, but it's an annoyingly austere language. With all the languages in this last wave, I just don't know why nobody hit on a full featured Go level language yet. No memory management, not deployment dependencies, full of nice sugary high level abstractions, and cross platform Windows/Linux. Something solid and ready for production use, not an alpha or beta.
Go fits that bill nicely, but it's an annoyingly austere language. With all the languages in this last wave, I just don't know why nobody hit on a full featured Go level language yet. No memory management, not deployment dependencies, full of nice sugary high level abstractions, and cross platform Windows/Linux. Something solid and ready for production use, not an alpha or beta.
> Compile [assemble] an executable and xcopy the executable to an arbitrary server [with a JVM]. Ideally, nothing to configure outside of the application itself.
That is exactly what we do with Java, Scala, JRuby. Installing a JVM is 5 lines of bash; 1 line of Dockerfile. I don't understand the point you're making.
That is exactly what we do with Java, Scala, JRuby. Installing a JVM is 5 lines of bash; 1 line of Dockerfile. I don't understand the point you're making.
Let me start by saying I think the argument for binaries vs fat jars is overblown.
That said there is more complexity with the jvm. Do you have the right jvm installed? Where was it installed? Are there multiple versions of the jvm installed? Do you care? Can you mess with it? Have you accepted the license for the jvm? Should I use docker to manage all this complexity? Is the docker agent working? etc.
In environments where you are deploying to a single architecture that is more complex than "copy binary". In environments with LOTS of servers the (admittedly limited) complexity difference can add up.
That said there is more complexity with the jvm. Do you have the right jvm installed? Where was it installed? Are there multiple versions of the jvm installed? Do you care? Can you mess with it? Have you accepted the license for the jvm? Should I use docker to manage all this complexity? Is the docker agent working? etc.
In environments where you are deploying to a single architecture that is more complex than "copy binary". In environments with LOTS of servers the (admittedly limited) complexity difference can add up.
IT says everyone uses version X.
This group IT, do they set up the servers? Do they make sure policy is enforced? Do they deploy your software? If so, they are doing the work and we should be asking them & not you whether they prefer JVM based solutions or single binary ones.
Most of the companies I worked for, only IT has a say what devs have on their machines and servers. You need tickets for everything.
First off, make the assumption that you're not just running Linux. Half your deploys are to Windows. If you don't do Windows then you'll certainly have fewer problems.
Second, Docker may be the solution. In concept it's great. But Docker isn't yet a first class citizen in Windows. For the time being it becomes yet one more run-time piece that has to be configured.
Clearly my map of the world not your map of the world (à la Korzybski). I find the various extraneous run time pieces constantly tedious and annoying. You don't. Can't say why you don't, but I'm to the point where I despise them. I don't want another call where I have to tell a customer they have to update this piece or download that piece or move this there in order to get the latest version of an application to work.
Second, Docker may be the solution. In concept it's great. But Docker isn't yet a first class citizen in Windows. For the time being it becomes yet one more run-time piece that has to be configured.
Clearly my map of the world not your map of the world (à la Korzybski). I find the various extraneous run time pieces constantly tedious and annoying. You don't. Can't say why you don't, but I'm to the point where I despise them. I don't want another call where I have to tell a customer they have to update this piece or download that piece or move this there in order to get the latest version of an application to work.
Docker and other containers are a response to runtimes failing to, ahem, contain themselves. It is true that you don't need a second solution if you already have one, but some people may not like the container solution.
I don't know about your situation, but at our end, to start JBoss after a new deployment, it takes about 75 to 90 seconds. While for production it may be okay-ish, it absolutely drives the developers and testers nuts.
I think D fills that bill, and it has at least a tiny bit of Facebook backing.
In fact, IMHO it is a much better language than go, the only lacking stuff are millions of libraries.
In fact, IMHO it is a much better language than go, the only lacking stuff are millions of libraries.
You can compile to native code with Java as well. The OpenJDK isn't the only one, e.g. Excelsior JET.
If you prefer freebies Java 10 might have an AOT compiler as well.
If you prefer freebies Java 10 might have an AOT compiler as well.
Talking about deployment is ridiculous to me with languages that in most cases are going to be long running server side applications.
How often are you going to install JVM/Ruby/Python ? Once. How often are you going to deploy ? Thousands. So the important part is how well the overall process works e.g dependency management, build scripts, automation, tooling etc.
How often are you going to install JVM/Ruby/Python ? Once. How often are you going to deploy ? Thousands. So the important part is how well the overall process works e.g dependency management, build scripts, automation, tooling etc.
That makes an assumption about deployment. It assumes that you only provision a server once and you deploy many times. There are operational models where the provisioning of the server themselves is the deployment step.
> I have to export GOMAXPROCS=`nproc` in a wrapper script...
if os.Getenv("GOMAXPROCS") == "" {
runtime.GOMAXPROCS(runtime.NumCPU())
}
Go is only a competitor for Java 1.0 like languages.
It is not a competitor to Rust, because it lives in enterprise mindset of 90's language design.
It is not a competitor to the JVM languages, because all of them are more feature rich and any knowledgeable JVM developer is aware there are plenty of options to deploy, including static binaries.
It is not a competitor to Rust, because it lives in enterprise mindset of 90's language design.
It is not a competitor to the JVM languages, because all of them are more feature rich and any knowledgeable JVM developer is aware there are plenty of options to deploy, including static binaries.
I have a lot of experience in the JVM and understand how to deploy, build, etc. JVM based solutions including those built on "next generation" JVM languages like Scala.
Go absolutely is a competitor to that environment because writing web services across large teams is something Go has a compelling story around. This has been the domain of the JVM for a long time and many people have bad experiences with it (many people have good experiences as well I'd add).
Go absolutely is a competitor to that environment because writing web services across large teams is something Go has a compelling story around. This has been the domain of the JVM for a long time and many people have bad experiences with it (many people have good experiences as well I'd add).
> the JVM for a long time and many people have bad experiences with it
And the only reason for this is that people don't have to maintain 15 yo Go code bases yet. But Go is verbose and will be a hell to maintain just like any other language that becomes 'enterprisey', just like big nodejs code bases, big rails code bases or big JEE code bases give people 'bad experiences'.
And the only reason for this is that people don't have to maintain 15 yo Go code bases yet. But Go is verbose and will be a hell to maintain just like any other language that becomes 'enterprisey', just like big nodejs code bases, big rails code bases or big JEE code bases give people 'bad experiences'.
I dont disagree at all. The one thing I would say might mitigate this, is that the golang community and leaders are very much rooted in the Unix philosophy of doing one thing well. They push back very hard on things that enable code bases to get big.
Its possible that golang will simply not be viable in use cases that require big code bases, and therefore won't deal with those problems. Its also possible that over time the focus on keeping things small will drift, and golang will just be Java.
Its possible that golang will simply not be viable in use cases that require big code bases, and therefore won't deal with those problems. Its also possible that over time the focus on keeping things small will drift, and golang will just be Java.
Why are we still talking about this?
Every language that's vaguely close to a multi-purpose language is a competitor with every other language. There are people who write websites in X86 assembler and people who write embedded systems in Python.
Rust and Go are competitors. Yes, they were intended for different things, but who cares? Any reasonable metric of language success is going to show one language pulling numbers from the other. Pick your metric: users? There are plenty of people who aren't using Rust because they're using Go, and vice-versa. Successful projects? There are plenty of projects which aren't being written in Go because they're being written in Rust, and vice-versa. Reliability and safety? Maybe Go would have a reasonable type system if Rust hadn't snapped up so many of the good thinkers in that field.
Arguing about whether languages are competing based on what they were intended for is a pointless argument: there's no metric for success, no way to validate who's right or wrong. Are we really going to spend time arguing over what Google devs meant when they used the word "systems"? Seriously?
Every language that's vaguely close to a multi-purpose language is a competitor with every other language. There are people who write websites in X86 assembler and people who write embedded systems in Python.
Rust and Go are competitors. Yes, they were intended for different things, but who cares? Any reasonable metric of language success is going to show one language pulling numbers from the other. Pick your metric: users? There are plenty of people who aren't using Rust because they're using Go, and vice-versa. Successful projects? There are plenty of projects which aren't being written in Go because they're being written in Rust, and vice-versa. Reliability and safety? Maybe Go would have a reasonable type system if Rust hadn't snapped up so many of the good thinkers in that field.
Arguing about whether languages are competing based on what they were intended for is a pointless argument: there's no metric for success, no way to validate who's right or wrong. Are we really going to spend time arguing over what Google devs meant when they used the word "systems"? Seriously?
I certainly see the need for Rust, a better, stricter and more modern C designed for low-level tasks where both performance and correctness matter, e.g. layout engines, game engines, OS kernels.
On the other hand Go seems more suited to system/server tools where good-enough perfmance and quick startup matters more. I've noticed that people have been converting Python and Ruby code-bases to Go, and its use in system tools such as Docker, CoreOS, and Kuberentes. We're working in this area and have considered jumping on the bandwagon and rewriting our Python prototype in Go for the same reasons - performance, minimal runtime, strong ecosystem, some 'typing'. (Python made/makes sense atm as we're still very exploratory so doesn't get in our way).
However upon investigation I was a bit disappointed with Go, although it has an incredible ecosystem and active community. Perhaps its simplicity is also an advantage although I found it counter-intuitive at times. However I can see why it found use in a way that 'better' (IMHO) tools such as OCaml were unable to.
We're still undecided as to what to use when/if rewriting our code. Funnily enough I'm wondering if maybe C#/F# would work, now .NET has been open-sourced and has a native compiler. A good language/runtime, stronger type-system, lots of libraries, and potentially good performance with quick startup. I guess it would be quite amusing if MS's tooling ended up as the best way to write Linux system/server tools within those particular constraints.
On the other hand Go seems more suited to system/server tools where good-enough perfmance and quick startup matters more. I've noticed that people have been converting Python and Ruby code-bases to Go, and its use in system tools such as Docker, CoreOS, and Kuberentes. We're working in this area and have considered jumping on the bandwagon and rewriting our Python prototype in Go for the same reasons - performance, minimal runtime, strong ecosystem, some 'typing'. (Python made/makes sense atm as we're still very exploratory so doesn't get in our way).
However upon investigation I was a bit disappointed with Go, although it has an incredible ecosystem and active community. Perhaps its simplicity is also an advantage although I found it counter-intuitive at times. However I can see why it found use in a way that 'better' (IMHO) tools such as OCaml were unable to.
We're still undecided as to what to use when/if rewriting our code. Funnily enough I'm wondering if maybe C#/F# would work, now .NET has been open-sourced and has a native compiler. A good language/runtime, stronger type-system, lots of libraries, and potentially good performance with quick startup. I guess it would be quite amusing if MS's tooling ended up as the best way to write Linux system/server tools within those particular constraints.
Cheney sounds on the money to me. Even with this ending-
"Go competes for mindshare in the post 2006 Internet 2.0 generation of companies who have outgrown languages like Ruby, Python, and Node.js (v8) and have lost patience with the high deployment costs of JVM based languages."
I agree. If you're a large company that has a lot of product which is backend webservices and you have huge amounts of Ruby, Python (dunno who has large amounts of Node, but that has to be sad)- then Go needs to be looked at pretty hard. While some of Go's deployment advantages are nullified a bit thanks to things like Docker and UbuntuCore, it's probably going to win on maintainability with large codebases over time with new programmers coming in the door over time. I wouldn't put up much argument against that. If running a business and the choice was a 500KLOC codebase in Python, Go or Java.. I'd prefer that is in Go. And no one starts out with 500KLOC, so the decision for a new business would need to be taken seriously from the start.
It's cliche but if your problems match Google's, then Go is a great solution. I think Go will be and already is wildly successful in this domain. The killer feature that ensures this is the simplicity. I think anyone coming from any language could pickup one of the "simple is better" languages like Go. That's going to ensure the prophecy continues IMO. Doesn't mean I'm onboard as 1 guy. I wouldn't have a problem with doing it for a job though. It'd be on my short list of acceptable technologies I'd work with.
Doxsey in his response though with his Go for everything stance, is a bit overzealous for me. I'd agree if it seemed right, but it doesn't seem right. I don't see it. Fortunately for Go, he doesn't have to be right. I think what I described as being Go's sweet spot in the industry will be more than enough. That religiosity reads as someone who's overly excited and maybe trying to keep Go in the news.
I agree. If you're a large company that has a lot of product which is backend webservices and you have huge amounts of Ruby, Python (dunno who has large amounts of Node, but that has to be sad)- then Go needs to be looked at pretty hard. While some of Go's deployment advantages are nullified a bit thanks to things like Docker and UbuntuCore, it's probably going to win on maintainability with large codebases over time with new programmers coming in the door over time. I wouldn't put up much argument against that. If running a business and the choice was a 500KLOC codebase in Python, Go or Java.. I'd prefer that is in Go. And no one starts out with 500KLOC, so the decision for a new business would need to be taken seriously from the start.
It's cliche but if your problems match Google's, then Go is a great solution. I think Go will be and already is wildly successful in this domain. The killer feature that ensures this is the simplicity. I think anyone coming from any language could pickup one of the "simple is better" languages like Go. That's going to ensure the prophecy continues IMO. Doesn't mean I'm onboard as 1 guy. I wouldn't have a problem with doing it for a job though. It'd be on my short list of acceptable technologies I'd work with.
Doxsey in his response though with his Go for everything stance, is a bit overzealous for me. I'd agree if it seemed right, but it doesn't seem right. I don't see it. Fortunately for Go, he doesn't have to be right. I think what I described as being Go's sweet spot in the industry will be more than enough. That religiosity reads as someone who's overly excited and maybe trying to keep Go in the news.
Yeah I think of go as an upgraded scripting language in a lot of ways. In a lot of ways I think go or scala are going to become the standard "oh crap we need to scale and preform better" web application languages. I think in most cases if I'm building a green field web application on the server side I'd be hard pressed to not choose go or scala at the beginning. Nearly as quick a development cycle and a MUCH better scaling story.
Rust is too my a language aimed squarely at what I mentally model at tight loop applications, web browser engines, game engines, real time network servers etc... Go has amazing performance compared to python or ruby or even node.js but the GC is still too unpredictable to work well enough for those type of apps IMO.
Rust is too my a language aimed squarely at what I mentally model at tight loop applications, web browser engines, game engines, real time network servers etc... Go has amazing performance compared to python or ruby or even node.js but the GC is still too unpredictable to work well enough for those type of apps IMO.
[deleted]
Two fringe languages are not competitors. Who would have thought it.
First, being fringe doesn't make you non-competitor automatically. Fringe language can and often DO compete for the same niche.
Second, with support from most major shops, and being deployed even in companies such as Apple, Mozilla, Facebook and more, Go is hardly "fringe" at this moment.
Second, with support from most major shops, and being deployed even in companies such as Apple, Mozilla, Facebook and more, Go is hardly "fringe" at this moment.
What's the source for Apple, Mozilla (ok Facebook I'm less surprised) deploying Go?
Apple have posts for go jobs: http://www.golangprojects.com/golang-go-job-in-Senior-CDN-De...
There is also some conjecture that someone at Apple is writing a web scraper in Go: https://news.ycombinator.com/item?id=8567205
Mozilla have a product called Heka written in Go: https://blog.mozilla.org/services/2013/04/30/introducing-hek...
Facebook have a load of open source libraries written in Go: https://github.com/facebookgo
There is also some conjecture that someone at Apple is writing a web scraper in Go: https://news.ycombinator.com/item?id=8567205
Mozilla have a product called Heka written in Go: https://blog.mozilla.org/services/2013/04/30/introducing-hek...
Facebook have a load of open source libraries written in Go: https://github.com/facebookgo
Most prominent Mozilla Go usage is Heka ( https://github.com/mozilla-services/heka ).
I don't know about Apple, but knowing a number of folks in infra and ops there, and their tendencies, I do not doubt it is in use in places.
I don't know about Apple, but knowing a number of folks in infra and ops there, and their tendencies, I do not doubt it is in use in places.
In that narrow sense, it doesn't matter that the underlying semantics and runtimes of Go and Rust are targeted for different use cases. They get lumped together in the same conversation because people have a vague sense that something... (newer programming language, newer database engine, newer CSS templating, etc)... will make their project better. In that nebulous cloud of possible future benefits, it's understandable for people to mention both in the same conversation. However once people get past the unspecified idea of "better" and actually analyze (i.e. write concrete programs) the real costs & benefits, the differences of Go & Rust will reveal themselves. People will realize that Go is inappropriate to write a 60 fps graphics rendering engine and likewise, Rust is inappropriate to write quick scripts for Google-scale cloud orchestrations.
One other reason that Go is mentioned along with Rust is that Google used the adjective "systems" to describe it. "Go is intended as a systems language". Unfortunately, a lot of folks didn't realize that Google was using an idiosyncratic definition of "systems" to mean a programming language to help the management of their datacenters. To others, "systems language" means writing operating systems, device drivers, embedded chips, etc. There was a nuance that got lost and it ended up muddying the discussion. The phrases, "Go is a systems language", and "Rust is a systems language" look the same but they mean different things.