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

Just Use Go

blainsmith.com

Post reply on HN
Print view View original

171–180 of 238 posts

Re: Just Use Go

#171

Post by potato-peeler »

dualvariable wrote: post #136

> if err != nil is the feature, not the bug. It forces you to look at every place something can go wrong and decide what to do about it. No it really doesn't. It litters your code with if statements that are all just about the same, except that one that needs to be different, and you go blind looking at them all and can't spot the difference. And these days people probably just type "tab" and their LLM assistant fill…

> No it really doesn't. It litters your code with if statements that are all just about the same

Wrong thing to be bothered with. This allows static analysis of every possible path the code can take. Try to do that with throw/catch. There is a reason many industry guidelines like misra, jsf, etc just outright ban hidden paths. They have been literally catastrophic. There is a reason why many modern languages like go, rust, etc, want errors to be explicitly handled.

Go documentation specifically reasons why they treat errors-as-values and why is it like that - https://go.dev/doc/faq#exceptions

> Rust converts the common case boilerplate down into one character: ? which lets you focus on any exceptional error handling rather than a wall of if statements that almost all look alike

Again, wrong way to look at errors. Errors are not a problem for a compiler to resolve. Errors are part of your business logic. They need to be explicit and handled. The syntax of one language vs another is not the point of error handling. Errors are not a distraction. It is your job to review each path the code can take.

Code may be written once, but code is always reviewed or audited or referenced more than once. No one is impressed if you write some meta magic one-liner. I would rather be more impressed if I can read your code and form a mental image on how many paths your code takes to achieve an outcome in a single sitting, instead of pinging you for a quick call to explain yourself.

> you go blind looking at them all and can't spot the difference

> And these days people probably just type "tab" and their LLM assistant fills out the entire block incorrectly in one keypress copying the pattern from everything else

Now, if someone is 'going blind' looking at error checks, its because their function is doing too much and has too many failure points. Perhaps one may need to focus on honing their software engineering skills on how to structure their code, instead of hitting that 'tab' more so often.

Re: Just Use Go

#172

Post by jesseschalken »

potato-peeler wrote: post #171
dualvariable wrote: post #136

> if err != nil is the feature, not the bug. It forces you to look at every place something can go wrong and decide what to do about it. No it really doesn't. It litters your code with if statements that are all just about the same, except that one that needs to be different, and you go blind looking at them all and can't spot the difference. And these days people probably just type "tab" and their LLM assistant fill…

> No it really doesn't. It litters your code with if statements that are all just about the same Wrong thing to be bothered with. This allows static analysis of every possible path the code can take. Try to do that with throw/catch. There is a reason many industry guidelines like misra, jsf, etc just outright ban hidden paths. They have been literally catastrophic. There is a reason why many modern languages like go,…

Go has plenty of hidden code paths in defer, panic and recover. You can minimise the use of those things, just like in other languages you can minimise use of try-catch in favour of a Result sum type, which is already better than Go's "multiple return that you have to pretend is a sum".

Re: Just Use Go

#173

Post by jesseschalken »

The single executable deployment hasn't been an advantage for a very long time. C# has Native AOT. Java/Kotlin/Scala have GraalVM native-image, plus Kotlin Native and Scala Native.

And of course there is Rust, which compared to Go has better performance, lower memory usage, smaller binaries, safe concurrency, safe resource handling, and a real type system with tagged unions.

The Go team built good tooling around a mediocre language. Now most other languages have caught up, and Gophers are left writing mind numbing `if err != nil` checks with no benefits left to show for it.

Re: Just Use Go

#174

Post by potato-peeler »

jesseschalken wrote: post #172
potato-peeler wrote: post #171

Earlier quoted context omitted.

> No it really doesn't. It litters your code with if statements that are all just about the same Wrong thing to be bothered with. This allows static analysis of every possible path the code can take. Try to do that with throw/catch. There is a reason many industry guidelines like misra, jsf, etc just outright ban hidden paths. They have been literally catastrophic. There is a reason why many modern languages like go,…

Go has plenty of hidden code paths in defer, panic and recover. You can minimise the use of those things, just like in other languages you can minimise use of try-catch in favour of a Result sum type, which is already better than Go's "multiple return that you have to pretend is a sum".

Which is what should be discussed about go, rather than if-err clauses. That is hardly an issue in go. But Go has these little quirks which, if not careful, can become a problem. But instead most go critiques discuss only the error handling syntax. Look at the other comments.

The article is on point on the strengths of go, and in many cases, those other languages you say, you will find it really hard to do the same thing with the ease with which you can do in go.

