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

191–200 of 526 posts

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

#191

Post by zozbot234 »

pema99 wrote: post #147
KingOfCoders wrote: post #61

Earlier quoted context omitted.

Exceptions are sum types, they just have different syntactic sugar.

Not really. Exceptions usually imply unwinding the stack, and the ability to catch at any point throughout the callstack. Result types are just 'dead' data.

These are fully equivalent in outcome, though often not low-level implementation. You can use try...catch (called panic...recover in Go) to pack a normal and abnormal return case into the equivalent of a Result type. Or just pass an abnormal Result back to the caller to manually unwind a single "layer" of the call stack.

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

#192

Post by spirit-sparrow »

euroderf wrote: post #74
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.

That should not be an issue, unless the code is written in notepad. As for interfaces, a better approach is to return struct and accept interface in your functions wherever it is possible.

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

#193

Post by iamcalledrob »

sureglymop wrote: post #133

Rust and Go are very different and I feel people want a middle ground that just doesn't exist currently. A garbage collected relatively simple language that compiles into a statically linked binary but has a type system similar to rust, rest types etc. Syntactically, Gleam and Kotlin come somewhat close but not really. I like Rust but I do believe it is too complicated for many people who are capable of creating some…

Kotlin is interesting as a middle ground, but I still find it much less productive than Go for most tasks, and unsuitable for tasks where you'd reach for Rust.

In practice, Kotlin is extremely complicated, and you end up spending time being clever. There are 1000 ways to do things. Operator overloading. Proxies. Properties. Companion objects. Exceptions AND result types...

The build system (assuming you use Gradle) is tantamount to torture for anyone used to "go build".

The coroutines APIs feel simultaneously more complicated and yet more restrictive than Goroutines. More structured but less flexible and more effort to use.

Access control feels awkward. There's no way to make a type package-private -- it's file-private or available to the whole module. This leads to either a larger API surface than desired, or the inability to break up complexity into multiple files.

Kotlin/Native and Kotlin/JVM really are two different beasts too.

Kotlin/JVM is mature, but then you are running on the JVM, so that cuts out a whole class of use cases you might bust out Rust for.

There is a very weak ecosystem for Kotlin/Native, and it's poorly documented. There are some scary bugs in the bug tracker.

You can't publish source-only libraries for Kotlin/Native either, so you need a complex CI setup to build binaries for every OS and arch under the sun. Or just don't publish libraries at all, which probably feeds in to the weak ecosystem...

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

#194

Post by gspr »

atemerev wrote: post #111

I wish I could take the Rust pill like everyone else and be happy. I am not a stranger to the programming world. I am fluent in Python, Java, Scala, Erlang. I can write acceptable Haskell and C++ and Common Lisp. I am well versed in functional programming (though I don’t hate OOP — it is still a good thing when done correctly, and I am a big fan of Smalltalk). However, for some reason, I am completely unproductive in…

I do miss several of the things you list, too, especially (safe) self-referential data structures. But Rust is a fantastic compromise solution if your number one priority is to match the performance (or rather, performance possibilities) of C and C++, and have memory safety while doing it. If your number one goal is to be able to write memory safe ideomatic code that is entirely comparable to those languages, and then add some functional programming and lots of quality of life stuff to that, then it's pretty sweet.

In other words: Don't think of it as rivalling the entry cost of Python or Java, or the expressiveness of Haskell or Scala. Try to think of it as a replacement for C++, with memory safety and piles of quality of life improvements. And then with a sprinkle of the other things on top.

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

#195

Post by shikck200 »

The author clearly does not weigh in on the "whys" some things work in Go like they do.

So, adding an extra struct field results in the base value, and by design this should be used as a base default. The go proverb make base values useful goes hand in hand.

Obviously functions are not the same. And calling function with the wrong args is a compile time error. There is also CI check that check for this use case.

Overall this seems like a comparison to Rust, and its obvious they are not same same. Apples to Oranges.

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

#196

Post by zapnuk »

tessela wrote: post #181
sureglymop wrote: post #133

Rust and Go are very different and I feel people want a middle ground that just doesn't exist currently. A garbage collected relatively simple language that compiles into a statically linked binary but has a type system similar to rust, rest types etc. Syntactically, Gleam and Kotlin come somewhat close but not really. I like Rust but I do believe it is too complicated for many people who are capable of creating some…

> A garbage collected relatively simple language that compiles into a statically linked binary but has a type system similar to rust, rest types etc. Swift.

If they'd drastically improved their tooling then yes.

But sadly it's not that easy to create a statically liked binary in swift. The last time i did it it also included the whole runtime, and the resulting "hello world" binary was 50mb large. Annoying at least.

For years I wished they got their stuff together, but at this point I'd be very suprised. They probably have too much technical dept already due to the support of XXX edge cases Apple need for iOS/MacOS development.

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

#197

Post by belter »

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.

The money shot....

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

#198

Post by coldtea »

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 like the explicit error handling everywhere

Then you're doing yourself a disfavor by using Go. In other languages it would be even more explicit, mandatory, and automatically checked whether it's handled!

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

#199

Post by lenkite »

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 like Go, but after writing/reading so much Go code, I get nightmares from `if err != nil` demons punching me in the face. There were so many nice suggestions made to fix this, but there are some extremely conservative and extremely loud-spoken community members who killed all the proposals with vitriolic feedback. Now, the Go team has given up the battle for improving error handling since they are psychologically afraid of these folks.

Every Go developer survey has results where the community overwhelmingly votes to improve error handling, but a few extremists have derailed all progress.

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

#200

Post by zozbot234 »

quotemstr wrote: post #105
pyrale wrote: post #66

Earlier quoted context omitted.

Exception and explicit on-the-spot handling are not the only two ways to handle failing processes. Optional/result types wrapping the are a clean way to let devs handle errors, for instance, and chaining operations on them without handling errors at every step is pretty ergonomic.

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…

The '?' operator is the opposite of a footgun. The whole point of it is to be very explicit that the function call can potentially fail, in which case the error is propagated back to the caller. You can always choose to do something different by using Rust's extensive facilities for handling "Result" types instead of, or in addition to, using '?'.
Post reply on HN