rust VS go

Compare rust vs go and see what are their differences.


Empowering everyone to build reliable and efficient software. (by rust-lang)


The Go programming language (by golang)
Our great sponsors
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern identity platform for B2B SaaS
  • SaaSHub - Software Alternatives and Reviews
rust go
2660 2050
90,398 118,162
1.1% 0.6%
10.0 9.9
5 days ago 4 days ago
Rust Go
GNU General Public License v3.0 or later BSD 3-clause "New" or "Revised" License
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.


Posts with mentions or reviews of rust. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2024-03-01.
  • Why do we need for an Undefined Behavior Annex to C++
    2 projects | | 1 Mar 2024
    On Unix targets, it installs a signal handler for SIGSEGV and checks if the faulting address falls within the range of the stack guards. See

    The stack guards would normally be setup by the system runtime (e.g. kernel in the case of the main thread stack, libc for thread stacks), not Rust's runtime. Likewise, stack probes that ensure stack operations don't skip guard pages are usually (always?) emitted by the compiler backend (e.g. GCC, LLVM), not Rust's instrumentation, per se.

    In this sense Rust isn't doing anything different than any other typical C or C++ binary, except hijacking SIGSEGV as Rust does is normally frowned upon, especially when it's merely for aesthetics--i.e. printing a pretty message. Also, attempting to introspect current thread metadata from a signal handler gives me pause. I'm not familiar enough with Rust to down the underlying code. I presume it's using at some POSIX threads interfaces, but POSIX thread interfaces aren't async-signal-safe, and though SIGSEGV is a synchronous signal, that doesn't mean the Rust runtime isn't technically relying on undefined behavior.

  • Talc – A fast and flexible allocator for no_std and WebAssembly
    4 projects | | 28 Feb 2024
    You don't. It currently requires `-Z build-std=std,panic_abort` and some nightly flags (e.g. `#![feature(restricted_std)]`) but you can build `std` programs on bare metal targets. I can't remember exactly what it does if you try to open files or start threads or whatever (probably panics?) but you can compile and run it. If you don't do any of those things it works fine.

    Currently the `sys` crate implementation is hard-coded into the compiler but eventually you will be able to provide it without modifying the compiler so you can e.g. target a RTOS or whatever.

    It looks like that work started really recently actually:

  • Learning Rust: A clean start
    5 projects | | 26 Feb 2024
    I've decided it's time to learn Rust and in order to keep myself motivated I'm going to keep a record of how the learning is going here.
  • Delving Deeper: Enriching Microservices with Golang with CloudWeGo
    7 projects | | 22 Feb 2024
    Built for the modern development landscape by embracing both Golang and Rust, CloudWeGo delivers advanced features and excellent performance metrics. As proof of its performance, benchmark tests have shown that Kitex surpasses gRPC by over 4 times in terms of QPS and latency, with a throughput increased by 51% - 70% in terms of QPS (Queries Per Second) and latency.
  • Fast memory vulnerabilities, written in 100% safe Rust
    9 projects | | 20 Feb 2024

    “Similarly, the reason why niko's approach is not yet implemented is simply that getting the type system to a point where we even can implement this is Hard. Fixing this bug is blocked on replacing the existing trait solver(s): #107374. A clean fix for this issue (and the ability to even consider using proof objects), will then also be blocked blocked on coinductive trait goals and explicit well formed bounds. We should then be able to add implications to the trait solver.

    So I guess the status is that we're slowly getting there but it is very hard, especially as we have to be incredibly careful to not break backwards compatibility.”

    9 projects | | 20 Feb 2024
    Because Rust doesn't have a specification, we can argue back and forth forever about whether something is part of the "language design". The point is that we know how to solve the problem by desugaring [1] in a way that everyone basically expects to happen already. It's not going to break a significant amount of code: even the bigger sledgehammer of banning contravariance on function types was measured to not have much of an impact.

    As far as I can tell, the main reason to argue "language design" vs. "compiler bug" is to imply that language design issues threaten to bring down the entire foundation of the language. It doesn't work like that. Rust's type system isn't like a mathematical proof, where either the theorem is true or it's false and one mistake in the proof could invalidate the whole thing. It's a tool to help programmers avoid memory safety issues, and it's proven to be extremely good at that in practice. If there are problems with Rust's type system, they're identified and patched.


    9 projects | | 20 Feb 2024
    I believe it really is a flaw in the language, it's impossible for any compiler to check contravariance properly in this edge case. I don't think anything in this link is incorrect: (and it seems the rustc types team endorses this analysis)

    I am not at all familiar with Miri. Does Miri consider a slightly different dialect of Rust where implicit constraints like this become explicit but inferred? Sort of like this proposal from the GH issue: but the "where" clause is inferred at compile time. If so I wouldn't call that a "fix" so much as a partial mitigation, useful for static analysis but not actually a solution to the problem in rustc. I believe that inference problem is undecidable in general and that rustc would need to do something else.

    9 projects | | 20 Feb 2024
    Seems to rely on at least one known compiler bug (admittedly one open since 2015)
  • json-responder 1.1: dynamic path resolution
    3 projects | | 12 Feb 2024
    hyper-based HTTP server generating JSON responses. Written in Rust.
  • Rust GraphQL APIs for NodeJS Developers: Introduction
    7 projects | | 8 Feb 2024
    In my usual NodeJS tech stack, which includes GraphQL, NestJS, SQL (predominantly PostgreSQL with MikroORM), I encountered these limitations. To overcome them, I've developed a new stack utilizing Rust, which still offers some ease of development:


