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

81–90 of 526 posts

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

#81

Post by slau »

liotier wrote: post #59
troupo wrote: post #12

Earlier quoted context omitted.

It's actually very rare that it should be the caller who has to handle the errors. Go, however, forces you to spread your error handling over a thousand little pieces with zero overview or control of what's happening. Rust eventually realised this and introduced try! and ? to simplify this

Unsure if this is the right place to ask, but this conversation inspires me this question: Is there in practice a significant difference between try/catch and Go's "if err" ? Both seem to achieve the same purpose, though try/catch can cover a whole bunch of logic rather than a single function. Is that the only difference ?

Try/catch can bubble through multiple layers. You can decide/design where to handle the errors. If you don't `if err` in Golang, the error is skipped/forgotten, with no way to catch it higher up.

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

#82

Post by masklinn »

DanielHB wrote: post #62
stouset wrote: post #45

Earlier quoted context omitted.

Without fail, every single person I’ve seen rave about go’s error handling compares it only to exceptions as if that’s the only alternative. On the flip side I have yet to find a person who’s familiar with sum types (e.g., Maybe, Option, Result) that finds the golang approach even remotely acceptable.

You hit the main gripe I have with Go, its types system is so basic. I get people raving type-correctness of Go when they come from Python but the type system in Go is simply pre-historic by modern day standards.

Go’s type system is not even impressive compared to python’s.

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

#83

Post by wokwokwok »

jchw wrote: post #22

Every time I read a critique of Go, I feel the same way: I'm still going to continue to use it anyways. The reason why I am going to continue to use it anyways is because while I understand that it has plenty of easily documented issues in theory (and that people regularly do actually run into in practice), I still find that it is one of the better programming languages in practice anyways. Some of the things that pe…

> I guess I feel bad for people who are particularly sensitive to the areas that Go does not succeed in, because they are probably going to be complaining about it for the rest of their lives.

Well, that’s a stellar endorsement of the article, because that’s literally the point they’re making.

You’ll use go.

…and then regret it.

…but by then it’ll be too late, and you’re stuck with it.

I think the author makes a compelling argument, which is very difficult to counter, that it is a bad choice and you will regret having it in production in many of the explicitly listed cases, and in many professional situations where companies that are not technically competent use unsuitable tech.

Companies should stick to boring tools.

…but, for personal projects? Sure, go for it.

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

#84

Post by matwood »

pif wrote: post #44
vasco wrote: post #33

Earlier quoted context omitted.

"Manager imposes it on you" just means you work in a team rather than alone. You can pick whatever you like for side projects, of course you're going to use whatever your team uses otherwise.

[flagged]

> People tend to forget that Golang was created on purpose for poor programmers.

Poor programmers by Google's standards. I would argue the vast majority of programmers, even those outside of Google, don't want to be language researches, have no desire to be a language wonk, but want to build software to solve their and their companies problems. I read that quote and think it means that Golang is the only language the vast majority of programmers should be using unless they are researchers, not as a some veiled put down.

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

#86

Post by Cthulhu_ »

tonfreed wrote: post #42
jchw wrote: post #22

Every time I read a critique of Go, I feel the same way: I'm still going to continue to use it anyways. The reason why I am going to continue to use it anyways is because while I understand that it has plenty of easily documented issues in theory (and that people regularly do actually run into in practice), I still find that it is one of the better programming languages in practice anyways. Some of the things that pe…

Exactly. Every programming language is a tool in your toolbox, and you should choose the appropriate one for the job at hand. For me, that's Go around 95% of the time. I have no need to worry about a 24 byte overhead for a slice allocation, if I did have to worry about that, I'd probably use C or Rust.

And since Go is so readable, theoretically getting the core functionality out and rewriting it in a more specialized language would be fairly straightforward. And while it's an investment in time and effort to rewrite a chunk, at least you know what you're writing already.

But that's a point made in the article, that Go is also good for prototyping. But there's a few languages good for that, e.g. Ruby which powered a lot of the HN startups in their early days until parts needed to be rewritten for performance / scalability.

But writing a new, unproven product in a high performance, high difficulty language from the get-go is cargo cult; you hope you will need the performance and correctness offered by the language. Meanwhile, halfbaked hack jobs like Facebook and Twitter exploded in popularity and revenue, and while their performance issues gave their developers headaches, at least they knew what problems they had and had to solve instead of guessing and hoping.

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

#87

Post by theshrike79 »

liotier wrote: post #59
troupo wrote: post #12

Earlier quoted context omitted.

It's actually very rare that it should be the caller who has to handle the errors. Go, however, forces you to spread your error handling over a thousand little pieces with zero overview or control of what's happening. Rust eventually realised this and introduced try! and ? to simplify this

Unsure if this is the right place to ask, but this conversation inspires me this question: Is there in practice a significant difference between try/catch and Go's "if err" ? Both seem to achieve the same purpose, though try/catch can cover a whole bunch of logic rather than a single function. Is that the only difference ?

You can decide not to catch a thrown exception, it travels upwards automatically if you don't catch it.

I think that's the biggest difference.

With Go you need to specifically check the errors and intentionally decide what to do, do you handle it right there or do you bubble it upwards. If you do, what kind of context would the caller want from this piece of code, you can add that too.

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

#88

Post by surgical_fire »

jchw wrote: post #22

Every time I read a critique of Go, I feel the same way: I'm still going to continue to use it anyways. The reason why I am going to continue to use it anyways is because while I understand that it has plenty of easily documented issues in theory (and that people regularly do actually run into in practice), I still find that it is one of the better programming languages in practice anyways. Some of the things that pe…

I sort of like Go. The explicit error handling is a little obnoxious sometimes, but it's just a way to get things done. Otherwise I see its simplicity as a strength. It is very ergonomic, easy to pick up, and generally performs pretty well. I perhaps wouldn't pick it for every scenario, but there are plenty of scenarios where it would be a good tool.

Then again, I sort of like Java and Python too, two languages I am proficient enough at. All of those are good tools for what they intend to be.

I don't understand why people get so passionate about programming languages. They are tools. You may like soke more than others, but that doesn't invalidate the ones you don't like.

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

#89

Post by imjonse »

pif wrote: post #32
jchw wrote: post #22

Every time I read a critique of Go, I feel the same way: I'm still going to continue to use it anyways. The reason why I am going to continue to use it anyways is because while I understand that it has plenty of easily documented issues in theory (and that people regularly do actually run into in practice), I still find that it is one of the better programming languages in practice anyways. Some of the things that pe…

> I choose a language that I feel works well for me Which is the wisest choice for everyone. Golang is only a problem when a manager imposes it on you.

More generally, when it's not well suited for the problem to be solved. Eager coworkers anticipating Google level traffic may want to write the system in Go and multiple microservices when a simple FastAPI server would do.

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

#90

Post by rednafi »

I want to build things and could care less about intellectual masturbation. It was built for proletarians like myself. I like Go because it's neither Rust nor Python. But I do understand that there are times when having some nice abstractions over common patterns doesn't hurt. At the same time, Go has come a long way over the years.
Post reply on HN