Go is a terrible language (2020)
debugged.it
debugged.it
I hope some day null is no longer a thing, and that Functional Programming types like Option, Either, Try etc in the native libraries is the new default. (BTW, there's really nothing "Functional Programming" about them, they're just objects like any other in "Object Oriented" languages)
The guidance I remember when I was trying out go and researching idiomatic Go style was not “don’t use panic in your code” but “don’t expose panics [other than the ‘always and everytime fatal’ kind] across the public API surface of your code”.
Basically, if someone other than the code owner would want to react to it, it should be converted to an error return before hitting the code consuming your library.
> If error isn’t typed it’s no different from “anything can throw anything anywhere in the stack”.
Errors aren't untyped. It's an interface type. Not everything returns errors anyway, they definitely can't be returned from anywhere in the stack.
Errors in Go are definitely nowhere near as amorphous as those in JS. In JS, you can take an Error object and stick additional properties on it, and then throw that. In fact, Node does that, and by extension, thousands of JS libraries generate exceptions like that.
With Go, you use errors.As(), or errors.Is(), or a little bit of dynamic casting. The type of error which a function returns may not be part of its type signature, but decent libraries usually have only one or two error types they return. Yes, I hit F12 to see the library's source to see what errors it returns... but that's just because the IDE experience with Go is so fast and nice to use.
throw 'wat'
And by not typed, I specifically meant in the function signature. If tooling helps with that, that’s awesome.
Sure, Go allows you to create an error with nothing but a string message inside. The equivalent JS is something like
throw Error('wat');
> Which doesn’t seem like a very useful interface to me. Everything can be stringly typed. But again I’m looking at this from the outside.
What’s happening here is that your function is returning an error, but in such a way that you can’t identify that specific error from its value. If you’re a library author, you use this in two scenarios:
1. You can’t imagine a way that this specific error could be handled by the caller. (It doesn’t need a special type, because nobody will be checking for it.)
2. You expect all errors from your function to be handled the same way. (It doesn't need a special type, because you already know what to do with it.)
The way you handle errors in Go is actually quite rich, seems like it just doesn’t jive with the author’s personal preferences. Or possibly the author is using terrible libraries. Or possibly the author really hates boilerplate code (the author's complaining about “tons” of boilerplate code, but it doesn’t look like much boilerplate code to me).
If anything, my experience handling Go errors is that you might end up with rather complex error objects, with errors nested inside of other errors, multiple levels deep. You can extract a ton of information from these objects—like if there’s an I/O error, you’ll know what operation failed and the path of the file, and then inside you’ll find the wrapped I/O error without that information.
We've gone down this route with Java and my conclusion is that declaring the kind of errors a function returns is, for most users, just a pain.
https://www.artima.com/articles/the-trouble-with-checked-exc...
My experience with Go is that decent libraries only have a small number of error return types, and then forward or wrap errors from libraries that they use. You can use errors.Is(), errors.As(), errors.Unwrap() to figure things out as necessary.
Just like putting on a seat belt is a pain.
Both are pains that are worth having because they help you create robust software.
The ways in which a function can fail should absolutely be part of its signature, and if these are recoverable, the compiler should refuse to build until you either handle these errors or pass them on to the caller.
The problem with that is that a downstream library gets welded to the specific errors it can throw and can't evolve.
So, what everybody will do is generate the most generic "Error" possible so that the signature never needs to change. That is NOT an improvement.
func canThrowErrors() throws -> String
func cannotThrowErrors() -> StringAnyone supporting such flagging behavior is completely against the spirit of what made this place great. Please reconsider your actions and what flagging does on HN.
"There are certainly many reasons to hate Go, from the unusual syntax to the half-arsed way they decided to implement the programming model. On the other hand you can go all fanboy over how cool Go is because it makes it so simple to write microservices. (No, it doesn’t. It really, really doesn’t if you want to do it properly.)
If you jumped on either of these bandwagons, I would recommend getting off as soon as possible. Neither of these approaches are very professional and are telling signs of inexperience in software development."
There is an upsetting level of hypocrisy in patronizing your readers for consuming the clickbait-titled articles _you authored_.
Most applications I tend to see don’t even use concurrency because they are so small and simple that they don’t need it.
They don’t need to. Static analysis (guru) can answer the question “what kinds of error can this error be?” There’s no need to go source diving as the author suggests.
Not having all that in the core language can be a reasonable design choice.
Not having it in the core language can be a reasonable choice, but you still need to do community work to ensure that those needs are met somehow
Also I’m guessing the section on immutability isn’t referencing something special in Java, dunno.
# Like this
y = mx + b
Boilerplate, no exceptions, slices, ... all felt terrible.
And then I started to appreciate the typing and the fact that I had to give some thought about where to actually handle errors.
I know kinda like Go, except for the weird way maps are handled, and the lack of types in errors (compared to Python where it is fantastic).
There are certainly pros and cons (I am not a good enough developer to have advanced thoughts on that) but the cross compilation makes a lot of things easier when deploying self-contained executables.
(I actually quite like Go, despite it being more difficult to write tests for than other languages, and error messages usually being very cryptic.)
https://golang.org/doc/faq#exceptions https://go.dev/blog/errors-are-values
If someone could write a "coffeescript" for it, perhaps a python+pascal love-child, while keeping the fantastic lower-level parts of go, I'd be all over it.
It is kind of boilerplatey, but I find myself stopping to consider how best to manage an error vs languages with exceptions.
https://learning-rust.github.io/docs/e6.combinators.html
https://learning-rust.github.io/docs/e5.error_and_none_propa...
Edit: I left out "engaged in" previously.
for _, a := range albums {
if a.ID == id {
c.IndentedJSON(http.StatusOK, a)
return
}
}
for a in albums:
if a.ID == id:
// the rest of the code
albums = append(albums, newAlbum)
albums.append(newAlbum)
Edit 2 : Fixed the formatting issue.
albums = append(albums, newAlbum)
Except that implication is incorrect -- slices are mutable.
What kind of formatting can you use in comments?
http://news.ycombinator.com/formatdoc
Text after a blank line that is indented by two or more spaces is reproduced verbatim. (This is intended for code.)
Saddest part is that it’s actually pretty good language at getting things done, you just have to hold your nose and pretend it was invented in early 1980s, before the industry figured out good, clean solutions to many problems, and converged on them. Otherwise, to think that someone thought nil (that is, not empty) arrays, or returning value/error as pair instead of tagged result union, or lack of generics, is a good idea on 2000s, is just unconscionable.
It makes PR review job so much easier, and to me, that's beautiful.
This is Go's biggest anti-feature to me. I can't stand that all code in Go is so similar.
Have you debugged.it ?
While I had over a decade of experience in other languages, such as Python, PHP, Java, etc.
I found it extremely difficult to wrap my head around Go.
Maybe it's not Go that is a terrible language but just that the author is not a systems programmer who has worked with large code bases ?
Is there any reason you believe python and java are 'very problematic"? Isnt every language promlematic in its own way? Are they more problematic than C, which breeds foodguns, or what are we comparing to?
1. Take the line number where the error was logged, likely somewhere very close to e.g. the main event handling loop, and completely disconnected from the place where the error was initially thrown. There is no stack trace.
2. Try to figure out which parts of the error string are constant (i.e. searchable), and pray for the developer to have been familiar with the issue so that the string is globally unique (corollary: When writing Go, make sure your error strings are unique, introduce some form of variation if you're throwing similar errors, even if it's just punctuation or synonyms, to make sure the throw site is identifiable).
3. Try to guess what the flow between those two sites could have been.
The lack of proper stack traces (or even the line number where the error was thrown) on errors is one of the most insane effects of this error handling approach. (The other is hard to read code because the actual logic is hidden in 3x as much error handling boilerplate).
Author’s tone could be better but they’re just being straightforward that they don’t like Go and specifically why. Totally ok in my view.