Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lies we tell ourselves to keep using Golang (2022)

fasterthanli.me

Post reply on HN
Print view View original

301–310 of 526 posts

Re: Lies we tell ourselves to keep using Golang (2022)

#301

Post by Yoric »

usrnm wrote: post #30
XorNot wrote: post #8

Earlier quoted context omitted.

When I started trying to teach myself Rust, the error handling story fell apart on me very quick. Like as soon as I wanted to try and get sensible reporting in their, suddenly we were relieving libraries, adding shims and fighting mismatched types and every article was saying the same thing: haha yeah it's kind of a problem. I'm very, very unsold on explicit error handling compared to exceptions for practical program…

The problems you're describing don't exist in go. There is exactly one standard type that is used by everyone, at least in public API's, you can always just return the error to the caller, if you don't want to handle it in place. The main difference with exceptions in my practice is the fact that it's a lot easier to mess up, since it requires manual typing. This is probably my main problem with everything being as e…

The drawback, on the other hand, is that all the Go code I've read (including the stdlib and all the dependencies of my current project) is using `fmt.Errorf` or `errors.New`, which means that you can't use `errors.As`, which means that you generally cannot handle errors at all.

Re: Lies we tell ourselves to keep using Golang (2022)

#302

Post by acdha »

pansa2 wrote: post #227
devjab wrote: post #5

This article makes a lot of great points about the shortcomings of Go. I don’t think explicit error handling is one of them however. I’ve previously spoken about my loathing of exception handling because it adds a “magic” layer to things which is way too easy to mess up. From a technical standpoint that isn’t necessarily a good argument, but from a pragmatic standpoint and decades of experience… well I will take expl…

> Go is seeing adoption that no other “new” language has exactly because of its simplicity Yes - for me, the simplicity is essential. As a part-time programmer, I don't have months to spend learning C++ or Rust. If my project needs to compile to small(-ish) standalone binaries for multiple platforms (ruling out Python, Ruby, Java, C#, etc) what simple alternative language is there? Plain C?

Basic Rust doesn’t take months to learn, especially when you’re not trying to do things like distributing crates to other people. I found the compiler to be enough more helpful than Go’s to make them roughly time-equivalent for the subset of common features, especially for a simple CLI tool.

Re: Lies we tell ourselves to keep using Golang (2022)

#303

Post by gregwebs »

afiodorov wrote: post #14

Not sure why Go is compared to Rust all the time, whilst most appropriate comparison is Java.

The Go language was actually created while waiting for C++ to compile. Their goal was to create something that was better than C++ for network services and they succeeded- but that's a pretty low bar! Most companies that don't have major performance concerns don't use C++ for networked services. If Rust was already mature it would have been a good option- except for the compile times which was one of their main original issues could well be worse in a Rust code base! I have seen this myself- Go being used instead of Rust with the biggest reason being it compiles so much more quickly.

Re: Lies we tell ourselves to keep using Golang (2022)

#304

Post by Seb-C »

the_gipsy wrote: post #279
the_gipsy wrote: post #29

Earlier quoted context omitted.

There are several shortcomings with go's error handling. The author heavily lies onto rust, so the alternative is not exceptions but a `Result ` sum type. No stacktraces and error wrapping forces you to not only invent unique error messages. You must also conceive a unique wrapping message at every call-site so that you can grep the error message and approximate a stacktrace. The weird "return tuple" , which obviousl…

I forgot: The tenet "accept interfaces, return structs" is violated all over by returning the `error` interface. IMO it's okay to make behaviour-exceptions specifically for error handling. Rust for example doesn't really have builtin behaviour exceptions specifically for errors, they're generic to sumtypes and just happen to work well for errors. But then in practice you must resort to thiserror or anyhow helper crat…

"Do what I say, not what I do" is almost a design guideline of Go at this point, there are so many inconsistencies like this in the language design.

Re: Lies we tell ourselves to keep using Golang (2022)

#305

Post by bob1029 »

mike_hearn wrote: post #268
abtinf wrote: post #25

Earlier quoted context omitted.

Having programmed for over 30 years, including nearly a decade of C#, I would say exceptions are one of the worst ideas in all of programming. They are just horrific gotos that any library can invoke against your code. They are pretty much never, ever handled correctly. And nearly always, after an exception is “handled”, the application is actually in an unknown state and cannot be reasoned about. Even junior enginee…

Well, I've also programmed for over thirty years and I wouldn't use a language without exceptions and even wrote a whole essay defending that position: https://blog.plan99.net/what-s-wrong-with-exceptions-nothing... > Even junior engineers have a trivial time debugging most go errors Not my experience at all. I had to do this once. An HTTP request to a production server was yielding a 400 Bad Request with no useful i…

> Diagnosing errors given stack traces is very easy.

This is the most important aspect of exceptions in my view.

The line that threw the exception isn't even the part of a stack trace that I find most interesting. The part that is most valuable to me when working on complex production systems are all of the call sites leading up to that point.

