Choosing Between Rust or Go?(dmv.myhatchpad.com)
dmv.myhatchpad.com
Choosing Between Rust or Go?
https://dmv.myhatchpad.com/insight/choosing-between-rust-or-go/
70 comments
This whole site reads like blogspam. The copy has that uncanny "SEO-optimized" je ne sas quoi to it, with a writing style halfway between "high-school newspaper" and "coding interview cheat-sheet written by an Indian ex-pat", using parts of the English language without understanding the underlying meaning or where they fit in - like a script kiddie, but with natural language. Does anyone else get the heebie-jeebies when they read "uncanny" text like this?
I just experienced this googling when particular 2021 car models come out, hoping to find out what upgrades might be coming. There's a website for each car with near-gibberish write-ups full of keywords that tell you absolutely nothing.
And they're on the first page of google!
https://www.2020lexus.com/car-reviews-2019-2020/
First paragraph:
"Honda Civic is actually 1 of the most recent car that are designed by Honda. This car is a sedan car hybrid of which are developed to be used for metropolis car used."
And they're on the first page of google!
https://www.2020lexus.com/car-reviews-2019-2020/
First paragraph:
"Honda Civic is actually 1 of the most recent car that are designed by Honda. This car is a sedan car hybrid of which are developed to be used for metropolis car used."
I feel like I would enjoy the Internet a lot more if I had a "spam filter" that just hid everything that reads like that. It'd certainly make the experience of browsing e.g. YouTube 10x better, with all the content farms filtered out.
Check out Edmunds.com, they will give you a rundown on changes for a model year over year.
It really does present itself as a pseudo-ad for Hatchpad. No date, no author...
I think the author is Lauren Alexander (found in a box in the upper right of the desktop site). But that is confusing because there is a picture of man with the subtitle "Thought Leader Insight" directly above the article, sort of implying whoever is pictured there is the author.
Of course. The Rust people here will upvote anything about Rust, even AI generated blogspam.
So when I wrote my piece complaining about how people should not try to compare Go and Rust as they were created for very different purposes, people kept commenting that I was attacking a problem that I had came up with myself, and yet here's one more comparison of that kind reaching the front page of hn.
To me the question in the title is as ill posed as would be "Choosing Between C or JavaScript?".
To me the question in the title is as ill posed as would be "Choosing Between C or JavaScript?".
Your problem is that you're not a Thought Leader whose Insights are being brokered by a Community Engagement Specialist.
And let me explain. This guy has been "at a startup" and "at a Golang Meetup." If that isn't thought leadership, I don't know what is.
And let me explain. This guy has been "at a startup" and "at a Golang Meetup." If that isn't thought leadership, I don't know what is.
Your problem is that you're not a Thought Leader whose Insights are being brokered by a Community Engagement Specialist.
Good point.
It's a very light article, written for people who listen to Thot Leaders. It misses most of the important points.
Go is designed for web back ends. It has all the stuff you need for that, and the libraries have been thoroughly pounded on and debugged, because Google uses them internally. The language is stable and doesn't change much. It's a good fit to that job.
For other applications, Go may or may not be a good fit. Desktop apps? Probably not. Games? Probably not. Real-time control? No.
Rust now seems to be trying to use every cool idea around, all at once. The borrow checker was brilliant. The added cruft, not so much. We have generics! We have type theory! We have lambdas! We have functional programming! We have threads! We have futures! We have async! We have a whole bunch of different HTTP libraries! We've changed the error handling system how many times now? It's all very cleverly done. But it's overdone. I'm out of that world, and not clear on whether there are signs of it settling down yet.
Good point.
It's a very light article, written for people who listen to Thot Leaders. It misses most of the important points.
Go is designed for web back ends. It has all the stuff you need for that, and the libraries have been thoroughly pounded on and debugged, because Google uses them internally. The language is stable and doesn't change much. It's a good fit to that job.
For other applications, Go may or may not be a good fit. Desktop apps? Probably not. Games? Probably not. Real-time control? No.
Rust now seems to be trying to use every cool idea around, all at once. The borrow checker was brilliant. The added cruft, not so much. We have generics! We have type theory! We have lambdas! We have functional programming! We have threads! We have futures! We have async! We have a whole bunch of different HTTP libraries! We've changed the error handling system how many times now? It's all very cleverly done. But it's overdone. I'm out of that world, and not clear on whether there are signs of it settling down yet.
> Thot Leaders
That's a completely different industry, I think.
> The added cruft, not so much. We have generics! We have type theory! We have lambdas! We have functional programming! We have threads! We have futures! We have async!
Generics, lambdas, and threads are must-have basics. Futures and async are the same thing. Rust doesn't "have functional programming", unless you mean chaining `map` and `collect` methods, in which case Java also has functional programming.
HTTP and error handling are third-party libraries. Multiple choices in this area are a direct result of not trying to bundle the kitchen sink with the language. These things don't standardize in a year.
That's a completely different industry, I think.
> The added cruft, not so much. We have generics! We have type theory! We have lambdas! We have functional programming! We have threads! We have futures! We have async!
Generics, lambdas, and threads are must-have basics. Futures and async are the same thing. Rust doesn't "have functional programming", unless you mean chaining `map` and `collect` methods, in which case Java also has functional programming.
HTTP and error handling are third-party libraries. Multiple choices in this area are a direct result of not trying to bundle the kitchen sink with the language. These things don't standardize in a year.
The issue with Rust is that people actually like using it. So there’s a bunch of development happening purely for enjoyment: why is that an issue? Nobody’s forcing you to keep up with the trends - just stick to the older versions of the libraries and it’ll simply work.
Is there a winner in the HTTP Rust library wars yet? The last time I used Rust, Hyper was on top, but I hear it's no longer cool. "reqwest" is being talked up. You can also get several versions of the same library in the same program through dependency problems.[1]
This is a process problem. The development process for Rust does not seem to force convergence.
[1] https://hackernoon.com/programming-in-rust-the-good-the-bad-...
This is a process problem. The development process for Rust does not seem to force convergence.
[1] https://hackernoon.com/programming-in-rust-the-good-the-bad-...
It's... been hyper for years and is still hyper. Reqwest is an ergonomic wrapper on top of hyper if you want a higher-level API with less control.
Among the Rust ecosystem things to gripe about, this is a odd one.
async_std vs. tokio is the real split-investment battleground these days, effectively undermining the async/await momentum right as it gets out of the gate.
Among the Rust ecosystem things to gripe about, this is a odd one.
async_std vs. tokio is the real split-investment battleground these days, effectively undermining the async/await momentum right as it gets out of the gate.
Reqwest is an easier-to-use wrapper around Hyper. By the same authors.
"Thought Leader" gives me cultist vibes, with a hint of multi-level marketing. If you write some more shallow, keyword-laden dreck to get us some of that sweet, sweet SEO JUICE[1], you could be a Double Black Diamond as well!!!
[1] https://youtu.be/3bARSNVobUk?t=420
[1] https://youtu.be/3bARSNVobUk?t=420
This article makes the point you were apparently making, that Go and Rust are created for very different purposes. The difference is in the framing: this article is not complaining about people posing a question, it's providing useful information to people who don't already know everything.
There some bad judgment around, due, in my opinion, to a couple of main reasons:
- heavy Go marketing, which (intendedly or not) makes devs think that Go is "great at everything": you can't tweak memory management? that's a feature¹.
- simplified/misguided categorization into old language models: Golang is the new C, Rust is the new C++.
I think with a long enough time, the roles of the two languages will become significantly clearer.
¹: to clarify, that's a feature in some contexts, but not in others (therefore, not appropriate for "everything").
- heavy Go marketing, which (intendedly or not) makes devs think that Go is "great at everything": you can't tweak memory management? that's a feature¹.
- simplified/misguided categorization into old language models: Golang is the new C, Rust is the new C++.
I think with a long enough time, the roles of the two languages will become significantly clearer.
¹: to clarify, that's a feature in some contexts, but not in others (therefore, not appropriate for "everything").
> I think with a long enough time, the roles of the two languages will become significantly clearer.
I also expect this to be the case. But when I try to think of historical context, I come up blank. Was there this much polarization between languages in the past? I remember similar rumblings between Java and C# like 15-20 years ago, but that had more to do with the corporate backing and licensing IIRC. This feels more like political/tribal arguing.
I also expect this to be the case. But when I try to think of historical context, I come up blank. Was there this much polarization between languages in the past? I remember similar rumblings between Java and C# like 15-20 years ago, but that had more to do with the corporate backing and licensing IIRC. This feels more like political/tribal arguing.
Eh go can be a fill in for things you would do in c, just as rust can be as well, Different strokes or whatnot
Note that the section "Fuschia: Google’s Successor to Android" is incorrect. The [Fuchsia Programming Language Policy](https://fuchsia.googlesource.com/fuchsia/+/refs/heads/master...) states neither Rust nor Go is not supported for end-developers.
> states neither Rust nor Go is not supported for end-developers
Just for clarification, neither are supported according to the linked document. (the double negative was confusing for me)
Just for clarification, neither are supported according to the linked document. (the double negative was confusing for me)
Oops you're right - too late to edit it. It should say "neither Rust nor Go are supported for end-developers"
Initially my take was Javascript is for quick-and-dirty code, Rust is for beautiful thought-out architectures, and Go is somewhere in the middle.
Nowadays I tend to do even quick hacks in Rust.
I've written well engineered code in JS, I think it just requires a lot of discipline because the runtime doesn't help you.
It's not that it's impossible, it's just that expectations are generally low when it comes to JS code quality.
Who sets their expectations low? :)
I do quick stuff in scala because Rust doesn't have a decent repl.
Maybe a dumb question... but how would a compiled language provide a REPL? Isn't a VM of some sort a requirement to provide anything that we'd call a "REPL"?
REPL stands for read eval print loop. Being "compiled" is not a property of the language, but a property of the implementation. You can provide a "compiler" for python or "interpreter" for C. In Rust's case "eval" part of REPL would do compile->run. Note that even "interpreted" languages such as python are internally compiled (but this is not the output), e.g. cpython compiles python to python-byte-code, and then executes.
Aha that's a good way of putting it - thanks! I guess my experience with Go and C has made me only expect REPLs with dynamic languages that use VMs. Some of the other comments also noted that Haskell and Erlang are compiled but also provide REPLs.
Haskell is compiled and has a decent repl
It's possible to be both compiled and have a vm, like jvm and erlang (notably, erlang has a repl)
Lisp is a compiled language with a REPL.
My general file card on Rust's appropriateness:
It's for anywhere you want an iron grip on memory and correctness and the cost of screwing up is very large and don't need a quick minimum viable product. You'd expect to be writing a database or a high availability proxying server or any kind of driver or a game engine
It's for anywhere you want an iron grip on memory and correctness and the cost of screwing up is very large and don't need a quick minimum viable product. You'd expect to be writing a database or a high availability proxying server or any kind of driver or a game engine
Go is more like a faster python or lighter java, rust is more like C/C++, they aren't comparable
> Go aims to combine the safety and performance of a
statically typed compiled language with the expressiveness
and convenience of a dynamically typed interpreted
language.
It also aims to be suitable for modern systems
programming.
- Rob Pike
https://web.stanford.edu/class/ee380/Abstracts/100428-pike-s...
edit: To provide greater context from the slides I linked. Go was designed to replace C++ and Java in Google.
- Rob Pike
https://web.stanford.edu/class/ee380/Abstracts/100428-pike-s...
edit: To provide greater context from the slides I linked. Go was designed to replace C++ and Java in Google.
I like both, why not both? They are created for different purposes.
> Go probably is a better successor to Java since it’s useful for building distributed systems.
Far from it. golang, both the language and the ecosystem offer nothing close to what Java (and the JVM) offer in terms of building reliable systems, monitoring, profiling, performance, etc. Sorry to say, the fact that this comparison was made in the first place shows lack of experience.
Far from it. golang, both the language and the ecosystem offer nothing close to what Java (and the JVM) offer in terms of building reliable systems, monitoring, profiling, performance, etc. Sorry to say, the fact that this comparison was made in the first place shows lack of experience.
I don't know Rust but Go:
* Go is an extremely productive language * It doesn't have all the fancy cool features other languages have * The community is huge and it is easy to find libraries * It has gained popularity faster than any other language I can think of. They must have done something right.
* Go is an extremely productive language * It doesn't have all the fancy cool features other languages have * The community is huge and it is easy to find libraries * It has gained popularity faster than any other language I can think of. They must have done something right.
I would agree for all of them. But, from personal experience - productivity dives down really badly the moment code base have grown in size considerably. Adding more people makes it even worse, since most of these people start to come in with a very fresh language knowledge ("oh, Go is simple, you can pick it up in no time --management"), and you have to babysit each merge request carefully. Which makes your productivity worse, mgmt adds more people, you miss things here and there, and code quality goes down.
My only complaint about go is the lack of a Go supported IDE. There are lots of paid ones out there, but I've spent the morning looking for a good one that runs in a web browser that are easy to install.
> My only complaint about go is the lack of a Go supported IDE. There are lots of paid ones out there, but I've spent the morning looking for a good one that runs in a web browser that are easy to install.
I am not sure why would you want to run your IDE in a web browser, but Visual Studio Code [1] is regarded by the Go community as one of the best code editors (with plugins) [2] to develop Go projects, and in case you do not know already, Visual Studio Code is technically a web browser [3]. That being said, Goland [4] is probably one of the best integrated development environments for Go programming out there.
[1] https://code.visualstudio.com/
[2] https://code.visualstudio.com/docs/languages/go
[3] https://github.com/microsoft/vscode
[4] https://www.jetbrains.com/go/
I am not sure why would you want to run your IDE in a web browser, but Visual Studio Code [1] is regarded by the Go community as one of the best code editors (with plugins) [2] to develop Go projects, and in case you do not know already, Visual Studio Code is technically a web browser [3]. That being said, Goland [4] is probably one of the best integrated development environments for Go programming out there.
[1] https://code.visualstudio.com/
[2] https://code.visualstudio.com/docs/languages/go
[3] https://github.com/microsoft/vscode
[4] https://www.jetbrains.com/go/
Plus if you want VS Code in the browser there's Coder.com (both hosted and open source varieties)
are there a lot of IDEs that run in a browser? that seems like a really odd requirement to me.
I know of none off the top of my head, though perhaps when they say "IDE" they really mean a code editor, so there's Cloud9, Coder.com, and the like.
Maybe gitpod.io would be to your liking?
tl;dr Go, of course. rust it just too fugly and has no worthy support on windows and in IDEs. sure, you may love it but if you check out jobs, it's like 100:1 for Go. rust is and will be an exotic language for very niche use cases.
let the downvotes begin :)
let the downvotes begin :)
What kind of problems with IDEs are you running into with Rust? I've used Intellij and Clion with the Rust plugin and they seem to have all the standard IDE bells and whistles - inferred type annotations, autocomplete, autoimport, interactive debugging, refactoring, etc. I haven't tried VSCode but from what I understand that's even more popular than the Jetbrains tools so I would guess that it works pretty well too.
> has no worthy support on windows
Actually, with Rust you can even link with msvc toolchain, which Go cannot.
Actually, with Rust you can even link with msvc toolchain, which Go cannot.
What Windows problems do you see with Rust? I’ve been Windows only for a few years now.
Rust has better Windows support than Go.
I've abandoned Go in the middle of The Go Programming Language. There is really no reason to use it - there are much better languages for systems (both - as in services as well as in low-level systems) development. Desktop development experience is quite a mess as well.
I've been starting up using Go as "fast Python" for web services / REST APIs. The patterns encouraged by Go development are actually how I preferred to write Python in the first place, which is to say
1. largely avoiding huge tightly-coupled frameworks like Django
2. writing a little more boilerplate with the payoff of making code a lot clearer to reason about without having to step through tons of layers of overly-dynamic libraries
I think Go will really start to eat up the backend web services space in the coming years.
1. largely avoiding huge tightly-coupled frameworks like Django
2. writing a little more boilerplate with the payoff of making code a lot clearer to reason about without having to step through tons of layers of overly-dynamic libraries
I think Go will really start to eat up the backend web services space in the coming years.
In this vein, I've been focused on finding/creating tooling at the same level of abstraction as Go (net/http, database/sql + sqlx, etc) but in Haskell. So it ends up being a bit more ergonomic for a variety of reasons.
scotty (-> net/http), aeson (-> encoding/json), and postgresql-simple (-> database/sql) are pretty close, although aeson & postgresql-simple need some tooling on top to get them on par w/Go struct tag reflection imo.
I still love to use more advanced Haskell libraries, but there's something to be said for stitching together functions in IO with simple types.
scotty (-> net/http), aeson (-> encoding/json), and postgresql-simple (-> database/sql) are pretty close, although aeson & postgresql-simple need some tooling on top to get them on par w/Go struct tag reflection imo.
I still love to use more advanced Haskell libraries, but there's something to be said for stitching together functions in IO with simple types.
I think you're right that the level of abstraction is the same but the language ergonomics are drastically different. Go was designed so that anyone coming out of school could read/understand/write it very quickly. I'm not a Go expert and I can reason about code pretty well and even write some stuff.
That's absolutely NOT true of Haskell. It's a much more nuanced language and while I'm sure it's great once you learn it, the learning curve is steep. Because of that I think it's much easier to hire Go developers than Haskell developers too
That's absolutely NOT true of Haskell. It's a much more nuanced language and while I'm sure it's great once you learn it, the learning curve is steep. Because of that I think it's much easier to hire Go developers than Haskell developers too
Optimizing for the beginner isn't necessarily a good thing though. While that is true of Go, the trade-off is for even somewhat complex systems, Go starts to falter compared to Haskell. Local reasoning of Haskell scales nicely with complexity, at the cost of learning it.
There are economics at play here too. If your turnover rate is high (1-2 years even), the company can get the short end of the stick, while the employees get to pay the fixed cost of learning Haskell on company time.
My experience though is FP novices can get to doing new-hire-level tasks in Haskell within a couple weeks of mentorship. I've seen 0-FP-experience interns dive into applicative functor code in _Scala_ and have no trouble so long as we sat down and explained things from first principles (and motivated the value of the abstractions we use.)
I have actually found the opposite to be true for hiring. Every place I've worked has had more Haskell applicants than they knew what to do with. Largely because Haskell can make your company uniquely desirable in a sea of options.
The only time a Haskell company I worked at "had trouble hiring" was when we turned away countless Haskell-experienced developers due to the sole veto of a VPE over and over again. After months of observation, it was clear that he was actually starving the team of Haskell resources so he could build momentum to move away from it (despite the team being fine with the language)
There are economics at play here too. If your turnover rate is high (1-2 years even), the company can get the short end of the stick, while the employees get to pay the fixed cost of learning Haskell on company time.
My experience though is FP novices can get to doing new-hire-level tasks in Haskell within a couple weeks of mentorship. I've seen 0-FP-experience interns dive into applicative functor code in _Scala_ and have no trouble so long as we sat down and explained things from first principles (and motivated the value of the abstractions we use.)
I have actually found the opposite to be true for hiring. Every place I've worked has had more Haskell applicants than they knew what to do with. Largely because Haskell can make your company uniquely desirable in a sea of options.
The only time a Haskell company I worked at "had trouble hiring" was when we turned away countless Haskell-experienced developers due to the sole veto of a VPE over and over again. After months of observation, it was clear that he was actually starving the team of Haskell resources so he could build momentum to move away from it (despite the team being fine with the language)
> Go starts to falter compared to Haskell.
Not just Haskell, but any mature OO language/runtime as well (JVM, .NET). The fact remains that golang is popular because of Google's name behind it. While its concurrency model is somewhat decent, its warts get in the way very quickly for any non-trivial project.
Not just Haskell, but any mature OO language/runtime as well (JVM, .NET). The fact remains that golang is popular because of Google's name behind it. While its concurrency model is somewhat decent, its warts get in the way very quickly for any non-trivial project.
what do you define as non-trivial? I'm aware of a number of companies and projects that are definitely more than non-trivial.
I think Java/C# are verbose and ineffectual languages and people are seeking alternatives that make a lot more sense and deliver more power and speed.
I think Java/C# are verbose and ineffectual languages and people are seeking alternatives that make a lot more sense and deliver more power and speed.
Here's a bunch of things that Haskell has better solutions for that I run into in Go all the time:
* ResourceT is composable defer
* Streaming libraries (I use conduit due to familiarity) mean I don't have to write wonky loops to process data in constant memory
* ExceptT & Either is more composable error handling
* Parametric Polymorphism all around, but especially when it comes to concurrency (no need to hand-roll goroutine rube goldberg machines!) and collections (same but for hand-rolled loops)
* Async exceptions mean you can't have runaway threads without added implementation burden (I'm looking at you select + Context!)
* Sum types for a variety of use-cases :)
* ResourceT is composable defer
* Streaming libraries (I use conduit due to familiarity) mean I don't have to write wonky loops to process data in constant memory
* ExceptT & Either is more composable error handling
* Parametric Polymorphism all around, but especially when it comes to concurrency (no need to hand-roll goroutine rube goldberg machines!) and collections (same but for hand-rolled loops)
* Async exceptions mean you can't have runaway threads without added implementation burden (I'm looking at you select + Context!)
* Sum types for a variety of use-cases :)
> I've been starting up using Go as "fast Python" for web services / REST APIs.
I've been using Rust as "fast Python". It's super expressive and you can get things done quick and dirty if you want.
IMO, the one advantage Go has over Rust is the fast compile time. Rust's type system makes it worth the wait (which isn't even really that bad).
I've been using Rust as "fast Python". It's super expressive and you can get things done quick and dirty if you want.
IMO, the one advantage Go has over Rust is the fast compile time. Rust's type system makes it worth the wait (which isn't even really that bad).
its still why I love PHP, its super easy to hack together a website in under a hour does something stupid simple, and I'm not even talking about using any frameworks or libs, just pure PHP that does X simple thing and does it well