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

161–170 of 526 posts

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

#161

Post by grey-area »

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…

No, because it's an example of someone who chose Go and didn't regret it, and continues to choose Go, because the objections of the article are in practice just not very important or compelling.

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

#162

Post by 0x_rs »

CTRL+F "rust", 24 matches, I had a feeling that would be the case. What does Golang, for the most part, have to do with Rust? I also find the following bit somewhat funny:

>The success of Rust is due in large part to it being easy to adopt piecemeal and playing nice with others.

And as if Rust itself didn't suffer from the same kind of imperfections one can find in Golang. So much for that "nothing new under the sun" back in 2012! But then it starts talking about the "rust shills" boogeyman, and one has to wonder if it's not trying to justify one's choices. (which is fine, anyway) And I agree wholeheartedly to each and every single one of the "lies" listed in the article, that you could very easily rewrite half of which to fit Rust, and the other half requires no changes to apply.

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

#163

Post by cnity »

OtomotO wrote: post #117
stouset wrote: post #45

Earlier quoted context omitted.

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

Sorry, balanced opinions are not welcome in discussions about favourite programming languages.

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

#164

Post by guappa »

matwood wrote: post #84
pif wrote: post #44

Earlier quoted context omitted.

[flagged]

> People tend to forget that Golang was created on purpose for poor programmers. Poor programmers by Google's standards. I would argue the vast majority of programmers, even those outside of Google, don't want to be language researches, have no desire to be a language wonk, but want to build software to solve their and their companies problems. I read that quote and think it means that Golang is the only language the…

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.

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

#165

Post by fire_lake »

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…

Try F# with the new AoT compilation option and publish single file switch.

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

#166

Post by madeofpalk »

monksy wrote: post #10
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 would certainly argue against the claim that explicit error handling is far overkill. Where I agree: It forces you to think about all of the possibilities your code might generate. (This is more of a C question than it is with other languages) However, when abstracting blocks of code away, you don't always need to handle the error immediently or you may want to handle it down the stack. You're giving up a lot of re…

> It forces you to think about all of the possibilities your code might generate.

Except it doesn't actually. You can totally just ignore it and pretend errors don't exist. Lack of sum types/Result, and pointers as poor mans optional, really hinder's Go's error handling story.

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

#168

Post by iamcalledrob »

There's a lot of valid critique of Go, but I've never found anything like it that lets me build lasting, high quality, bug free software.

Explicit error handling means that I actually think about and handle errors. No surprises in production. No random exceptions throwing deep inside some dependency. I've been running some Go services for years with no crashes.

The brain-dead simplicity means I am not tempted to waste time being clever.

The tooling means my code is trivial to build, even years later on a new machine.

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

#169

Post by cnity »

euroderf wrote: post #63
stouset wrote: post #45

Earlier quoted context omitted.

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.

FWIW... WebAssembly has Option and Result, and adapters for Go.

What do you mean by this? WebAssembly is a low level bytecode which only defines low level types. WebAssembly doesn't "have" types any more than x86 "has" types right? Or have I missed something?

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

#170

Post by GaryNumanVevo »

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.
Post reply on HN