3 ms·

It probably doesn't work to convince you, still I see that differently ;) About generics, it depends on the problem at hand. When writing a generic Matrix mult

It probably doesn't work to convince you, still I see that differently ;) About generics, it depends on the problem at hand. When writing a generic Matrix multiplication type that for instance should work both on real and complex numbers (or more obscure types) generics are a thing. On the other hand, when working for instance with golang.org/x/net/html, I really appreciate the interface definitions and the possibility to do type switches on those. The error handling problem can also be dealt with. I also prefer to not shadow variables, IMHO the ideal function has all its variables defined already in the signature. I mean there are stack traces when a panic is called, or something that wraps it like a log.Fatalf. I guess the idea is the author is giving much more thought to how errors are dealt with and how they are printed in a both useful (=greppable) and beautiful way. As an end user that doesn't want to dive into the code I probably always prefer to see a nicely formatted error message (or even a gracefully handled error) instead of a 100 line stack trace. Probably Go is not just the language spec but also how to use it. Therefore saying "Learning Go in 5 minutes" is probably a bit far-fetched ;-) (Probably for any language that would be true...)

BoorishBears 6y ago
I'm aware of stack traces on panics, but my understanding is you only get them if you let them bubble up and kill the application (so not really a "first class" option for errors in places like web handlers) Has that changed, or did I misunderstand? But I also think the stack trace message example is the perfect example of what I mean by "take the Go mentality with you" In a language like Kotlin for example, Go got my in the habit of attaching more information to exceptions as they bubble up. I was already generally in the habit of wrapping library exceptions, but I started religiously using a Result nomad implementation and wrapping errors with additional information so that my stack traces looked very "Go-like" in terms of human readability, but kept traditional stack trace information. It's small things that I think using Go makes you "re-appreciate" in other languages
- hcles 6y ago
  You can get the full stack of the crash point (and a few extra frames that handles the stack generation) in a deferred recover, ie https://play.golang.org/p/XvZteY6Y6fh https://play.golang.org/p/XvZteY6Y6fh github.com/pkg/errors is a simple way to dump expensive stacktraces into each new/wrapped error. Or you can just panic and recover in your own app, it's possible though discouraged.

BoorishBears 6y ago

I'm aware of stack traces on panics, but my understanding is you only get them if you let them bubble up and kill the application (so not really a "first class" option for errors in places like web handlers) Has that changed, or did I misunderstand? But I also think the stack trace message example is the perfect example of what I mean by "take the Go mentality with you" In a language like Kotlin for example, Go got my in the habit of attaching more information to exceptions as they bubble up. I was already generally in the habit of wrapping library exceptions, but I started religiously using a Result nomad implementation and wrapping errors with additional information so that my stack traces looked very "Go-like" in terms of human readability, but kept traditional stack trace information. It's small things that I think using Go makes you "re-appreciate" in other languages

hcles 6y ago
You can get the full stack of the crash point (and a few extra frames that handles the stack generation) in a deferred recover, ie https://play.golang.org/p/XvZteY6Y6fh https://play.golang.org/p/XvZteY6Y6fh github.com/pkg/errors is a simple way to dump expensive stacktraces into each new/wrapped error. Or you can just panic and recover in your own app, it's possible though discouraged.