Ask HN: Rust or Golang?
39 comments
JavaScript for web development tbh
Rust, too. WebAssembly is going to be a big deal to some people, and the rust tools are good for that.
Sorry for the misunderstanding, I meant back-end development. I just edited the question.
I like Go because of its fast compile times more than anything. It's like a scripting language that compiles to fast native code.
golang has much more libraries available to be reused (not as much as java but still much more than rust)
If you’re working on a professional project as a freelancer, something to consider is the ease with which you can transfer ownership of your project to another developer. I can’t say which is better, rust or go, but just wanted to mention this consideration
From the outside Go seems to be the clear winner in terms of popularity for back end web development and services. Maybe that will change for Rust in the future, things like Rocket look very nice but overall I think Rust is targeting a different area.
Go for backend web services.
Go in my mind is a replacement for java/c#
Rust is a replacement for c/c++ Do you see that much development for backend web services in C or C++?
Go in my mind is a replacement for java/c#
Rust is a replacement for c/c++ Do you see that much development for backend web services in C or C++?
> Rust is a replacement for c/c++
It is modern language with big-enough community and many features making it good backed language. It goes far beyond C/C++ niche.
It is modern language with big-enough community and many features making it good backed language. It goes far beyond C/C++ niche.
I don't have much non-academic experience with Java but what is C# lacking that Go has? The reportedly fast compile times have me curious, Go is I think #1 on my list of new languages to learn.
Go applications don't use the CLR, just compiled binary. It's a lot more lightweight than C#. I'd use them for different things. Go is replacing Python for me in certain places.
.NET Native, CoreRT, IL2CPP.
It's more about what it doesn't have.
> what is C# lacking that Go has
Google support and presence in the minds of non-ms shops
Google support and presence in the minds of non-ms shops
Kubernetes? -> learn go.
I hope rust will become soon a (really) good place for embedded software.
Go has a distinct C flavor, and Rust has a moderate C++ flavor.
Go has the key design features of asynchronous concurrency (go-routines) and message passing, as well as fast compile times. Go is backed by Google.
Rust has the distinct design feature of memory safety, particularly with its implication of pointers, for concurrent processing. Rust is backed my Mozilla.
Since both share that C/C++ ancestry, I wouldn’t expect that you would gain too much, or lose too much, by picking one over the other if you’re interested in just learning the language to become a better programmer. If you’re doing it for work, then you’re going to use whatever they have already set up for you. So, use that one... which is probably Java...
Coming from a company which is switching from Golang to Rust, I can definately say that this article is pretty true and needs to be taken into account: https://blog.discord.com/why-discord-is-switching-from-go-to...
Even though it's "old", but back in July (2020) we could replicate this behavior.
One main aspect of "why" we are swithcing to rust is that our project needs to handle large amounts of data (think > 15Gb in RAM). When you try to work with large data structures within RAM, the GC of golang goes a little nuts. There's many different memory issues that we found, for example, when we put a larger load on our project, there's allocations happening, but Golang won't deallocate or release the memory to the OS unless the load goes down.
But if you don't have to work with large data structures and need a speedy multithreaded solution, then you can definately go with golang.
I would also like to point out that it's not very accurate to say that Rust has moderate C++ flavor. It has C flavor with some "differences" when it comes to variables and their lifetimes as well as some different minor flavors of other languages. For example, it has channels, which work in a very similar way as in golang. It has stream (functional) programming to be done as easy as with Java. The biggest issue with Rust is that there's no well established libraries to work with and sometimes you get major incompatibilities or the issue when you have to so many different 3rd party libraries, that it becomes unconfortable to manage.
Even though it's "old", but back in July (2020) we could replicate this behavior.
One main aspect of "why" we are swithcing to rust is that our project needs to handle large amounts of data (think > 15Gb in RAM). When you try to work with large data structures within RAM, the GC of golang goes a little nuts. There's many different memory issues that we found, for example, when we put a larger load on our project, there's allocations happening, but Golang won't deallocate or release the memory to the OS unless the load goes down.
But if you don't have to work with large data structures and need a speedy multithreaded solution, then you can definately go with golang.
I would also like to point out that it's not very accurate to say that Rust has moderate C++ flavor. It has C flavor with some "differences" when it comes to variables and their lifetimes as well as some different minor flavors of other languages. For example, it has channels, which work in a very similar way as in golang. It has stream (functional) programming to be done as easy as with Java. The biggest issue with Rust is that there's no well established libraries to work with and sometimes you get major incompatibilities or the issue when you have to so many different 3rd party libraries, that it becomes unconfortable to manage.
I am a bit tired of seeing this topic come up again and again on Reddit or HN. You may have as well, asked if someone preferred blue or orange.
The choice of a programming language (without considering specific details of the application) is very subjective with a low signal to noise ratio. What looks aesthetic or ergonomic for others will most likely not apply to you.
For most practical applications things like the runtime, library ecosystem and other factors become more important and just "Rust or Golang for backend development?" isn't very helpful.
The choice of a programming language (without considering specific details of the application) is very subjective with a low signal to noise ratio. What looks aesthetic or ergonomic for others will most likely not apply to you.
For most practical applications things like the runtime, library ecosystem and other factors become more important and just "Rust or Golang for backend development?" isn't very helpful.
Also, why is the question always “Rust or go?”, excluding all other languages?
If that is “because those are the hip languages”, that’s not a good reason to make a choice for years. How long will they stay hip?
If it is an ideological choice, I don’t understand what the ideology is. Go is not more open than, say, C#, Java, or Swift (all open source, but backed by a huge company that largely controls the evolution of the language).
Rust is more of an underdog, being backed by a relatively, smaller player.
So, what’s the argument to limit the choice to these two?
If that is “because those are the hip languages”, that’s not a good reason to make a choice for years. How long will they stay hip?
If it is an ideological choice, I don’t understand what the ideology is. Go is not more open than, say, C#, Java, or Swift (all open source, but backed by a huge company that largely controls the evolution of the language).
Rust is more of an underdog, being backed by a relatively, smaller player.
So, what’s the argument to limit the choice to these two?
> library ecosystem and other factors become more important
I guess this is what OP is asking here
I guess this is what OP is asking here
But what you need out of those "other factors" varies based on your business requirements, which OP didn't share. What we're going to end up with (what we always end up with in these kind of threads) is ~35% of comments are from folks who've only ever used Go, so they suggest Go. ~35% are from those who've only used Rust, and they suggest Rust. ~20% are from people who've used both but in wildly different environments such that it's hard to do any real comparison. The remaining ~10% or less who have used both languages in suitably similar production-level environments are going to be split more-or-less evenly between the two because they've had different business constraints. An exceedingly small minority will have used both in the same business environment, and they're going to suggest whichever one they used second.
And that's even ignoring the much more important fact that there are about 50 other back-end languages that are likely as good or better candidates, but not trendy enough to warrant mentioning.
And that's even ignoring the much more important fact that there are about 50 other back-end languages that are likely as good or better candidates, but not trendy enough to warrant mentioning.
But what is the downside to what you are saying ? We have experiences from golang devs and rust devs all available to be compared here in a thread and other thread (the discussions change as time changes)
Isn't this why we are here ? Share what you have experience with, who even knows everything ?
Isn't this why we are here ? Share what you have experience with, who even knows everything ?
I think it really depends on what kind of backend you're writing. If you're writing a simple CRUD web backend, I'd suggest avoiding Rust because other backend frameworks have a lot of boring side stuff (CSRF, security headers, form validation, you name it) already implemented while the more recent Rust frameworks are still missing them all over the place, requiring you to implement them yourself. It's not a lot of work to do it yourself, but it's boring, easy to get wrong and you need to check with docs and specs to see if what you're doing is even correct. For those cases, I'd recommend a classic such as Java+Spring or C#+ASP Core with their excellent plugins and addon ecosystems.
If you're handling big data structures with loads of allocations and deallocations and complicated algorithms, Rust might be the language for you. The language shines and the lack of a GC shines at those workloads. The same is true for batched workloads that can be processed in parallel, because the restrictions Rust puts on object access makes it excellent to make assumptions about data access and ownership with little or no performance wasted on the framework around the threading library.
As much as I like Rust and projects like Rocket.rs, I'm just not sure if the ecosystem is mature enough for it to be used for a production backend for web services. I'd wait a year or two for the Rust frameworks to gain more features and more quality of life improvements before actually using it.
If you're handling big data structures with loads of allocations and deallocations and complicated algorithms, Rust might be the language for you. The language shines and the lack of a GC shines at those workloads. The same is true for batched workloads that can be processed in parallel, because the restrictions Rust puts on object access makes it excellent to make assumptions about data access and ownership with little or no performance wasted on the framework around the threading library.
As much as I like Rust and projects like Rocket.rs, I'm just not sure if the ecosystem is mature enough for it to be used for a production backend for web services. I'd wait a year or two for the Rust frameworks to gain more features and more quality of life improvements before actually using it.
I use both frequently, in and out of work. And I can’t state enough that people need to stop asking this question.
These languages - I would throw Swift in there as well - are “apples and oranges” and shouldn’t really be compared. Depending on your use case, they all have different merits over each other.
To actually make a worthwhile recommendation, you’d have to elaborate on what you mean by backend service. RESTful? gRPC? Something else? When it comes to the first two scenarios, I think Go enables more rapid development and has a stronger library ecosystem.
These languages - I would throw Swift in there as well - are “apples and oranges” and shouldn’t really be compared. Depending on your use case, they all have different merits over each other.
To actually make a worthwhile recommendation, you’d have to elaborate on what you mean by backend service. RESTful? gRPC? Something else? When it comes to the first two scenarios, I think Go enables more rapid development and has a stronger library ecosystem.
Update: Sorry about not providing details on the submission. Here is additional details on what I'm looking for I'm asking language/framework recommendation for the RESTful API that needs to be fast and secure, so security and performance of the framework is very important.
Feel free to recommend any Go/Rust framework. Also why do you prefer that language?
Feel free to recommend any Go/Rust framework. Also why do you prefer that language?
For Rust, I am using Actix https://github.com/actix/actix-web .
Without better definition of "secure" and "performance" there is no way to help you.
Both of them are used and exposed publicly by numerous companies, so ootb they good enough for any API. For 99.999% percent of people both are performant enough. Rust will win on memory usage, in some cases significantly, and will win on performance by a smaller margin, but run your own benchmark.
This is an interesting article about why npm uses Rust instead of something else: https://www.infoq.com/news/2019/03/rust-npm-performance/
>performance of the framework is very important
No, its not. Whatever you do with it, will be 100-1000x slower than what framework does. Making decision on something that takes 0.01% of time spend on request handling makes no sense. Optimize your code and data sources, don't worry about framework,
> Also why do you prefer that language?
Tons of modern features. Algebraic data types (this eliminates null-pointer errors completely, which you can't say about Go), generics, borrow checker, pattern matching, macros, general focus on correctness of your code. All of that composes nicely and allows to produce correct and readable code.
Both of them are used and exposed publicly by numerous companies, so ootb they good enough for any API. For 99.999% percent of people both are performant enough. Rust will win on memory usage, in some cases significantly, and will win on performance by a smaller margin, but run your own benchmark.
This is an interesting article about why npm uses Rust instead of something else: https://www.infoq.com/news/2019/03/rust-npm-performance/
>performance of the framework is very important
No, its not. Whatever you do with it, will be 100-1000x slower than what framework does. Making decision on something that takes 0.01% of time spend on request handling makes no sense. Optimize your code and data sources, don't worry about framework,
> Also why do you prefer that language?
Tons of modern features. Algebraic data types (this eliminates null-pointer errors completely, which you can't say about Go), generics, borrow checker, pattern matching, macros, general focus on correctness of your code. All of that composes nicely and allows to produce correct and readable code.
If you want to get started quickly, Go. Better yet, Python or Ruby or Java, which have far more available frameworks and libraries. If you care about quality, performance and memory usage enough to invest more time into learning how to use it, Rust.
Between Go and Rust, Go wins on popularity and amount of libraries, compilation speed (not an issue for me really, but some people care more about that) and its easy to get someone who knows it. Rust wins on quality of libraries, tooling and the code you'll produce.
Rust gets dependency management right, and the language is actually worth learning. Golang is meh at best.
You will need to spend some time building yourself a web framework though, if you want one, as existing ones are very basic. That's a serious issue with Rust atm.
Between Go and Rust, Go wins on popularity and amount of libraries, compilation speed (not an issue for me really, but some people care more about that) and its easy to get someone who knows it. Rust wins on quality of libraries, tooling and the code you'll produce.
Rust gets dependency management right, and the language is actually worth learning. Golang is meh at best.
You will need to spend some time building yourself a web framework though, if you want one, as existing ones are very basic. That's a serious issue with Rust atm.
I feel like choosing between the two for a new project comes down to one factor: do you truly need to maximize performance? Be honest.
If yes, Rust: no GC, consider the rayon crate for concurrency. Higher learning curve, ecosystem may not be as mature for certain areas yet (outside of web assembly).
If no, Go: lower learning curve, runtime-managed concurrency, more ecosystem maturity for most enterprise software tasks.
If yes, Rust: no GC, consider the rayon crate for concurrency. Higher learning curve, ecosystem may not be as mature for certain areas yet (outside of web assembly).
If no, Go: lower learning curve, runtime-managed concurrency, more ecosystem maturity for most enterprise software tasks.
Come up with a small project and code it in both. It will help you decide which feels better to you.
But in my experience, I wouldn't pick Go. Having the GC makes it easier to just get things done than with Rust, but it doesn't take long to feel like all the logic is lost to the noise of error handling. It also seems easy to miss closing resources with defer since there's nothing like .NET's IDisposable to look for.
If you need a large variety of battle-tested libraries, I wouldn't choose either though. Python, C#, Java, and C++ are better choices there.
But in my experience, I wouldn't pick Go. Having the GC makes it easier to just get things done than with Rust, but it doesn't take long to feel like all the logic is lost to the noise of error handling. It also seems easy to miss closing resources with defer since there's nothing like .NET's IDisposable to look for.
If you need a large variety of battle-tested libraries, I wouldn't choose either though. Python, C#, Java, and C++ are better choices there.
[deleted]
I would choose Rust every time. The abstraction facilities in Go just are too non-existent.
It seems to me that Go is purpose built for writing network services like a backend.
Rust is a more general purpose language, and has been designed from the start to work well with existing C-style libraries.
Both have their place, but you asked about a backend. Go shines there.
Rust is a more general purpose language, and has been designed from the start to work well with existing C-style libraries.
Both have their place, but you asked about a backend. Go shines there.
I don't see the two as directly comparible.
Go is garbage collected, Rust is not. Go is compact, Rust has lots of functional programming bells and whistles like algebraic data types. Go compiles quickly, Rust takes a while. Go has first class support for concurrency, Rust does not.
Roll with whichever you like. For me, as a side-language, it's Go, because I already enjoy and use Haskell, and I feel like Go contrasts more with Haskell. If I didn't know Haskell, I'd probably choose Rust.
If it wasn't for a side-language, but was for a specific project, I'd choose on the basis of available libraries.
Go is garbage collected, Rust is not. Go is compact, Rust has lots of functional programming bells and whistles like algebraic data types. Go compiles quickly, Rust takes a while. Go has first class support for concurrency, Rust does not.
Roll with whichever you like. For me, as a side-language, it's Go, because I already enjoy and use Haskell, and I feel like Go contrasts more with Haskell. If I didn't know Haskell, I'd probably choose Rust.
If it wasn't for a side-language, but was for a specific project, I'd choose on the basis of available libraries.
GO v. Rust is a tough compare and kind of a bad question.
I work in a very large C/C++ organization and the build concern over our 1000s of libraries is a giant chore to do well in a DEVOPS context. GO is so much better. RUST is routinely seen worse than GO here. Compilation is slow but anecdotally dependency management in RUST is orders of 10 better that C/C++ and comparable to GO.
There are a few stories in HN where cloud providers, big data types have been burned by GC. But it's not routine. Their ability to find and fix root cause required in-depth diagnostics. If your system is complex your tooling better have good support there. GO definitely does.
Here's what I say: if you are I/O bound GO is just fine. GO has great libraries for all manner of HTML/socket work. It works well with protobuf, compression, REST APIs, UUIDs. Its SQL library is great.
If you are low latency bound or need latency in a narrow range you'd better do a POC in GO and RUST and make an informed choice. There's plenty of GO programmers and fewer good RUST programmers.
There are more HN posts from people learning RUST reporting the borrow aspect of RUST is tough to learn and tougher to do right. RUST kind of memory management isn't routinely found in other languages.
RUST is meant to be a better C++. It's meant to excel in the niche area of system like libraries by yielding C/C++ performance without memory C/C++ memory problems which are perhaps the largest security attack area. RUST will not remove all data races. It reduces them - which is good - but do not over interpret. In this sense RUST is smart: they've picked a good market, and their tools make good sense there.
C++ is not necessarily the go-to for bare metal programming. So neither would RUST be. Most of the Linux kernel is C not C++, for example. We know that calling C-libraries from a non-C language is routine. To RUST? Not sure. To C++? That's a harder ask but you're probably not the only one who's doing it - at least that.
I work in a very large C/C++ organization and the build concern over our 1000s of libraries is a giant chore to do well in a DEVOPS context. GO is so much better. RUST is routinely seen worse than GO here. Compilation is slow but anecdotally dependency management in RUST is orders of 10 better that C/C++ and comparable to GO.
There are a few stories in HN where cloud providers, big data types have been burned by GC. But it's not routine. Their ability to find and fix root cause required in-depth diagnostics. If your system is complex your tooling better have good support there. GO definitely does.
Here's what I say: if you are I/O bound GO is just fine. GO has great libraries for all manner of HTML/socket work. It works well with protobuf, compression, REST APIs, UUIDs. Its SQL library is great.
If you are low latency bound or need latency in a narrow range you'd better do a POC in GO and RUST and make an informed choice. There's plenty of GO programmers and fewer good RUST programmers.
There are more HN posts from people learning RUST reporting the borrow aspect of RUST is tough to learn and tougher to do right. RUST kind of memory management isn't routinely found in other languages.
RUST is meant to be a better C++. It's meant to excel in the niche area of system like libraries by yielding C/C++ performance without memory C/C++ memory problems which are perhaps the largest security attack area. RUST will not remove all data races. It reduces them - which is good - but do not over interpret. In this sense RUST is smart: they've picked a good market, and their tools make good sense there.
C++ is not necessarily the go-to for bare metal programming. So neither would RUST be. Most of the Linux kernel is C not C++, for example. We know that calling C-libraries from a non-C language is routine. To RUST? Not sure. To C++? That's a harder ask but you're probably not the only one who's doing it - at least that.
if you're end goal is to be productive and build something shippable, then I would suggest Go. You focus on building what you want and dont have to explicitly deal with memory management etc. But, if you want to get into nitty-gritty details of things and have complete control over things you need to build something performance in mind, then choose Rust.
Coming from Java/Python background, Go feels like a fresh breeze. You can easily get things done with Go.
Coming from Java/Python background, Go feels like a fresh breeze. You can easily get things done with Go.
Depends..without context this question has no meaning...
Anyway, speed-wise, go will get you further faster.
Job-wise, go will get you way mor opportunities.
Performance-wise, rust will be always faster, no way around that.
Future-proof-wise, go, no contest.
Popularity-wise, go, hands down.
tl;dr rust is very niche, low-level, performance-oriented language and should be used in such use-cases. Anything else, Go will do better.
Anyway, speed-wise, go will get you further faster.
Job-wise, go will get you way mor opportunities.
Performance-wise, rust will be always faster, no way around that.
Future-proof-wise, go, no contest.
Popularity-wise, go, hands down.
tl;dr rust is very niche, low-level, performance-oriented language and should be used in such use-cases. Anything else, Go will do better.
Which language would you recommend for the back-end development?