221–230 of 243 posts
I still don't see a benefit with this over custom error types. Having a huge switch statement to determine the HTTP response code seems really inefficient vs just doing errors.As and getting the response code directly.
It’s very useful when multiple errors happen concurrently, like collecting errors from separate goroutines after they all finish.
"What only matters is the unwrapping procedure and conversion to string because that is what is needed." This, in a nutshell, encapsulates what Go gets wrong about error handling. The simplicity is great; the extreme simplicity at the expense of runtime efficiency and clarity is not . Errors are not just strings . They can (and should) encode information, and the language should support that efficiently. And the mech…
This blog post is inaccurate. The only information an error is required to implement is their string representation. You can add whatever you want on top, there are no further restrictions.
Earlier quoted context omitted.
I feel a lot of that has to do with Googlers not daring to question the famous authors, and the same authors seem to have been asleep for the last three decades in terms of modern programming language developments. I geared up to learn Go one day, got the book and everything, and after just a few hours of trying to write and rewrite error-handling code, I was wondering how this ever got out of the Request for Proposa…
The answer to error handling is ADT like Result or Maybe . The problem with old exception is that it is not part of the function signature. If a function says it accept a key and return a value; why should I expect it to return NullPointerException?
What signature do you get from "if err := myFunction()"?
It's still just a generic error object, possibly a string. You still have to write a handler for it. Why do it every time?
I have a web application. There is a SQL query that produced no results for an object. I throw an ObjectNotFoundException. It results in an HTTP 404, producing a web page or a JSON response, depending on the request location, and I handle it all once.
Earlier quoted context omitted.
You may not like the language, but it's managed to grow with a consistent story. Yes, there have been some missteps, like auto_ptr and vector , but it does work together. At worst you have to write small adapters because there's no equivalent of smatch for string_view, etc... But compare this to Go, where contexts, error wrapping, generics, uh... error wrapping again (this multierror thing), horrible conditional buil…
I'm saying this after 20 years using C++, from AT&T CFront onwards, all the GotW, years of Boost posts, every Modern, Effective and Exceptional book read. I've loved C++, but now it is complex even with my experience.
I have more than 20 years of C++ experience. Maybe more than 25. I'm surprised you used CFront 20 years ago. Is this like how in my head the beginning of the Unix epoch was "about 30 years ago" when actually it's almost 53?
Earlier quoted context omitted.
It's also not true the interface for Unwrap() doesn't exist; behold https://cs.opensource.google/go/go/+/refs/tags/go1.19.4:src/... ... Yeah, it's not exported but...
In the blogpost I specifically wrote "There is no (named) interface in the standard library..." because I was aware of the function you point out. Rather than unexported interface, I would probably call that an "anonymous interface". Anyway, now that I read that, I should probably skip this fact and just keep the example interface. It is not uncommon practice in Go to make "copies" of interfaces to avoid extra depend…
> It is not uncommon practice in Go to make "copies" of interfaces to avoid extra dependency (or cyclic dependency).
I hadn't really noticed but my exposure to the source is spotty. See what they are doing there and can imagine why, it just irks me.
There are now implicit, "standard" shapes for Error that don't have named, exported interfaces and presumably anyone wanting to write code around both Unwrap shapes will need to reach for the same techniques to suss out what they are dealing with..
Earlier quoted context omitted.
> Of course, mnemonics 1-2-3-4-5-6-7 (1st month, 2nd day, 3rd hour, 4th minute, 5th second, 6-th year, 7th timezone) is harder to remember than mmHHMMssSSYYyy crap that is different in different languages. Very much so. The latter is at least portable between cultures, because a month is a month, unlike "1". And then of course you've got all the collisions like weekday (which for some reason does not follow the US st…
Very much so? Let's put it to the pragmatic challenge. What will be the output of Go's "Jan 2006" and of R's "%B %h %M" format strings? Don't google.
Earlier quoted context omitted.
> Years and years of discussions about Go's poor and verbose error handling ...with majority of users saying that it's actually great and simple, unlike "usual" approaches... > Many "features" of Go are borderline insane ...which start make sense as long as you use them and put some thought behind the reasons of the design, instead of sticking to "what I used to is the only right way" mentality... > (date formatting)…
> (1st month, 2nd day, 3rd hour, 4th minute, 5th second, 6-th year, 7th timezone) Who was the bright spark that decided they the month of all things should go in first? This format makes almost as much sense as Sunday being the first day of the week
Also funnily enough Go does not use the field 0 for DOW, instead it uses 1 (Monday).
Which makes no sense at any level, because it uses 2 for both month-day and year-day, but apparently week-day is not a day (and you can’t get the numerical week-day anyway, because who needs that).
Earlier quoted context omitted.
mnemonic is just a memory aid, it can be anything. if you prefer other term, feel free to use it, but the point still holds - it's a 1234567-based date that you remember once (most people can do it) and it helps remembering what should be in the format string.
What is 1234567 anyway? Why 1 is month? From which clue should I remember that?
But don’t rely too much on cultural assimilation, because DOW is not the Sunday / 0 you might then expect.
Earlier quoted context omitted.
Well, the proof is in the pudding, and the pudding has spoken and found Go wanting, compared to its most direct competitor, Rust. Even though Go appeared earlier than Rust, and Go's creators are much more famous than Rust's, and the corporation behind Go is much more influential than that behind Rust, adoption of Rust is skyrocketing for mission critical systems while (apart from the container ecosystem) Go is much l…
> compared to its most direct competitor, Rust. No, no, no and no. How on Earth people come to this conclusion? Go is closer to node.js than to Rust. Like, it is not even a competition they are so far apart. One is a “zero-cost abstraction, low-level language”, the other is a “managed language with a GC like million others, which is as badly expressive as C”. To mention some positive as well, virtual threads are cool…
1. Because they were first unveiled around the same time, as AOT natively-compiled languages with drastically different takes and directions.
2. Because when the authors of Go first released it, they called it a systems language. By which they meant, unlike anyone else, a language to write systems with. Like… programs.
3. Because when first unveiled, Rust was a very different language, much more similar to Go. It always had a much more functional and type-heavy bent, but it had a runtime and scheduler, userland threads, kinda-sorta a GC in potential (“GC’d pointers” though no GC was ever implemented for real). As noted in (1) it looked a bit on a completely different take on a similar niche. It was brought downstack over time as the community saw its potential as an “innovative” breath of fresh air for low-level uses: higher levels of the stack already had memory-safe and type-heavy programming languages if they wanted those.
Earlier quoted context omitted.
Very much so? Let's put it to the pragmatic challenge. What will be the output of Go's "Jan 2006" and of R's "%B %h %M" format strings? Don't google.
“Jan 2006” and short month, short month, minutes?
R example - it's "Long month, hour, decimal minute", so something like "December 15 35"
So you got Go format style right, and alphabet-style wrong. But Go's format is worse, right?