rustig VS go

Compare rustig vs go and see what are their differences.


A tool to detect code paths leading to Rust's panic handler (by Technolution)


The Go programming language (by golang)
Our great sponsors
  • Scout APM - Less time debugging, more time building
  • SonarQube - Static code analysis for 29 languages.
  • OPS - Build and Run Open Source Unikernels
rustig go
3 864
167 94,717
0.6% 2.1%
0.0 10.0
6 months ago 5 days ago
Rust Go
GNU General Public License v3.0 or later GNU General Public License v3.0 or later
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 rustig. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2021-10-03.
  • Three Things Go Needs More Than Generics
    7 projects | | 3 Oct 2021
    > Doesnt Rust have implicit panics on indexing out of bounds?

    It does yes. A fair number of other constructs can panic as well.

    > I wonder if any codebases lint those away.

    Clippy has a lint for indexing so probably.

    For the general case, it's almost impossible unless you're working on very low-level software (embedded, probably kernel-rust eventually) e.g. `std` assumes allocations can't fail, so any allocation will show up as a panic path. can actually uncover panic paths, but because of the above the results are quite noisy, and while it's possible to uncover bugs thanks to rustig it requires pretty ridiculous amounts of filtering.

  • Linus Torvalds on Rust support in kernel
    6 projects | | 16 Apr 2021
    This comment is strongly confused.

    > [1]

    That's a binary analysis tool. It is only approximate, and does not claim to be an accurate analysis like unsafe-checking and typechecking are:

    > All paths leading to panic! from one of those functions (whether actually used or not) will be reported.

    It also only works on x86_64 binaries.

    Panics are an ugly leftover from the bad old days before Rust had nice monad-like syntax for Result error-handling (the "?" syntax). It's time for panic to sunset.

    6 projects | | 16 Apr 2021
    This comment is strongly missinformed:

    1- panicking allocations are here to stay, because in lots of case, it's the most convenient behavior. BUT Rust is adding fallible allocations methods (prefixed with try_) which return a result instead of panicking in allocation failure.

    2- panics are catch-able as long as you don't compile your binary with panic=abort setting (and as long as you don't panic in your panic handler itself)

    3- panics can only occur in specific places (array indexing, allocations, utf-8 validation, unwrap, etc.) which are by definition known at compile-time, and there's tooling to catch these up [1].

    In practice, a might_panic annotation would add a lot of noise for pretty much everybody, because most of us mortals use panicking function all days and it's not a big deal. Obviously it is critical for Linux, but because it's relevant only to the minority of rust users, it doesn't make sense to include it in rustc itself: it's exactly the kind of situation where external tooling is the good option.



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 2022-01-28.
  • What's up with people wanting GNU-less things?
    9 projects | | 28 Jan 2022
    Go MIT/BSD like. Now a hugely popular language.
  • Is it ok to shadow the err variable?
    1 project | | 27 Jan 2022
    Unfortunately it was rejected. I'm not sure what it's successor is. (meta issue, front runner)
  • In defense of complicated programming languages
    2 projects | | 25 Jan 2022
    > There is something in video games called minmaxing, which is where you maximize one attribute at the expense of all of the others. For me C++, and now Rust, feel like they are guilty of this with their weight on zero-cost abstractions.

    > I think it was literally just meant to be the bare minimum to try to solve the most important parts of the problem, and at that it succeeds.

    In other words, it's the cost effectiveness of a language feature. You want features to provide as much value for as little cost as possible. This is what Go's going for; to paraphrase Russ Cox - "If a feature is not clearly above the bar, it's below it." [1].

    > Just as reducing programming language complexity doesn’t remove it, but only moves it around, removing runtime cost doesn’t remove it either. And the problem here isn’t that compile time isn’t a better time than runtime; it’s the hidden costs that suck. Sure, maybe the compile times in Rust will improve, and maybe it’s not even that big of a deal. But every little feature the language has puts some additional stress on the ecosystem. The language server has to bear this load, for example.

    The worst hidden cost that's often missed is the impact on the programmer.

    Take Python's controversial walrus operator [2]. If you look at the reasoning and the examples, the change seems reasonable. But consider that once the feature gets implemented, every single Python programmer will have to learn what it does in order to be able to read others' code. Does this feature provide enough to justify this weight? Undoubtedly not. Of course, it got implemented anyway, because the impact of making the code slightly more readable in some cases is clearly visible, but the cost incurred on every single programmer's mind is not.

    This is how languages reach untenable levels of complexity. By the time you realize your language is getting complex you're 20 features in and it's too late to turn back. "A frog dropped in a pot of boiling water will jump out of the pot to save his own life. If the frog is put into cool water and slowly brought to a boil, he will remain there until he is cooked through."



  • Change Go beta's SDK location
    1 project | | 25 Jan 2022
    x/dl/version: installer shouldn't create a new subdirectory of $HOME #26520
  • proposal: constraints: move to x/exp for Go 1.18 · Issue #50792
    1 project | | 24 Jan 2022
  • Please help a noob understand this basic golang behavior
    1 project | | 24 Jan 2022
    This is described in detail at
  • GitHub - ledongthuc/goterators: A utility library that supports aggregate & transforms functions Go 1.18 with generic. Such as filter, map, reduce, find, exist
    2 projects | | 24 Jan 2022
    Such as common constraints package for generic, they are ready to start with after thinking and using Generic in period:
  • Anyone know where I can find discussions around generic methods?
    3 projects | | 23 Jan 2022 was recent and IIRC there were some more bugs related to this a while ago.
    3 projects | | 23 Jan 2022
    There seems to be a general misunderstanding in this thread, that this is about having additional type parameters on methods. It's not. That particular sentence refers to this issue, about having local type-declarations in generic functions. That's simply a bug, which is intended to get fixed by go 1.19.
    3 projects | | 23 Jan 2022
    This seems to be the most interesting issue.

What are some alternatives?

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

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).

v - Simple, fast, safe, compiled language for developing maintainable software. Compiles itself in <1s with zero library dependencies.

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

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

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

RxGo - Reactive Extensions for the Go language.

gin-vue-admin - 基于vite+vue3+gin搭建的开发基础平台(已完成setup语法糖版本),集成jwt鉴权,权限管理,动态路由,分页封装,多点登录拦截,资源权限,上传下载,代码生成器,表单生成器等开发必备功能,五分钟一套CURD前后端代码。

Weaviate - Weaviate is a cloud-native, modular, real-time vector search engine

Gin - Gin is a HTTP web framework written in Go (Golang). It features a Martini-like API with much better performance -- up to 40 times faster. If you need smashing performance, get yourself some Gin.

crystal - The Crystal Programming Language

sqlc - Generate type-safe code from SQL

asdf - Extendable version manager with support for Ruby, Node.js, Elixir, Erlang & more