Posts with mentions or reviews of go. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2024-03-01.
  • 🤓 My top 3 Go packages that I wish I'd known about earlier
    6 projects | | 1 Mar 2024
    ✨ In recent months, I have been developing web projects using GOTTHA stack: Go + Templ + Tailwind CSS + htmx + Alpine.js. As soon as I'm ready to talk about all the subtleties and pitfalls, I'll post it on my social networks.
  • Memory Safe TLS Library Now Has AWS Crypto and FIPS
    4 projects | | 29 Feb 2024
    And they now have to deal with the same kind of timing attacks related stuff as everybody else, so they lag behind:
  • querySrv errors when connecting to MongoDB Atlas
    3 projects | | 29 Feb 2024
    Building with Go 1.11+ and using connection strings with the mongodb+srv scheme is unfortunately incompatible with some DNS servers in the wild due to the change introduced in You may receive an error with the message "cannot unmarshal DNS message" while running an operation when using DNS servers that non-compliantly compress SRV records. Old versions of kube-dns and the native DNS resolver (systemd-resolver) on Ubuntu 18.04 are known to be non-compliant in this manner. We suggest using a different DNS server ( is the common default), and, if that's not possible, avoiding the mongodb+srv scheme.
  • Fast persistent recoverable log and key-value store
    3 projects | | 24 Feb 2024
    Of course it does: just call TCPConn.SetNoDelay(false).


  • Go + Hypermedia - A Learning Journey (Part 1)
    6 projects | | 23 Feb 2024
    Go - programming language
  • Delving Deeper: Enriching Microservices with Golang with CloudWeGo
    7 projects | | 22 Feb 2024
    Built for the modern development landscape by embracing both Golang and Rust, CloudWeGo delivers advanced features and excellent performance metrics. As proof of its performance, benchmark tests have shown that Kitex surpasses gRPC by over 4 times in terms of QPS and latency, with a throughput increased by 51% - 70% in terms of QPS (Queries Per Second) and latency.
  • A beginner's guide to constant-time cryptography (2017)
    6 projects | | 22 Feb 2024
    I noticed in July of 2022 that Go did exactly the vulnerable example and reported it to the security team.

    It was fixed as of Go 1.21


    The article cites JavaScript, which is not constant time. There's no sure way to do constant time operations in JavaScript and thus no secure way to do crypto directly in Javascript. Browsers like Firefox depend on low level calls which should be implemented in languages that are constant time capable.

    JavaScript needs something like constant time WASM in order to do crypto securely, but seeing the only constant time WASM project on GitHub has only 16 stars and the last commit was 2 years ago, it doesn't appear to have much interest.

    However, for JavaScript, I recommend Paul's library Noble which is "hardened to be algorithmically constant time". It is by far the best library available for JavaScript.

  • Maybe Everything Is a Coroutine
    3 projects | | 14 Feb 2024
    > Channels are specifically designed to be a high-speed data bus between goroutines, rather than ever use more expensive and less safe shared memory.

    What do you mean? Shared memory is not more expensive. Memory is memory, it's either cached on your core or not. In fact, Go still has to issue fence instructions to ensure that the memory it observes after a channel read is sequenced after any writes to that memory, so it's at best the same cost you'd have with other forms of inter-thread communication in any language.

    Anyway, even that is missing the point. Go still shares memory if you used a reference type, and most types in Go end up being reference types, because it's the only way to have a variable-sized data structure (and while we're at it, string is the only variable-sized data structure that's also immutable).

    The bigger problem is that Go doesn't enforce thread safety. Channels only make communication safe if you send types that don't contain any mutable references... but Go doesn't give you any way to define your own immutable types. That basically limits you to just string. Instead people send slices, maps, pointers to structs, interfaces, etc. and those are all mutable and Go does nothing to enforce that you didn't mutate them.

    Even if all of that somehow wasn't true, many parallelism patterns simply don't map well to channels, so you still end up with mutexes in many parts of real world projects. Even if you don't see the mutexes, they're in your libraries. For example, Go's http.Transport contains a connection pool, but it uses mutexes instead of channels because even the Go team knows that mutexes still make sense for many real-world patterns.

    This whole "channels make Go safe" myth has to stop. It's confused a generation of Go programmers about the actual safety (and apparently performance) tradeoffs of channels. They do not make Go safer (mutable references are still mutable after being sent on a channel), they do not make it faster (the memory still has to be fenced), and heck while we're at it, they do not even make it simpler ("idiomatic" use of channels introduces many ways that goroutines can deadlock, and deadlock-free use of channels is much more complicated and less idiomatic).

    The most useful thing about channels is that you can select{} on multiple of them so they partly compensate for Go's limitations around selecting on futures in general. They're a poor substitute when you actually needed to select on something like IO, where io.Reader/Writer still don't interact with select, channels, or even cancellation directly.

  • Context Control in Go
    2 projects | | 9 Feb 2024
  • Go 1.22 Release Notes
    5 projects | | 6 Feb 2024
    Is the memory issue reported in go 1.21 version in linux OS resolved in go 1.22?

What are some alternatives?

When comparing rust and go you can also consider the following projects:

carbon-lang - Carbon Language's main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)

v - Simple, fast, safe, compiled language for developing maintainable software. Compiles itself in <1s with zero library dependencies. Supports automatic C => V translation.

TinyGo - Go compiler for small places. Microcontrollers, WebAssembly (WASM/WASI), and command-line tools. Based on LLVM.

zig - General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.

Nim - Nim is a statically typed compiled systems programming language. It combines successful concepts from mature languages like Python, Ada and Modula. Its design focuses on efficiency, expressiveness, and elegance (in that order of priority).

Angular - Deliver web apps with confidence 🚀

Odin - Odin Programming Language

Elixir - Elixir is a dynamic, functional language for building scalable and maintainable applications

golang-developer-roadmap - Roadmap to becoming a Go developer in 2020

RxGo - Reactive Extensions for the Go language.