Lies we tell ourselves to keep using Golang (2022)

Post by kybernetikos » Tue, Nov 26, 2024, 5:13 PM UTC

monksy wrote: post #79

kybernetikos wrote: post #15

Earlier quoted context omitted.

I think this is exactly the right way to understand Go - it's targetted at building servers in environments where having strong consistency of code and a short ramp up time for junior engineers is valuable - i.e. it's perfect for all the big corp scenarios that Java was used for. I think maybe the more common, but less helpful comparison of go vs rust comes from the fact that they are both part of a new wave of langu…

> consistency of code There are many stylecheck tools that should be apart of a good stack. Accepting the creator's style is putting a lot of weight on their opinion. Most organizations have their own preferences for good reason. > short ramp up for junior engineers Junior engineers aren't a place you're concerned on being productive. Most of the time at that stage in someone's career they should be learning more, ge…

Post by Slartie » Tue, Nov 26, 2024, 5:21 PM UTC

forrestthewoods wrote: post #18

afiodorov wrote: post #14

Not sure why Go is compared to Rust all the time, whilst most appropriate comparison is Java.

Because someone decides what language to write a new thing in is very likely to consider Go and Rust. They are very unlikely to consider Java. Are Rust and Go sufficiently different that they should each be chosen in different cases? Sure! But that’s literally why someone would consider both and pick one.

Post by sunshowers » Tue, Nov 26, 2024, 5:34 PM UTC

quotemstr wrote: post #105

pyrale wrote: post #66

Earlier quoted context omitted.

Exception and explicit on-the-spot handling are not the only two ways to handle failing processes. Optional/result types wrapping the are a clean way to let devs handle errors, for instance, and chaining operations on them without handling errors at every step is pretty ergonomic.

Rust's error handling evolution is hilarious. In the beginning, the language designers threw out exceptions --- mostly, I think, because Go was fashionable at the time. Then, slowly, Rust evolved various forms of syntactic sugar that transformed its explicit error returns into something reminiscent of exceptions. Once every return is a Result, every call a ?, and every error a yeet, what's the difference between your…

Post by the_gipsy » Tue, Nov 26, 2024, 5:38 PM UTC

9rx wrote: post #339

the_gipsy wrote: post #279

Earlier quoted context omitted.

I forgot: The tenet "accept interfaces, return structs" is violated all over by returning the `error` interface. IMO it's okay to make behaviour-exceptions specifically for error handling. Rust for example doesn't really have builtin behaviour exceptions specifically for errors, they're generic to sumtypes and just happen to work well for errors. But then in practice you must resort to thiserror or anyhow helper crat…

> The tenet "accept interfaces, return structs" is violated all over by returning the `error` interface. To be fair, that expression came from a blogger who often wrote about Go. It is not a tenet held by the Go project. In fact, Rob Pike has made clear that he considers it to be misguided advice. It is only violated in the same way returning Result in Rust violates the assertion I made up for this comment: Do not re…

Post by the_gipsy » Tue, Nov 26, 2024, 5:49 PM UTC

packetlost wrote: post #338

the_gipsy wrote: post #29

Earlier quoted context omitted.

There are several shortcomings with go's error handling. The author heavily lies onto rust, so the alternative is not exceptions but a `Result ` sum type. No stacktraces and error wrapping forces you to not only invent unique error messages. You must also conceive a unique wrapping message at every call-site so that you can grep the error message and approximate a stacktrace. The weird "return tuple" , which obviousl…

Rust and Go's lack of stack traces are basically equivalent in that you need to call an additional function to add the stack context to the error result. For go you use fmt.Errorf, in Rust you use .context from anyhow (bad practice in many contexts IMO) or .inspect_err + log. It's rather unfortunate that neither has an easy way of capturing a line number + file easily and appending it to the context. Go could easily…

    b := g(f()?)?
    // var b B
    // {
    //     var a A
    //     var err error
    //     a, err = f()
    //     if err != nil {
    //         return *new(A), *new(B), err
    //     }
    //     var b B
    //     b, err = g(a)
    //     if err != nil {
    //         return *new(A), *new(B), err
    //     }
    //     // no accidental reuse of err
    // }