I really want to like Go, but I can't stand looking at Go code. The error handling is such a turn off.
Why would you say something so controversial yet so brave?
Go 1.27
101–110 of 277 posts
Re: Go 1.27
#102Wasn't Go supposed to be "simple"? I remember how Go advocates used to boast about not having generics and now it almost seems like Go is trying to become some sort of C# or Java Frankenstein. I'm not even trying to badmouth Golang - just legitimately confused.
Go genetics are still incredibly simple compared to languages with a rich type system.
Re: Go 1.27
#103Earlier quoted context omitted.
Ah. This is a bold faced lie. There were plenty of options in 2016. Nist released final candidates in 2024 and published the candidates this year. ssh (as noted in tfa) has had pq defaults since 2022.
In case you wanted to know, the expression is actually "bald-faced lie", i.e. unmasked, shameless.
"bold-faced lie" and "bald-faced lie" are both valid expressions. The original expression is "bare-faced lie" but they're all pretty similar to each other.
Re: Go 1.27
#104I really want to like Go, but I can't stand looking at Go code. The error handling is such a turn off.
Not that I like go at all but because of it my C++ is starting to look like it as I am returning tuples of [result, error].
I try to avoid exceptions, is there any better ways? (Variant looks a bit more complicated but could be a totally OK alternative)
Re: Go 1.27
#105I really want to like Go, but I can't stand looking at Go code. The error handling is such a turn off.
Personally I feel go has many issues and is ugly as hell but the error handling is really the least of my worries.
Re: Go 1.27
#106Earlier quoted context omitted.
In case you wanted to know, the expression is actually "bald-faced lie", i.e. unmasked, shameless.
"bold-faced lie" and "bald-faced lie" are both valid expressions. The original expression is "bare-faced lie" but they're all pretty similar to each other.
bold-faced lie is just the usual English drift that was actually questioned as incorrect when it first surfaced. If a lie is bold, you don't have to suggest that the user's face is bold when doing it. You can in thirty seconds of google searching find numerous sources explaining that "bold-faced" is a malapropism.
Re: Go 1.27
#107Earlier quoted context omitted.
Neat, stealing this.
I wrote a blog on it if you're interested: https://xeoncross.com/2026/better_go_handlers.html
Thanks for the link, looks like a very pleasant framework to use! I was interested to see "Mid-fasthttp" on the slower end in the benchmarks at the bottom, do you know why that is?
Btw, the Gin and Echo examples reference an "input" variable but it doesn't seem to be defined there? Maybe it was intentional, since the examples are just to give a general idea of how the handler looks in each library, but thought I would let you know just in case it wasn't.
Re: Go 1.27
#108Earlier quoted context omitted.
"bold-faced lie" and "bald-faced lie" are both valid expressions. The original expression is "bare-faced lie" but they're all pretty similar to each other.
bold-faced lie is just the usual English drift that was actually questioned as incorrect when it first surfaced. If a lie is bold, you don't have to suggest that the user's face is bold when doing it. You can in thirty seconds of google searching find numerous sources explaining that "bold-faced" is a malapropism.
It's the usual English drift perhaps, but "bold faced lie" has been used since the 17th century, which is also apparent from "thirty seconds of Google searching". Three hundred years is enough usage for me to count it as correct.
On a side note, "bold faced" does not mean the persons face is bold, only that it is said boldly, which implies a level of rudeness that "bald-faced" or "bare-faced" does not.
Re: Go 1.27
#109Generic methods are a huge win for the language. I've been waiting on these kinds of improvements to the type system before resuming work on my database toolkit.
Re: Go 1.27
#110I really want to like Go, but I can't stand looking at Go code. The error handling is such a turn off.
Not that I like go at all but because of it my C++ is starting to look like it as I am returning tuples of [result, error]. I try to avoid exceptions, is there any better ways? (Variant looks a bit more complicated but could be a totally OK alternative)
C++23 introduces std::expected, which is a simpler alternative to std::variant designed specifically for the result-or-error use case. You still don't get pattern matching, but Go-style tuples don't give you that either.