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

381–390 of 526 posts

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

#381

Post by xlii »

So I’m completely new to the Go but I have very specific need and I couldn’t fit it anywhere else:

I want to orchestrate asynchronous, highly fallible tasks. I could use Rust but I feel I would drown in correctness of handling various edge cases over which I’d rather panic and wind down everything I can.

Elixir/Erlang would also be an option, but getting it installed in specific version isn’t simple (and ASDF was guilty for long time of installing Elixir built on different OTP than defined one) and also problem lies in interacting with IOs, which also bring consequences.

And so, yeah, Go is simple enough so that I feel confident that if aj get hit by a bus there won’t be enough magic so that it won’t be picked up by someone and it… works.

After being in pull rope competitions with bash, sh, Perl and Python I have fun working with it.

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

#382

Post by wbl »

Yoric wrote: post #295
Cthulhu_ wrote: post #225

Earlier quoted context omitted.

This is down to developer style and agreements though; Go has typed errors and a set of utilities to match them [0]. Not using those is a choice, just like how in Java you can just `catch (Exception e)` after calling a dozen methods that might each throw a different exception. [0] https://pkg.go.dev/errors

Interestingly, every time (and I mean _every_ time) that I've tried to use `errors.As` on errors raised by lib code, I found out that the lib just went with "nah, I'm just going to use `errors.New` or `fmt.Errorf`", which makes the error impossible to match. So... I'd say that this is a fumble in the design of Go.

%W exists to solve this

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

#383

Post by guappa »

AnimalMuppet wrote: post #347
guappa wrote: post #164

Earlier quoted context omitted.

I managed to make go segfault multiple times (a real actual segfault). It's not a general purpose language. If you want to do things that aren't json RPC is awful.

A general purpose language must be one that you cannot cause to segfault? That's a rather... unique perspective.

A segfault is a security vulnerability :)

I expect a modern programming language that has a runtime to not do that, correct.

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

#384

Post by guappa »

mrbadguy wrote: post #361
guappa wrote: post #151

Earlier quoted context omitted.

Go is very boilerplate. It requires at least 3 lines of error checking every 1 line of actual code. Also it doesn't have packed structs so it's completely incapable of doing low level networking or to handle binary files (you can of course do all the bitwise operations yourself… but is it sensible to use a language that is more error prone than C in 2024?). Also due to its lack of A LOT of system calls, you will need…

I’m not sure I understand the packed structs complaint. I have used Go to read binary data and it’s quite easy. You just need to ensure that all of your struct fields have fixed sizes e.g. int32 or [4]int64 or whatever. Unless I’ve misunderstood what you mean?

Yes it works, but you can't state the endianness and you have no control to decide if the compiler will decide to insert padding. It's undefined.

You HOPE it works.

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

#385

Post by zaptheimpaler »

sterlind wrote: post #250
radicalbyte wrote: post #52

Earlier quoted context omitted.

Go is an iteration of C, not of Java. It's a really bad choice for situations where Java is a good choice as not only is the language limited, the ecosystem around it is also very limited when compared to say Java. I'm maintaining Go, C# and TypeScript as my main languages as that gives me excellent coverage. I'll add Rust to the mix when I have 6 months where I can accept the productivity drop or have a project wher…

How is Go an iteration of C? You can't use Go to write a kernel, or program a microcontroller, or for high-frequency trading or a web browser or a tensor library or a language run-time. It's either a bad idea or simply impossible, depending. Someone please explain to me what's C-like about Go other than vaguely the syntax and that it compiles to machine code.

The refusal to use anything language designers have learnt since 1970 is what makes it C. No sum types, poor error handling, no map/filter funcs, all the other stuff written in the post. Java has all of that, any language after the 90s has most of that, Go doesn't. Actually even C has sum types lol.

The fact that it can't fill many of the usecases that C can and yet has ergonomics as bad as C makes it even worse.

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

#386

Post by eikenberry »

pas wrote: post #234
spirit-sparrow wrote: post #217

I wonder what makes someone go such a great length to bash a language, any language. I say bashing, because even the few valid points in the post are not written in a constructive style. After all is there a language that can't be criticised? Is the post written to make one feel better having a failed a project the language? (It's not me, it's the language) Or is it the failure to understand that not everyone thinks…

