DEV Community

Cover image for Rust vs Go: Choosing Your Backend Language 🚀

Rust vs Go: Choosing Your Backend Language 🚀

Bruno Ciccarino λ on November 12, 2024

Thinking about Rust and Go for your backend? Let’s break down what makes each language tick so you can pick the one that best fits your project! C...
Collapse
 
mykhailokrainik profile image
Mykhailo Krainik

However, it should be noted that in large projects using Go with goroutines, there is often at least one "data racing", whereas Rust avoids this issue. Additionally, Go lacks built-in doctests, whereas Rust includes them, making it much easier to keep documentation up-to-date.

While I’m not certain about Go’s capabilities in this area, Rust’s strong type system makes significant object refactoring much easier. Rust’s type system guarantees ensure that if a program compiles, you can have confidence in its stability. This is particularly beneficial in a microservice architecture, where you need assurances that one service won’t disrupt the data processing sequence—a level of reliability that Rust inherently provides.

That said, Rust has its own set of challenges, such as issues with colored functions (sync - async problem). Some error messages, particularly in libraries like Diesel, can be extremely difficult to understand.

Collapse
 
tsolan profile image
Eugene

How have you determined/counted that?
You either lock data with mutex or don’t. Not the problem of the language.
Rust still does not guarantee performance: it’s much easier to build inefficient model in Rust due to complexity of the language than in Go.

Collapse
 
mykhailokrainik profile image
Mykhailo Krainik

That's right, Rust is not for beginners and you should understand what you are doing.

Collapse
 
pmbanugo profile image
Peter Mbanugo

however, it should be noted that in large projects using Go with goroutines, there is often at least one "data racing", whereas Rust avoids this issue.

Maybe those are projects you worked in that has programmers who don't understand Go's concurrency model and the side effects of a shared data. Go has synchronisation and Mutex which can be used to avoid race conditions. Rust avoids this by design, but it doesn't mean you can't use shared mutable state, you'd have to do it explicitly. ANd for that, Rust also provide Mutex for such situation.

Talking about their concurrency model, threads in Go are lightweight than Rust. Rust threads would use more memory than their Go counterpart, and requires more overhead to create than in Go. They both have their place and for some type of applications the differences are negligible. That's what I expected from the article, given that it's making comparison rather than just saying:

It’s a little more verbose than Go, but extremely powerful, with no risk of data races thanks to Rust’s ownership rules..

Collapse
 
mykhailokrainik profile image
Mykhailo Krainik

Could you provide some performance measurements to prove your point "Rust threads would use more memory than their Go counterpart", for example on datasets of 1,000 threads and 500,000 threads for both languages ​​so we can compare them?

Thread Thread
 
pmbanugo profile image
Peter Mbanugo

I guess you're familiar with both from your comment. SO you could run your own benchmark. Or google and reference the docs.

Rust uses OS threads which requires more overhead to create or pass message to. Go uses lightweight threads controlled instantiated in the userspace and controlled by the Go runtime. Erlang VM uses lightweight processes controlled by the Erlang VM, I think even more lightweight than Go's threads.

When it comes to performance, there's no straight telling that one languages performs faster in every kind of application. So you have to do your own benchmark, for your specific usecase.

For your Rust ref, this is one part of the docs that can give you a hint: doc.rust-lang.org/book/ch16-01-thr...

Collapse
 
brunociccarino profile image
Bruno Ciccarino λ

Good observation

Collapse
 
xuanlong5 profile image
xuanlong

gRPC in Golang's ecosytem is the best right now.

Collapse
 
kimss profile image
kelvin isaac phiri • Edited

Awasome, so helpful

Collapse
 
tsolan profile image
Eugene

Async requires runtimes and it does not come with the language itself.

Collapse
 
djnoslen3664 profile image
Pablo Carmona Sánchez

If I want to become a cyber security developer/analyst which language should I go with?

Collapse
 
brunociccarino profile image
Bruno Ciccarino λ

I would choose C++ or C and Python for cybersecurity, with C++ you go much deeper into how the computer works, or how networks work, etc... But if you are a beginner in the programming area I recommend starting with Python and then progressing to a C or a C++

Collapse
 
vemareddy_shrishveshredd profile image
VEMAREDDY SHRISHVESH REDDY 22115161

I just choose rust but got to know mid that rust is not a destination , It is a journey .

Collapse
 
khodyrev_ivan profile image
Ivan Khodyrev

Just pick Java or C# and you will be good. Go and Rust have their benefits for sure, but they lack expressive power and are a bit too low level for wide range of tasks. I mean writing high level code usually needs focussing on exact logic of a domain, but in Go your code will be full of excessive error handling stuff as well as "for" cycles, which make the code hardly readable and in Rust you will find yourself fighting the borrow checker and cryptic symbols a bit too much, rather than solving the real domain problems which are your actual goal in the end.

Collapse
 
sulaim_saed profile image
Sulaim Zaed

Good one

Collapse
 
martinhaeusler profile image
Martin Häusler

Backend? As in "server backend"? I default to JVM unless there's a damn good reason not to.

Collapse
 
skysingh04 profile image
Akash Singh

Honestly I feel like Rust and Go are languages are separate a normal everyday javascript / python developer with actual developers. Controversial but true! These two languages are more preferred by people who love to build software xD

Collapse
 
ktbsomen profile image
somen das

simple fucking nodejs or rather PHP 5.0