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

111–120 of 526 posts

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

#111

Post by atemerev »

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 Rust. It always fights me. There’s always something I want to do (graph structures? spliced lists?), and it’s always “you don’t need that” and “it’s not the Rust way”. There’s always explicit lifetimes and you miss something and you need to rewrite huge swaths of your code. And nothing is refactorable. It’s not even a good functional language, there are no persistent data structures, and it’s a pain to make them, and no ways to express yourself functionally like I used to do with Scala.

But apparently, everyone and their dog like Rust and are insanely productive in it. What am I missing?

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

#112

Post by KingOfCoders »

nulld3v wrote: post #101
richbell wrote: post #75

Earlier quoted context omitted.

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".

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.

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

#114

Post by ralegh »

theshrike79 wrote: post #76
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.

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. D…

I used generics once, was kinda useful, but definitely avoidable. The only feature I could see myself using is something Linq-esque for slices and maps. Otherwise I’m content.

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

#115

Post by mort96 »

wokwokwok wrote: post #83
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 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…

There's plenty of software I work on from time to time that's written in Go which I'm happy are written in Go. Some of those were even projects which I started and chose the language for.

Then there's software I've been involved in where I believe Go was the wrong choice. And software not written in Go where I believe Go would have been the wrong choice.

My point is, Go is just another programming language, with a unique set of strengths and weaknesses, and there are plenty of cases which i have experienced myself where there are genuinely no regrets around picking Go. Not because there aren't shortcomings in Go, but because there are plenty of cases where those shortcomings don't matter.

In my professional life, I have seen significantly more regret associated with choosing JavaScript on the back-end than with choosing Go. But then again, there are services in production written in JavaScript where that just never has been an issue and there are no regrets.

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

#116

Post by fransje26 »

Jare wrote: post #37

> Evidently, the Go team didn't want to design a language. This excerpt should be enough for you to know if you will find the article insightful or useless.

And this is why I normally start by going to the HN comments before reading an article.

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

#117

Post by OtomotO »

stouset wrote: post #45
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…

Without fail, every single person I’ve seen rave about go’s error handling compares it only to exceptions as if that’s the only alternative. On the flip side I have yet to find a person who’s familiar with sum types (e.g., Maybe, Option, Result) that finds the golang approach even remotely acceptable.

Here, you've found me.

I don't LIKE it, but it's acceptable.

I have been working with Rust since 2015 (albeit not professionally, but a lot of side projects) and love it.

But I also dabbled into go the last couple of months and while it has its warts, I see it as another tool in the tool-belt with different trade-offs.

Error handling is weird, but it's working, so shrug

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

#118

Post by OtomotO »

abtinf wrote: post #25
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…

Having programmed for over 30 years, including nearly a decade of C#, I would say exceptions are one of the worst ideas in all of programming. 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. Even junior enginee…

But with Exceptions you can easily implement multiple return types in e.g. Java ;)

I shocked my Professor at university with that statement. After I started laughing, he asked me more questions... still went away with a straight A ;D

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

#119

Post by maleldil »

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…

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

Because errors as values are explicit. You're not forced to use ? everywhere; you can still process errors however you like, or return them directly to the calling function so they deal with it. They're not separate control flow like exceptions, and they're not a mess like Go's.

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

#120

Post by abenga »

instig007 wrote: post #69
zwnow wrote: post #53

Earlier quoted context omitted.

You can call us poor programmers if that boosts your ego. The industry is still built upon people who can build fast. Go allows that and so does Javascript. You might not like it but that's what is earning most people their bread nowadays.

> The industry is still built upon people who can build fast. Correction: the commercial software is, not the industry. The industry and corporations are capitalising on quality open-source software, meticulously written off working hours with a straight head and passion, and a great attention to details. The fact that you can write glue fast enough to satisfy your SLT is predicated on the presence of those quality c…

What, no quality tools exist written "with passion, and a great attention to details" in Go? *Doubt.
Post reply on HN