> what makes someone go such a great length to bash ... """ Inherent complexity does not go away if you close your eyes. When you choose not to care about complexity, you're merely pushing it onto other developers in your org, ops people, your customers, someone. Now they have to work around your assumptions to make sure everything keeps running smoothly. And nowadays, I'm often that someone, and I'm tired of it. """…

That quote sounds like an argument against Rust, not GO. Rust is a complex language and that complexity doesn't go away if you close your eyes to it either. All complexity adds to project complexity.

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

#387

Post by dfawcus »

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…

Alef actually has/had real tuples, as does Limbo.

Looking at Alef, apart from using tuples to provide multiple return values in a C-like language, they don't seem to actually add much functionality over what Go has without them. One of the few extra things is the ability to pass a tuple over a channel, however passing a struct is more or less equivalent.

I've not looked in much detail at what Limbo could do with its tuples.

So maybe they don't really add that much, hence why they were not carried over when Go was created?

Alef had enums, Limbo has something like the Go constant scheme and iota. Limbo also had tagged unions / varient-records, in a sort of Pascal like fashion - the "pick adt".

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

#388

Post by stouset »

LinXitoW wrote: post #261
spirit-sparrow wrote: post #217

I wonder what makes someone go such a great length to bash a language, any language. I say bashing, because even the few valid points in the post are not written in a constructive style. After all is there a language that can't be criticised? Is the post written to make one feel better having a failed a project the language? (It's not me, it's the language) Or is it the failure to understand that not everyone thinks…

One very subjective, very irrational factor for my borderline hate for Go is that for years the Go zealots gaslighted everyone about every single part of Go. Anything that Go did, no matter if it was the most basic implementation or if other languages already did it (better), was essential, the best and only way to solve that issue. Anything Go did not do was superfluous and downright a conspiracy by Big Complexity t…

Dear christ yes.

“Go is designed as a systems programming language” has been retconned so that “systems” is redefined to mean programs talking over a network?

“Real programs won’t use repetitive error handling, but build on top of it.” I don’t think this one needs further explanation.

“Go doesn’t need xyz.” This is just the slow and painful process of the golang community realizing one at a time why other languages have the features they do.

“Explicit is good.” Explicit and verbose are not the same thing. You can have explicit and terse.

“Golang is simple.” Golang is primitive, not simple. There are tons of footguns and gotchas, not all of which are chronicled in the linked essay, which would have been so easy to avoid. And everyone just collectively internalizes these issues as if “just avoid writing those bugs” is a sane mindset any different than the languages that came before.

“Go doesn’t need a package managers.” Oops, it did. Now we’re like three attempts deep.

Over and over and over I feel like we’ve been gaslit and told we’re crazy, only to later on have the community act like (for example) golang always intended to add generics and of course they’re a good idea.

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

#389

Post by stouset »

Seb-C wrote: post #315
LinXitoW wrote: post #261

Earlier quoted context omitted.

One very subjective, very irrational factor for my borderline hate for Go is that for years the Go zealots gaslighted everyone about every single part of Go. Anything that Go did, no matter if it was the most basic implementation or if other languages already did it (better), was essential, the best and only way to solve that issue. Anything Go did not do was superfluous and downright a conspiracy by Big Complexity t…

Yes, I've also grown tired of this toxic mindset, as well as the whole "idiomatic Go" dogma that is very often an excuse for poor engineering practices.

“Worse is better” has become a justification for pushing out complete garbage instead of the warning against perfectionism it was originally intended as.

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

#390

Post by dfawcus »

packetlost wrote: post #338
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…

Rust and Go's lack of stack traces are basically equivalent in that you need to call an additional function to add the stack context to the error result. For go you use fmt.Errorf, in Rust you use .context from anyhow (bad practice in many contexts IMO) or .inspect_err + log. It's rather unfortunate that neither has an easy way of capturing a line number + file easily and appending it to the context. Go could easily…

> I agree that Go should really have an analogue to Rust's `?`, but you can't really do that in a sane way without sum types to represent your conditions. The very multiple-return style error propagation makes it impractical to do.

There is always the Odin style 'or_return' operator, which is defined for a similar situation.

https://odin-lang.org/docs/overview/#or_return-operator

Post reply on HN