I remember in my junior years I wasn't a big fan of exceptions. A stack trace would make my eyes glaze over. I would try/catch at really deep levels of abstraction and try to suppress errors too early. It took me a solid ~5 years before I was like "yes, exceptions are good and here's why". I think a lot of this boils down to experience and suffering the consequences of bad design enough times.

Re: Lies we tell ourselves to keep using Golang (2022)

#306

Post by RMPR »

elcritch wrote: post #58

> I've started caring about semantics a lot more than syntax, which is why I also haven't looked at Zig, Nim, Odin, etc: I am no longer interested in "a better C". Well the post rambles a fair bit, IMHO. The whole bit about Go being “accidental” is BS given that Rust is just as much “accidental” in its origin and design. One thing stuck out to me is that Nim certainly isn’t a “better C”. It has a GC or you can use re…

> I’d argue (much) fewer software projects have been shipped in Rust. Firefox is still 95%+ C++.

It's funny but this comment reminded me of this tweet[0] from 2022 (!). I don't have a horse in this race as I am happily using Python and C++ at $DAYJOB. I'd argue that even if much less software has been written in Rust (source?), it still qualifies as "lots of software has been written and shipped" with it. Not to mention all the investments by $BIGCORPS in the language.

0: https://x.com/m_ou_se/status/1599173341117435905

Re: Lies we tell ourselves to keep using Golang (2022)

#307

Post by Seb-C »

abtinf wrote: post #25
devjab wrote: post #5

This article makes a lot of great points about the shortcomings of Go. I don’t think explicit error handling is one of them however. I’ve previously spoken about my loathing of exception handling because it adds a “magic” layer to things which is way too easy to mess up. From a technical standpoint that isn’t necessarily a good argument, but from a pragmatic standpoint and decades of experience… well I will take expl…

Having programmed for over 30 years, including nearly a decade of C#, I would say exceptions are one of the worst ideas in all of programming. They are just horrific gotos that any library can invoke against your code. They are pretty much never, ever handled correctly. And nearly always, after an exception is “handled”, the application is actually in an unknown state and cannot be reasoned about. Even junior enginee…

I agree about implicit exceptions, but I think that there is a sweet spot with explicit exceptions like Swift (and maybe Java): where you cannot not-handle one, it is part of a function's signature, and the syntax is still compact enough that it does not hurt readability.

Re: Lies we tell ourselves to keep using Golang (2022)

#308

Post by quotemstr »

chrismorgan wrote: post #262
quotemstr wrote: post #105

Earlier quoted context omitted.

Rust's error handling evolution is hilarious. In the beginning, the language designers threw out exceptions --- mostly, I think, because Go was fashionable at the time. Then, slowly, Rust evolved various forms of syntactic sugar that transformed its explicit error returns into something reminiscent of exceptions. Once every return is a Result, every call a ?, and every error a yeet, what's the difference between your…

One practical benefit of Rust’s approach that hasn’t been emphasised enough yet is the consequences of Option and Result being just values, same as anything else. It means you can use things like result.map_err(|e| …) to transform an error from one type to another. (Though if there’s a suitable From conversion, and you’re going to return it, you can just write ?.) It means you can use option.ok_or(error) or option.ok…

Exceptions are values in C++, Java, and Python too. They're just values you throw. You can program these values.

As usual, I find that opposition to exceptions is rooted in a misunderstanding of what exceptions really are

Re: Lies we tell ourselves to keep using Golang (2022)

#309

Post by neonsunset »

mathw wrote: post #245
quotemstr wrote: post #128

Earlier quoted context omitted.

Checked exceptions are more trouble than they're worth. That doesn't make exceptions in general bad.

Not having checked exceptions is a huge problem, because then you never know when something might throw and what it might through, and in the .NET world the documentation on that is pretty awful and absolutely incomplete. But then over in Java world, your checked exception paradise (which it of course isn't because the syntax and toolkit for managing the things is so clunky) is easily broken by the number of unchecke…

> in the .NET world the documentation on that is pretty awful and absolutely incomplete.

Depends on the area you look at. Language documentation is pretty good and so is documentation for the standard library itself. Documentation for the frameworks can be hit or miss. EF Core is pretty well documented and it’s easy to find what to look for usually. GUI frameworks are more of a learning curve however.

FWIW many in Java community consider checked exceptions to be a mistake. While I don’t find writing code that has many failure modes particularly fun with exception handling - Rust perfected the solution to this (and the Go way is visually abrasive, no thanks), I don’t think it’s particularly egregious either - Try pattern is pretty popular and idiomatic to use or implement, and business code often uses its own Result abstractions - switch expressions are pretty good at handling these. Personally, I’d write such code in F# instead which is a recent discovery I can’t believe so few know how good it is.

Re: Lies we tell ourselves to keep using Golang (2022)

#310

Post by voidUpdate »

voidUpdate wrote: post #4

I really wanted to like go, and I tried to write a discord bot using it, but the very opinionated brace style (which isn't the one I prefer to use), and the fact that I struggled to much to try and split my code across two files kinda turned me off it. In the end I just went back to python

Genuinely curious, why am I being downvoted? Did I say something wrong?
Post reply on HN