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

181–190 of 526 posts

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

#181

Post by tessela »

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.

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

#182

Post by KingOfCoders »

GaryNumanVevo wrote: post #170
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...

Go is "simple" insofar as you're doing simple things. If you've tried writing a KV store or database (as I have) you'll quickly find yourself wanting slightly more modern language features.

"quickly find yourself wanting slightly more modern language features."

Use the tool that works for you.

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

#183

Post by didntcheck »

OtomotO wrote: post #123
quotemstr wrote: post #91

Earlier quoted context omitted.

Hard disagree. Exceptions are actually good. They make code clear and errors hard to ignore. I've written a ton of code over decades in both exceptional and explicit-error languages and I'll take the former every day. There's no function color problem. No syntactic pollution of logic with repetitive error propagation tokens. Also, exception systems usually come with built in stack trace support, "this error caused by…

Bah, no, I hated that you had to wrap basically every code block in a try/catch in Java, because the underlying lib could change and suddenly throw a Runtime-Exception. At the same time Checked Exceptions were a nightmare as well, because suddenly they were part of the contract, even though maybe wrong later.

> the underlying lib could change and suddenly throw a Runtime-Exception.

And what would you do in that case? Since this is a future change your existing code presumably wouldn't know what else to do but throw its own exception, so why not just let that one propagate?

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

#185

Post by GaryNumanVevo »

KingOfCoders wrote: post #182
GaryNumanVevo wrote: post #170

Earlier quoted context omitted.

Go is "simple" insofar as you're doing simple things. If you've tried writing a KV store or database (as I have) you'll quickly find yourself wanting slightly more modern language features.

"quickly find yourself wanting slightly more modern language features." Use the tool that works for you.

Feel free to take a look at any more complicated GoLang code (k8s, gorm, etc) and you'll see that the tool/library you're depending on requires a veritable rats nest of bad practices to work around the Go's inherent limitations.

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

#186

Post by KingOfCoders »

eru wrote: post #140
KingOfCoders wrote: post #102

Earlier quoted context omitted.

Yes, like "Opening Brace Can't Be Placed on a Separate Line" (from your link). Everyone can read Go code and understand what happens. There are some minor difficulties like func (*A) vs func (A).,

RiscV assembly is even easier to read by that metric.

My assembler days were 4 decades ago, but

"Everyone can read Go code and understand what happens."

There seems to be a difference between "easy to read" and "understand what happens" - or what happens on what level. The challenge is that there is a tradeoff between the two. Assembler is too low to understand what "really" happens, on the other hand Haskell for example with Monad stacks is again very easy to read + understand what happens "most of the time", but hard to understand all the abstracted away side effects.

In Haskell with

   add 3 5
everything can happen beside what you see.

In assembler

  ld a, 3
  add a, 5
nothing happens except these two instructions.

The tradeoff is how much you want to be explicit, with the downside of creating too much noise, and how much you want to abstract away, with the downside of magic happening somewhere.

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

#187

Post by worldsayshi »

Cthulhu_ wrote: post #73
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.

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 amou…

The one language feature that I miss in most languages is pattern matching. I wonder if there's any minimalistic language that implements pattern matching well?

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

#188

Post by pyrale »

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…

I'm not sure why you bring up Rust here, plenty of libs/languages use the Result pattern.

Your explanation of what bothers you with results seems to be focused on one specific way of handling the result, and not very clear on what the issue is exactly.

> what's the difference between your program and one with exceptions

Sometimes, in a language where performance matters, you want an error to be handled as an exception, there's nothing wrong with having that option.

In other languages (e.g. Elm), using the same Result pattern would not give you that option, and force you to resolve the failure without ending the program, because the language's design goals are different (i.e. avoiding in-browser app crash is more important than performance).

> syntactically noisy

Yeah setting up semantics to make users aware of the potential failure and giving them options to solve them requires some syntax.

In the context of a discussion about golang, which also requires a specific pattern of code to explicitly handle failures, I'm not sure what's your point here.

> full of footguns

I fail to see where there's a footgun here? Result forces you to acknowledge errors, which Go doesn't. That's the opposite of a footgun.

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

#189

Post by pwdisswordfishz »

masklinn wrote: post #78
the_gipsy wrote: post #29

Earlier quoted context omitted.

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…

> MRV, go does not have tuples.

> MRVs mostly end up being worse tuples

I think you noticed yourself that you’re getting too hung up on terminology. Multiple return values are a half-hearted, non-reified version of tuples.

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

#190

Post by flir »

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…

I see a lot of people say this about exceptions, and I don't have that problem. The exception bubbles up the stack until something catches it. Ok it's a different code path, but it's a very simple one (straight up). So you either catch the exception nearby and do something specific with it, or it bubbles up to a generic "I'm sorry there was a problem please try again later" handler.

Honestly makes me wonder what I'm missing. Maybe it's because I don't deal with state much? Do the problems start to mount up when you get into writing transaction locks, rollbacks etc? But I don't see why you wouldn't have the same problems with Go's mechanism.

Hoping to gain enlightenment here.

[copied from a comment below]: They are just horrific gotos that any library can invoke against your code. They are pretty much never, ever handled correctly. And nearly always, after an exception is “handled”, the application is actually in an unknown state and cannot be reasoned about.

Maybe this is it? I prefer a "fail early and often" approach, and I tend to validate my data before I perform operations on it. I don't want to attempt recovery, I want to spew log messages and quit.

Post reply on HN