Three Things Go Needs More Than Generics

This page summarizes the projects mentioned and recommended in the original post on

Our great sponsors
  • Scout APM - Less time debugging, more time building
  • SonarLint - Deliver Cleaner and Safer Code - Right in Your IDE of Choice!
  • SaaSHub - Software Alternatives and Reviews
  • go

    The Go programming language

    There have been many[1] proposals for streamlining error handling in Go, including some coming from the Go Team, like the check/handle proposal from Marcel van Lohuizen[2] and the try proposal from Robert Griesemer[3].

    If anything, these proposals have been even more controversial than generics. The "try" proposal in particular, was probably the mildest proposal of them all, but it garnered a lot of criticism which amounted to "Go error handling is perfect as it is".

    Personally speaking, I vehemently disagree with the criticism. I think that error handling go is a meteor-crashing-into-earth level disaster and anyone happy with that must be completely out of their minds. But there does seem to be sizable (or at least very vocal) group of Go users who believe this boilerplate help understanding the code better, and I don't think we can reach common ground.

    It makes sense. Due to its design, Go naturally attracts people who we believe in can call "Imperative Explicitness Maximalism". This is the belief that the code is easier to read the closer the code is to to description to the way your machine executes code[4].

    The people who want to reduce boilerplate as much as possible may be motivated by various beliefs, but I think the most credible belief is that imperative explicitness hides the _purpose_ of your code behind nitty-gritty implementation details. From my perspective, in cases where the implementation is trivial (like error handling), you're adding nothing to understanding the implementation, while completely hiding the purpose and — at the same time — significantly increasing the signal-to-noise ratio in your code. So you get zero readability gains at the price of two significant readability losses.



  • errors

    Simple error handling primitives

  • Scout APM

    Less time debugging, more time building. Scout APM allows you to find and fix performance issues with no hassle. Now with error monitoring and external services monitoring, Scout is a developer's best friend when it comes to application development.

  • Go-1-2-Proposal---Immutability

    A a Go 1/2 language feature proposal to immutability

    I’ve a very small working experience with Go, tried it on few personal projects to test the language. Globally I really like it, and I’ve been pleased by a lot of « features » (simplicity, explicitness, readability of the standard lib etc…).

    One thing that I miss what a immutability story. You have values/references and, again I’m a beginner, I’ve the impression that passing references are favored. Wouldn’t it be nice if the compiler was able to check if you can mutate a reference or not? There are some proposals [1] that are discussed [2], that can be a nice evolution.


  • go101

    An online book focusing on Go syntax/semantics and runtime related things

    There are tons of immutable value proposals:

  • rustig

    A tool to detect code paths leading to Rust's panic handler

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

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts