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

71–80 of 526 posts

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

#71

Post by vrnvu »

“An idiot admires complexity, a genius admires simplicity, a physicist tries to make it simple, for an idiot anything the more complicated it is the more he will admire it, if you make something so clusterfucked he can't understand it he's gonna think you're a god cause you made it so complicated nobody can understand it. That's how they write journals in Academics, they try to make it so complicated people think you're a genius” ― Terry Davis

Please note, no offense intended, I just like this quote to describe Go success.

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

#72

Post by DanielHB »

koito17 wrote: post #34
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

More importantly, Rust has the notion of a result type and it is designed to be both generic and composable. A problem I often face in Go and TypeScript code is code that ignores errors, often unintentionally. For instance, many uses of JSON.parse in TypeScript do not check for the SyntaxError that may be thrown. In Go, it is common to see patterns like _ := foo.Bar() // assume Bar() returns error This pattern exists…

I am pretty sure if it were for the Typescript creators they would not allow exceptions in the language, but they had to work within the confines of Javascript. Heck they even refused to make exceptions part of the type-system.

It is unfortunate that many of Typescript developers still rely on throwing exceptions around (even in their own typescript code). Result types are totally doable in Typescript and you can always wrap native calls to return result types.

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

#73

Post by Cthulhu_ »

monksy wrote: post #57
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…

> Go does not succeed in, because they are probably going to be complaining about it for the rest of their lives. A lot of people really don't like Go because they have experienced other language features. Go has taken an arrogant stance at trying to make the decision about what features you might need and has given you a very small amount of things to work with.

Counterpoint, other languages - notably Javascript, Scala, PHP, maybe Java - have taken the stance that they adopt other languages' features, not because the language needs it, but because developers were clamoring for it. Which led to added complexity, because they kept adding more and more ways to solve a problem or structure an application, which led to every codebase being so different from the next that the amount of transferable skills and knowledge became less and less. Scala is the worst offender for that IMO.

One frequent praise one hears of Go is that a developer can open any codebase and immediately understand what's happening. Go is readable and stable, which are critical for code for the long term.

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

#74

Post by euroderf »

misonic wrote: post #36

While the article raises some valid critiques, it often overlooks the fundamental tradeoffs that make Go successful in its niche. Go’s simplicity is not a flaw but a deliberate choice, enabling rapid onboarding and maintainable code for large teams. Its explicit error handling may seem verbose but ensures clarity and avoids hidden surprises common in exception-heavy languages. The complaints about ecosystem isolation…

This. And there is one technique that would help in this.

Too often I see code like "xyz := pkg1.SomeFunc(a, b, c)" that makes xyz's type non-evident, especially when interfaces are involved.

Please write Go code like

  var xyz pkg2.SomeType

  xyz = pkg1.SomeFunc(a, b, c)
My 0.02€, YMMV.

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

#75

Post by richbell »

KingOfCoders wrote: post #65

Go: "I'm a simple language!" User uses Go for some time. User: "I hate you, you're a simple language!" Perhaps it's because I'm 50+, I love a simple language. I feel the "critique" is not very balanced, and I view judgements that are not balanced as weak, as everything in technology is about tradeoffs. I of course come to a different conclusion: https://www.inkmi.com/blog/why-we-chose-go-over-rust-for-our...

I wish the discourse that Go is a "simple" language would die.

Despite its veneer, once you start writing Go it quickly becomes apparent that it isn't simple. Hidden complexity and footguns are abundant (e.g., https://archive.ph/WcyF4).

It's nevertheless a useful language, and I use it quite a bit, but it's not "simple".

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

#76

Post by theshrike79 »

monksy wrote: post #57
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…

> Go does not succeed in, because they are probably going to be complaining about it for the rest of their lives. A lot of people really don't like Go because they have experienced other language features. Go has taken an arrogant stance at trying to make the decision about what features you might need and has given you a very small amount of things to work with.

I love the fact that I can pick up a Go project from 5+ years ago and it still compiles with the current toolchain. I might need to do a 'go mod init' first.

It didn't get 67 new features that start shooting deprecation warnings on old functions in the meantime. I don't have to learn new paradigms or switch integral parts of my code to something new.

Generics has been in Go for dunno how long, haven't used it once. Didn't need to.

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

#77

Post by Cthulhu_ »

pmezard wrote: post #68
monksy wrote: post #57

Earlier quoted context omitted.

> Go does not succeed in, because they are probably going to be complaining about it for the rest of their lives. A lot of people really don't like Go because they have experienced other language features. Go has taken an arrogant stance at trying to make the decision about what features you might need and has given you a very small amount of things to work with.

And a lot of people using Go have experienced other language features as well and either decided against them or that the whole tradeoff was not worth it. I will keep very fast compilation times and decade long backward compatibility over a lot of your features. Because those are features too.

I mean I miss some language features for sure, but the problem with adding language features is that it adds long-term inconsistency. Take a Go codebase from 10 years ago and it should look mostly the same as it would if it was rewritten in modern Go. Do the same with Java and across generations you'd go from straight for loops, to generic iterators and their for-each syntactic sugar, to for-comprehensions, streams and their functional programming style, to whatever Java is up to in 2024, I stopped paying attention years ago.

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

#78

Post by masklinn »

the_gipsy wrote: post #29
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…

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…

> The weird "return tuple" , which obviously just exists for errors because there is not a single other place where you can use tuples in the language

MRV, go does not have tuples.

Go is not the only language with MRV (as a special case) and they’re not necessarily bad, iirc Common Lisp uses them as auxiliary data channels and has a whole host of functions to manipulate and refit them.

Go is singularly incompetent at MRVs though, in the sense that only syntax and builtin functions get access to variable arity (e.g. if you access a map entry you can either get one return which is a value, or two which are the value and whether the key is/was in the map). So MRVs mostly end up being worse tuples infecting everything (e.g. iterators needing Iter and Iter2 because you can’t just yield tuples to for loops).

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

#79

Post by monksy »

kybernetikos wrote: post #15
afiodorov wrote: post #14

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

I think this is exactly the right way to understand Go - it's targetted at building servers in environments where having strong consistency of code and a short ramp up time for junior engineers is valuable - i.e. it's perfect for all the big corp scenarios that Java was used for. I think maybe the more common, but less helpful comparison of go vs rust comes from the fact that they are both part of a new wave of langu…

> consistency of code

There are many stylecheck tools that should be apart of a good stack. Accepting the creator's style is putting a lot of weight on their opinion. Most organizations have their own preferences for good reason.

> short ramp up for junior engineers

Junior engineers aren't a place you're concerned on being productive. Most of the time at that stage in someone's career they should be learning more, getting up to speed with professional practices, tools, and trying to learn code bases+patterns. Ramp up time for a language is a very minor consideration.

Both of those things have very little to do with server environments.

Bigger corporations struggle with Go's module system and forced reliance on seperate repos for separate modules. (Can you bundle multiple modules in the same repo.. yes but you're going to have a bad time)

Post reply on HN