2024-11-19
2472
#go#rust
Michiel Mulders
25770
Nov 19, 2024 ⋅ 8 min read

Go vs. Rust: When to use Rust and when to use Go

Michiel Mulders Michiel loves the Node.js and Go programming languages. A backend/core blockchain developer and avid writer, he's very passionate about blockchain technology.

Recent posts:

the replay nov 19

The Replay (11/19/25): React 19.2: The async shift is finally here

Discover what’s new in The Replay, LogRocket’s newsletter for dev and engineering leaders, in the November 19th issue.

Matt MacCormack
Nov 19, 2025 ⋅ 33 sec read

React 19.2: The async shift is finally here

Jack Herrington writes about how React 19.2 rebuilds async handling from the ground up with use(), , useTransition(), and now View Transitions.

Jack Herrington
Nov 19, 2025 ⋅ 5 min read

Offline-first frontend apps in 2025: IndexedDB and SQLite in the browser and beyond

The web has always had an uneasy relationship with connectivity. Most applications are designed as if the network will be […]

Alexander Godwin
Nov 18, 2025 ⋅ 11 min read
Real-Time AI In Next.js How To Stream Responses With The Vercel AI SDK

Real-time AI in Next.js: How to stream responses with the Vercel AI SDK

Streaming AI responses is one of the easiest ways to improve UX. Here’s how to implement it in a Next.js app using the Vercel AI SDK—typing effect, reasoning, and all.

Elijah Asaolu
Nov 17, 2025 ⋅ 9 min read
View all posts

14 Replies to "Go vs. Rust: When to use Rust and when to use Go"

  1. Your Rust thread example doesn’t spin up 10 threads, which I think was intended. It just runs a for loop in a single thread

  2. You didn’t compare Go very well in the last half of the post, in my opinion. You focused very heavily on how Rust approaches those topics instead of mentioning how Go handles them.

    A pet peeve of mine is also “Golang” is not the name of the language as they state on the site due to the confusion of registering Golang[.]org.

  3. What do you mean by the workd “subprocess” when talking about Go? Do you mean to say that the application will literally fork(…) off a child process? I’ll admit that I’ve never used Go, but that was not my impression of its architecture–I didn’t think that there was even a one-to-one correspondence of invoked goroutines to threads, but instead that it had an M-to-N threading model based on Go’s own implementation of pre-emption inside of its runtime. I would appreciate clarification.

  4. Hi Matt, thanks for your comment and honesty!

    The goal of this post is to provide a high-level overview between both languages for developers who need to decide between both languages. I’ve included some code snippets but don’t want to go into detail for each element. A great resource for looking up all discussed elements in this post is https://gobyexample.com/ 🙌

    Besides that, we’ve updated the post’s title from “Golang” to “Go”. Thanks for notifying us about this! 🙂

  5. Hi Ian, no worries, let me first clarify Goroutines using Go’s documentation (http://golang.org/doc/effective_go.html#goroutines).

    > They’re called goroutines because the existing terms—threads, coroutines, processes, and so on—convey inaccurate connotations. A goroutine has a simple model: it is a function executing concurrently with other goroutines in the same address space. It is lightweight, costing little more than the allocation of stack space. And the stacks start small, so they are cheap, and grow by allocating (and freeing) heap storage as required.

    > Goroutines are multiplexed onto multiple OS threads so if one should block, such as while waiting for I/O, others continue to run. Their design hides many of the complexities of thread creation and management.

    In short, Go multiplexes multiple goroutines into threads. So you are right about to M-to-N threading model. I’ve used the word “subprocess” here losely to make the concept more clear. It’s not 100% accurate. If this is confusing, feel free to ping me @michielmulders -> We want to avoid confusion! 🙂

  6. I think your language got confused between concurrency and parallelism while talking about Go. Go concurrency doesn’t spawn tasks across multiple CPUs, it maximises the single CPU utilisation by running sub processes concurrently (not in parallel)

  7. I get an error on line 7:
    thread::spawn(|| {

    error[E0373]: closure may outlive the current function, but it borrows `i`, which is owned by the current function

    Fortunately the Rust compiler tells me how to fix it:

    help: to force the closure to take ownership of `i` (and any other referenced variables), use the `move` keyword
    thread::spawn(move || {

  8. Certainly both languages are used for different purposes, we just need to go back to their origins, Go was designed by Google to solve a certain set of specific problems that they were having at that time, Rust was created with a completely different purpose in mind. Therefore each one of them is optimized for a different need.

    I’d say that go shines for its simplicity and fast development capabilities while Rust is strong when it comes to safety and good practices.

    In any case I think both of them are superior to Javascript 😉

  9. If you are looking for a job, learn Go. If you are future proofing your career for the next 10 years, learn Rust.

Leave a Reply

Would you be interested in joining LogRocket's developer community?

Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.

Sign up now