> Errors reach end users, and they cannot read stack traces.
In general, users don't care about errors or stack traces. They don't want errors of any kind. As a developer I want users reporting errors, which can include a dense stack trace, so I can get the error and an explanation of what they were doing when the error happened. I'm more for making my life easier than worrying about what a user sees.
I repeatedly fail to understand why golang proponents insist on flogging themselves into becoming human stacktrace authors. This is a solved problem the computer can do better than you, automatically, on your behalf.
Certainly any shortcut syntax should not prevent you from adding human-curated context to your errors. But the current situation comes at an enormous cost, and I truly think there's a bit of Stockholm Syndrome going on here.
It's not the same thing. In Java and Python programs, especially Java programs, developers seems to think it's perfectly reasonable to present the end user with a 100 entries stack trace. This may be of use to the developer to debug issues but it's not a substitute for good error messages that are to be presented to the end user.
I don't think Go errors are perfect either as you just tend to concatenate strings together but the information they include are more user friendly if done right, i.e. not just bubble up the error, but adding context that the user is aware of.
Languages that bubble errors up still let you catch and categorize the errors at the top, allowing for very presentable formats for the end user ... in fact, in my experience, because they don't have to deal with tiers of pointless boilerplate, devs put the effort instead into better end user/public errors.
I say this as an ex-(for now)-Python dev, currently suffering though Go's tedious error handling.
I agree that in theory the same is possible in languages that use exceptions but in my experience laziness often wins out. The exception is caught on the level where it's suitable to terminate the stack unwinding and deal with the error from the applications point of view. At that point it's too late to add user recognizable context to the error that what Go advocates by its design.
My opinion is that a syntax shortcut such as "?" to just bubble up errors without adding context would still be useful. I would welcome it. There are cases where I find that no additional context is needed. I think the Go designers are afraid what it would lead to though (the laziness wins out hypothesis)
Not that I agree with how Go handles it, but the computer is not always better at it. It's a tradeoff, a compromise, or a catch-22.
If you use the full stacktrace, you could get 50 frames of irrelevant library code worsening the signal:noise ratio, hiding what the real issue is.
If you write your own context, then when it _is_ a problem with library code, you're hopelessly lost.
I think we need better tooling: the ability to add your own contextual information, to propagate errors explicitly but without boilerplate, and the ability to _choose_ the level of information you see afterward.
We have log viewers that can filter out by severity level, why don't we have a standardization for stack traces to let you filter to what you want?
> I truly think there's a bit of Stockholm Syndrome going on here.
I agree in sense Stockholm Syndrome going on but not just for Go but with almost every technology including Go.
When we have folks defending Rust slow builds, Swift breaking changes, Half-assed tooling for Scala, poor power management on linux laptops and on and on. It could mean either plain old stockholm syndrome or that people can work around these minor irritants and get main benefit of technology. Just like with anything else in life.
Attributing this to stockholm syndrome is a bit convenient and reductionist.
Stacktraces are better than just bubbling up, and yes a mechanism to minimize if-err could also allow for human annotations.
I'd love if Go had a stronger type system, but I know it'd probably come with longer compile times like Rust has. I think it's not a dogmatic take, and I think a lot of golang proponent do take the same nuanced position.
But it doesn’t replicate the actual features people want from smart lights which is
1. Turn them off and on from my phone, or voice assistant thing.
2. Changing the color and brightness of the lights.
3. Doing 1 and 2 automatically.
Having lights change from white to yellow automatically based on the time is something I don’t want to give up now.
It’s the switch that’s the real issue. If your switch was a panel with an on and off button that controlled the smart lights and your lights were plugged into a normal outlet there would be no problem. Consumer tech is trying to retrofit in an environment that hasn’t caught up to commercial lighting systems.
This comment makes little sense. AWS is even less uniform when it comes to tools, exactly because of its organic growth. This clearly has no impact on its success nor its features.
Google does have a problem with management and the org-chart, but not the way you think.
AWS has significant first-mover advantage, but in chasing that advantage, Google sees providing a UI as a distinguishing feature to the AWS exeprience.
But their focus is on spanning the feature-set, not making the resulting UI fast. And the feature set is incredibly broad.
GCP's interface is worse because it clearly prioritizes form over function. When I click a button in the AWS control panel, generally it works. When I click a button in the GCP control panel, there's a non-trivial chance it will result in an infinite loading screen or an ambiguous error.
I see it all over Google's products (with the exception of search). Gmail loads 50mb of assets these days, and is extremely sluggish. It shows you the search bar but if you try to type in it too soon it'll skip characters and start to chop. It's embarrassing. And I'm on an i9 with a gigabit connection. Imagine how horrific it is to a user in the third world.
You have to implement UnmarshalJSON. Between each attempt to deserialize into a possible struct, be careful to return on errors that are not JSON serialisation errors (for example caused by reading from the underlying Reader, etc.)
It's ugly and verbose but there is no need to use empty interface.
Right, that's Plan9.