Go Developer Survey 2022 Q2 Results

The Rust is interesting, for sure, but I don't know what "?" is doing. I like the use of the question mark as it makes the act of calling the function a question - did it work or not? But what's not obvious is what happens if it did not work? What happens then? Where does the error object go? Is there something that represents the error? Hidden magic isn't good magic, in my opinion. Just be explicit.

Another issue with the Rust example is discipline. I don't know Rust, but the example you've given implies I can not include "?" in the call and just ignore any errors entirely? (What happens if I do that and there's an error? This isn't explicit enough.) Go, in comparison, does the opposite: it forces you to handle the error or literally ignore it. You cannot forget to deal with an error in Go.

And of course, Go gives you an error object you can work with (something I'm sure Rust does too, but it's not obvious to me as a none Rust developer.)

I prefer my languages to be statically typed, statically linked, and very explicit in their syntax. It results in a bit of extra work up front for compile and run time safeties, and the ability to easily re-read the code at a later date.

Rust code uses a Result type for error handling: it can either be Ok(T) or Err(E), never both.

The question mark operator tries to extract the value wrapped in Ok. If the Result is Err and not Ok, it returns the error. It’s not “hidden magic”, it’s a well-defined operator.

> I don't know Rust, but the example you've given implies I can not include "?" in the call and just ignore any errors entirely?

If you don’t unwrap the value from the result, then you still have a Result instead of a T, and will get a type error.

panic is certainly appropriate if programmer error left the application in an inconsistent state (an exceptional state, or exception for short as it is often referred to). I've never seen a Go developer, or developer in any other language for that matter, try to deal with these cases by hand.

COBOL is what you get when you optimize for readability by people who don't know how to program.

> The Rust is interesting, for sure, but I don't know what "?" is doing. I like the use of the question mark as it makes the act of calling the function a question - did it work or not? But what's not obvious is what happens if it did not work? What happens then? Where does the error object go? Is there something that represents the error? Hidden magic isn't good magic, in my opinion. Just be explicit.

It gets returned to the next level up, exactly like in the analogous Go code above. And that's how it always works, so you don't have to try to figure it out separately for each use of it you see.

> Another issue with the Rust example is discipline. I don't know Rust, but the example you've given implies I can not include "?" in the call and just ignore any errors entirely? (What happens if I do that and there's an error? This isn't explicit enough.) Go, in comparison, does the opposite: it forces you to handle the error or literally ignore it. You cannot forget to deal with an error in Go.

You actually can't do that and will get a compiler error if you try. Rust's type system distinguishes between "a number" and "either a number or an error". On the other hand, Go will let you forget to handle an error, if you do "res1, err1 = canFail()" but then forget to return an error yourself in the "err1" case. Rust's sum types prevent that mistake entirely.

> And of course, Go gives you an error object you can work with (something I'm sure Rust does too, but it's not obvious to me as a none Rust developer.)

Indeed it does. I consider it a good thing that you don't have to deal with language features you're not currently using, though.

> I prefer my languages to be statically typed, statically linked, and very explicit in their syntax. It results in a bit of extra work up front for compile and run time safeties, and the ability to easily re-read the code at a later date.

But Rust fits the bill for all of those things, and if you care about compile time safety, it does so way better than Go.

But it’s very easy to wrap one’s head around it. If the code under question mark returns an error, the function within which that code sits returns early with that error. If that function returns Result, the question mark essentially provides short, composable code.

I never personally had a problem with Go error handling but having prior experience with scala where I often used Try(…).toEither, I love Rust’s ?.