Lies we tell ourselves to keep using Golang (2022)
fasterthanli.me
Lies we tell ourselves to keep using Golang (2022)
1–10 of 526 posts
Re: Lies we tell ourselves to keep using Golang (2022)
#2The title lacks a (2022)
Otherwise great article :)
Re: Lies we tell ourselves to keep using Golang (2022)
#3(2022) Discussions at the time:
(130 points, 148 comments) https://news.ycombinator.com/item?id=34188528
(748 points, 544 comments) https://news.ycombinator.com/item?id=31205072
Re: Lies we tell ourselves to keep using Golang (2022)
#4I 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
Re: Lies we tell ourselves to keep using Golang (2022)
#5This 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 explicit error handling which happens exactly where the errors occur every day. You can argue that Rust does it in a more elegant way, and I prefer it for personal projects. For big projects with a lot of developers of various skill level joining and leaving I think Go’s philosophy is one of the sanest approaches to error handling in the modern world.
Staying in that lane. In my part of the world Go is seeing adoption that no other “new” language has exactly because of its simplicity. It’s not the best language, but it’s often the best general purpose language because it has a lot of build in opinions which protect you from yourself.
Re: Lies we tell ourselves to keep using Golang (2022)
#6The author's last post they referenced is a bit bizarre. I don't think that some overly simplified and error prone std library APIs is a particularly compelling reason to dislike a language. I didn't read the entire thing though because it was extremely long
Re: Lies we tell ourselves to keep using Golang (2022)
#7> Because they're Go experts, they know the cost of using Go upfront, and they're equipped to make the decision whether or not it's worth it
Well maybe not.
If I’m an expert in only Java 6, I might not be aware of all sorts of useful features that other languages have, such as sum types, traits, type inference… I only know one side of the trade off.
I might be vaguely aware of those ideas and dismiss them because I can’t imagine how they would fit in my Java 6 workflow.
And yet when some of them arrive in later Javas, I begrudgingly use them. Years later I can’t imagine how I ever lived without them!
We’ve seen this play out so many times.
Remember when lambdas were just for weird functional languages?
Re: Lies we tell ourselves to keep using Golang (2022)
#8This 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…
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 programming. The number of things which can error in a program is far larger then those that can't.
Re: Lies we tell ourselves to keep using Golang (2022)
#9Even async in Go isn't that good, ultimately. You can't monitor channels, you can't properly react to errors, you can't shutdown and restart them. A panic in a channel will kill your program. Etc.
It's "we learned about green threads and didn't bother to learn anything else" approach (also prevalent in many other languages)
Re: Lies we tell ourselves to keep using Golang (2022)
#10This 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…
I would certainly argue against the claim that explicit error handling is far overkill.
Where I agree: It forces you to think about all of the possibilities your code might generate. (This is more of a C question than it is with other languages)
However, when abstracting blocks of code away, you don't always need to handle the error immediently or you may want to handle it down the stack.
You're giving up a lot of readability in order for the language to be particular.