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

151–160 of 526 posts

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

#151

Post by guappa »

underdeserver wrote: post #125
wokwokwok wrote: post #83

Earlier quoted context omitted.

> I guess I feel bad for people who are particularly sensitive to the areas that Go does not succeed in, because they are probably going to be complaining about it for the rest of their lives. Well, that’s a stellar endorsement of the article, because that’s literally the point they’re making. You’ll use go. …and then regret it. …but by then it’ll be too late, and you’re stuck with it. I think the author makes a comp…

Uhh, maybe. Where is the tradeoff analysis? Yeah, you might regret using Go when some zero value you forget to fill in somewhere pops up later and ruins your pipeline. But are you considering all the issues that didn't pop up because you chose Go? Java's boilerplate code? Rust and C++'s lifetime analysis and memory management? C's lack of tooling? Python/Typescript's runtime errors? Functional languages' tiny employe…

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 to use modules written by someone on github, which will happily segfault if you look at them funny.

So now you have hidden memory management! Fun!

Of course if all you do with go is a glorified jq script… sure then it's kinda fine.

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

#152

Post by Ygg2 »

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…

> Once every return is a Result, every call a ?, and every error a yeet

The Try operator (`?`) is just a syntax sugar for return. You are free to ignore it. Just write the nested return. People like it for succinctness.

Yeet? I don't understand, do you mean the unstable operator? Rust doesn't have errors either.

> what's the difference between your program and one with exceptions except the Result program being syntactically noisy and full of footguns?

Exceptions keep the stacktrace, and have to be caught. They behave similar to panics. If panics were heavy and could be caught.

Rust errors aren't caught, they must be dealt with in whatever method invokes them. Try operator by being noisy, tells you - "Hey, you're potentially returning here". That's a feature. Having many return in method can both be a smell, or it could be fine. I can find what lines potentially return (by searching for `?`).

An exception can be mostly ignored, until it bubbles up god knows where. THAT IS A HUGE FOOTGUN. In Java/C# every line in your program becomes a quiet return. You can't find what line returns because EVERY LINE CAN.

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

#153

Post by jchw »

dataflow wrote: post #132
underdeserver wrote: post #125

Earlier quoted context omitted.

Uhh, maybe. Where is the tradeoff analysis? Yeah, you might regret using Go when some zero value you forget to fill in somewhere pops up later and ruins your pipeline. But are you considering all the issues that didn't pop up because you chose Go? Java's boilerplate code? Rust and C++'s lifetime analysis and memory management? C's lack of tooling? Python/Typescript's runtime errors? Functional languages' tiny employe…

Thoughts on C#?

Not that you asked me but since Go is my goto language, my thought on C# is that it looks pretty cool. C# with hill-climbing thread pool and async seems rather compelling. I really see only two (major, obvious) downsides with C#:

- It has so much. language. design. This is both a strength and a weakness, of course, but C# really does take this to an extreme. I won't bother making a huge list of examples because I think you get the picture.

- Microsoft needs to stop doing things that harm confidence in .NET. Between the silliness of removing hot reloading from the CLI, the situation around debugging outside of Visual Studio products, and drama around the .NET organization... I feel cautious touching the .NET ecosystem. That's saying something considering the company that backs the Go programming language.

(Note: I have not used C# in production, so I can't speak to what it's like in that case. Seems like it's at least fairly "boring" in a good way for a lot of organizations though.)

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

#154

Post by nulld3v »

KingOfCoders wrote: post #112
nulld3v wrote: post #101

Earlier quoted context omitted.

This 100%, I was just about to type a long rant up about this. There are so many weird parts of the language that took me forever to grasp, and in many cases, I still don't have an intuitive grasp of things. And plenty of other examples that aren't in that article: - You have a struct with an embedded interface. Does the outer struct satisfy the embedded interface? And can I type assert the outer struct into whatever…

Your thinking is too complex for Go. You might be better of with Rust. Same about benchmarking, if you want and need the fastest code, or the best memory management, use Rust. If you need something faster than Python in general but not the fastest, use Go.

But that's the thing right? Like I come from Java. In Java, we have objects. They are pointers. That's it. You don't get to decide on whether you want a pointer or a value (I guess primitives are an exception lol). But it was so simple!

And same in JavaScript. Everything is a pointer except primitives. That's it. End of story.

And I have written Rust too, and while the situation is definitely more complicated there, the guidance is extremely simple and straightforward: If the struct implements Copy, then it is very cheap to copy and you should pass by value. Otherwise, you should pass by pointer/reference.

And meanwhile in Go, I just see pointers and values being used seemingly interchangeably, and seemingly at random.

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

#155

Post by ForceBru »

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 and has a [good] type system

Yeah! Pattern matching too. What are currently available languages closest to this? AFAIK, Gleam relies on a virtual machine, but otherwise seems promising.

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

#156

Post by WesolyKubeczek »

thaumasiotes wrote: post #127
WesolyKubeczek wrote: post #11

The article is great. The bigger picture, of course, is that it’s always “pick your poison”. On one hand, say, I love operator overloading, I love how Python does it (once you satisfy an interface, its operators Just Work). On the other hand, I can appreciate the choice not to do it at all because half of the ecosystem will do it, and another half won’t. Also, it would require implementing function overloading, and i…

> I love operator overloading, I love how Python does it (once you satisfy an interface, its operators Just Work). Is this different from other styles of operator overloading? Why does it matter whether, when I want to overload the + sign, I need to define a function called `__add__` or `operator+`?

For me it's easier to introspect, fewer unexpected corners. Contrast this with operator overloads which you can put literally anywhere.

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

#157

Post by DanielHB »

masklinn wrote: post #82
DanielHB wrote: post #62

Earlier quoted context omitted.

You hit the main gripe I have with Go, its types system is so basic. I get people raving type-correctness of Go when they come from Python but the type system in Go is simply pre-historic by modern day standards.

Go’s type system is not even impressive compared to python’s .

Well I was comparing to python codebases before they added type annotations

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

#158

Post by guappa »

pif wrote: post #32
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 choose a language that I feel works well for me Which is the wisest choice for everyone. Golang is only a problem when a manager imposes it on you.

Plenty of software engineers don't know any better themselves

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

#159

Post by k__ »

yapyap wrote: post #130

Okay so I’m wondering, if you’re not in the Golang universe yet, what language is better to start with learning?

Depends on what you want to do.

Go's channels are probably awesome, if you need parallel computing.

If you want to build in k8s land, you can't avoid Go.

But besides that?

Maybe, use Gleam or Elixir.

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

#160

Post by underdeserver »

guappa wrote: post #151
underdeserver wrote: post #125

Earlier quoted context omitted.

Uhh, maybe. Where is the tradeoff analysis? Yeah, you might regret using Go when some zero value you forget to fill in somewhere pops up later and ruins your pipeline. But are you considering all the issues that didn't pop up because you chose Go? Java's boilerplate code? Rust and C++'s lifetime analysis and memory management? C's lack of tooling? Python/Typescript's runtime errors? Functional languages' tiny employe…

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 worked on a project with gopacket. It was completely fine.
Post reply on HN