What the article glosses over, is the footguns with working with the language. No compile time nil checks, implicit interfaces, lack of sum types, like you said, which more so often leads to bloated structs, member visibility which is just private and public. You can find more.

But these problems were not the main focus of go. Go was build because google devs wanted a simpler way to manage and deploy their software across thousands of services, not having to wait forever for their code to compile, not worrying about writing cpp code in the BEST possible industry standard, ability to do parallel processing of hundreds or thousands of workloads without choking your cpu, managing dependency hell. These were actual roadblocks. And google was not the only one facing these problems. Go solved all of it. Which language was solving this before go?

Re: Just Use Go

#175

Post by Ukv »

4ndrewl wrote: post #165
Ukv wrote: post #115

Earlier quoted context omitted.

Silently ignoring errors by leaving out some boilerplate doesn't really seem like an active/forced decision, or a selling point over the languages it disparages ("[...] hellscape doesn't make errors disappear, it just hides them"). Then that the correct path is the one of more resistance seems poor design, in my surface-level opinion.

It is a decision though, and one you have to consciously make for each and every occurrence. You can't just hope some catch block will eventually handle it...

I may be missing something, but I don't see how just forgetting to handle/propagate the error (and, say, causing data corruption by continuing with whatever empty/partial return value the function happens to give) would be a conscious decision.

Even when it is intentional, like writing some quick/dirty code and planning on handling errors properly later, I'd imagine it's difficult to grep for instances of unchecked errors in the way you can with `.unwrap()` - though tooling should help.

Re: Just Use Go

#176

Post by nick_ »

therealdrag0 wrote: post #159
nick_ wrote: post #128

Earlier quoted context omitted.

The convention of explicit error handling after every method call is absolutely bonkers to me. I would never use it for anything serious.

I recently vibe coded a large app in Go, it’s so mind-numbing to read. Like half the code base is error handling.

The anti-exception mind virus of the 2010s did a lot of damage. Go designers finally caved and added panic & recover, but jeez, the damage was done. The whole ecosystem has exception derangement syndrome.

Re: Just Use Go

#177

Post by kakwa_ »

After having way too strong opinions about this, and even if Go is my go to language, I've stopped caring for this kind of statements.

In the end, the language doesn't really matter and extremely rarely is the bottleneck.

Python, Java, Go, C#, PHP, Node, Ruby or Scala, for backend stuff, all these languages can do the work 99% of the time. They all have well developed ecosystems, and are sufficiently mainstream to easily find developers.

In the end, these languages are just variants of the same tool, and I find more interesting to just pick one and build something with it, rather than bickering endlessly about which one is better.

Re: Just Use Go

#178

Post by pjmlp »

potato-peeler wrote: post #174
jesseschalken wrote: post #172

Earlier quoted context omitted.

Go has plenty of hidden code paths in defer, panic and recover. You can minimise the use of those things, just like in other languages you can minimise use of try-catch in favour of a Result sum type, which is already better than Go's "multiple return that you have to pretend is a sum".

Which is what should be discussed about go, rather than if-err clauses. That is hardly an issue in go. But Go has these little quirks which, if not careful, can become a problem. But instead most go critiques discuss only the error handling syntax. Look at the other comments. The article is on point on the strengths of go, and in many cases, those other languages you say, you will find it really hard to do the same t…

Go was developed because two UNIX guys, and one Oberon guy, that didn't like C++ decided to create their own thing, and their manager decided to support them as their 20% project.

Nothing else.

The narrative of Google wanting Go never happened, it gets sold as such by many Googlers.

Even Kubernetes was originally written in Java, before some Go folks joined in and drove the rewrite into Go, which besides the Android build system are the only two key projects using Go.

Re: Just Use Go

#179

Post by pjmlp »

gib444 wrote: post #147
twic wrote: post #6

> The boring choice is the right choice. It always was. Right, absolutely correct, Java is a great choice, so why does this post keep going on about Go?

Well, Spring (Boot) is so hard to avoid running into at day jobs. And Spring is hell.

[flagged]

Re: Just Use Go

#180

Post by pjmlp »

barnabee wrote: post #62

Now that LLMs can breeze through the Rust boilerplate there's no reason to ever write Go again. It's one of the dullest, most mediocre languages out there and despite a nice toolchain and the fact it's undoubtedly a "safe" choice, I just have zero interest.

I bet if Rust was more mature back then, the Python to Go rewrite from Docker, and the Java to Go rewrite from Kubernetes would both have been into Rust instead, and that would be it.
Post reply on HN