Hacker News Reader

Comment by Zagill | Hacker News Reader

This is pretty trivial to accomplish with linters. Where I work your build will fail if you have unchecked err's hanging around, along with a lot of other sorts of issues. No, it's not built into the language by default or anything, but is that dealbreaking?

View on HN

It is dealbreaking. These days I gravitate more and more towards strongly statically typed languages over weakly dynamically typed ones, which I definitely used to use when younger. Fact is, linters are simply not the same as something built-in from the ground up. Trust me, I have written many thousands of lines of Python and Ruby, and even with linters, they don't hold a candle to even something like TypeScript in terms of type ergonomics and refactorability, not to mention even stronger languages like Haskell or OCaml.

Anecdotally this is the same argument many C++ devs make in regards to Rust safety guarantees. The difference is just...different.

In general I agree with you, but Go's simple syntax means that there are extremely few (if any? I've never run into one) edge cases with checking that an error was at least considered. The guarantees are the same as what you get with e.g. Rust. The only difference is that you have to run a third party's code, which I don't like, either.

> The guarantees are the same as what you get with e.g. Rust.

I'm not sure how they could be, given that Rust checks exhaustively and Go doesn't. If one programmer messes up, then that's it, an unhandled exception might occur in the future. I would rather rely on the computer telling me when it should be handled over humans.

And the worst human to tell you that is an SRE

Well for one, Go is not a weakly, dynamically typed language, and this also isn't an issue of type checking at all.

Sure, I did not mean Go specifically when I said that, just stating how when I used linters in other such languages, it was not comprehensive enough to replace a language with types and other niceties built-in.

I also don't use much Go because it lacks good algebraic data type support, honestly can't imagine going back to a language that doesn't have them as I like to define all my business logic in types and then build the actual application from there. Go simply doesn't have that capability.

I'm not familiar with algebraic data types, what's missing from Go that makes that impossible? Sounds about like defining structs/other custom types before writing any method bodies, which is what I'd typically do in a Go project.

> what's missing from Go that makes that impossible?

The language maintainers don't want to add it: https://github.com/golang/go/issues/19412

Reply on news.ycombinator.com