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

201–210 of 526 posts

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

#201

Post by coldtea »

surgical_fire wrote: post #88
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 sort of like Go. The explicit error handling is a little obnoxious sometimes, but it's just a way to get things done. Otherwise I see its simplicity as a strength. It is very ergonomic, easy to pick up, and generally performs pretty well. I perhaps wouldn't pick it for every scenario, but there are plenty of scenarios where it would be a good tool. Then again, I sort of like Java and Python too, two languages I am…

>I don't understand why people get so passionate about programming languages. They are tools.

Because when you're a professional programmer, tools are a huge part of what you do and how you do it, same like a race driver would need to be passionate about cars.

It's just that for an e.g. carpenter, tools are more or less standadized and simple enough to evaluate.

If saws and hammers and routers had as much variety as programming language tooling, and were as multi-faceted to evalute, carpenters would be absolutely obsessed with using the good ones - even more so than they already are.

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

#202

Post by Joker_vD »

shikck200 wrote: post #195

The author clearly does not weigh in on the "whys" some things work in Go like they do. So, adding an extra struct field results in the base value, and by design this should be used as a base default. The go proverb make base values useful goes hand in hand. Obviously functions are not the same. And calling function with the wrong args is a compile time error. There is also CI check that check for this use case. Over…

Rust is also not the same as C, and therefore shall not be compared to it. Crabs to Cats.

Of course they are not same; that's why we want to compare them in the first place: were they the same, there'd be no need to compare them at all. Since, you know, they would be same and have no differences.

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

#203

Post by coldtea »

jchw wrote: post #107
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…

There's no tool boring enough to prevent any chance of regret. At the end of the day, it's really, really difficult to anticipate where your pain points will actually wind up in the real world. In practice, I've had lots of really good production success with Go and not too much heartache about the choice. Since adopting it personally (in around 2014) almost every company I've gone to work since has used Go in some c…

>There's no tool boring enough to prevent any chance of regret.

I'm not so sure. I know C programmers that swear by it, warts and all, with absolutely zero regrets for using it e.g. in the embedded space.

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

#204

Post by masklinn »

pwdisswordfishz wrote: post #189
masklinn wrote: post #78

Earlier quoted context omitted.

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

No, MRVs can actually offer useful properties and features, that is what they do in Common Lisp. That Go does not do that has nothing to do with MRVs.

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

#205

Post by pansa2 »

tessela wrote: post #181
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.

> relatively simple

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

#206

Post by impulser_ »

Every time I work in a different language I'm always wanting to go back to Go even if it's not the perfect language.

I just love the fact that it literally just works. You install Go, you download code, and write code that's it.

No figuring out what version, runtimes, configurations, build tools, package managers to use. Just install and Go.

I think maybe Rust is the only other programming language that provides the same experience.

Maybe these are just lies I'm telling myself, but every time I use Python, Typescript, or Java I dread programming because I just want to write code and I'm often debugging things or figuring out related to configurations, package managers, build tools and versioning.

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

#207

Post by biorach »

pwdisswordfishz wrote: post #189
masklinn wrote: post #78

Earlier quoted context omitted.

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

Which is what they said. I'm not sure what point you're making

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

#208

Post by pyrale »

quotemstr wrote: post #122
maleldil wrote: post #119

Earlier quoted context omitted.

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

No, because you end up with a function coloring problem that way. A function that returns something other than Result has to either call only infallible code or panic on error, and since something can go wrong in most code, the whole codebase converges as time goes to infinity on having Result everywhere. Yeah, yeah, you can say it's explicit and you can handle it how you want and so on, but the overall effect is jus…

> A function that returns something other than Result has to either call only infallible code or panic on error

...Or solve the problem. A library function that can be a source of issues and can't fix these issues locally should simply not be returning something that is not a result in that paradigm.

> since something can go wrong in most code

That is not my experience. Separating e.g. business logic which can be described cleanly and e.g. API calls which don't is a clear improvement of a codebase.

> the whole codebase converges as time goes to infinity on having Result everywhere.

As I said previously, it is pretty easy to pipe a result value into a function that requires a non-result as input. This means your pure functions don't need to be colored.

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

#209

Post by zozbot234 »

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.

You just described Ocaml and ReasonML (which is Ocaml with Go-like syntax).

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

#210

Post by biorach »

zozbot234 wrote: post #191
pema99 wrote: post #147

Earlier quoted context omitted.

Not really. Exceptions usually imply unwinding the stack, and the ability to catch at any point throughout the callstack. Result types are just 'dead' data.

These are fully equivalent in outcome, though often not low-level implementation. You can use try...catch (called panic...recover in Go) to pack a normal and abnormal return case into the equivalent of a Result type. Or just pass an abnormal Result back to the caller to manually unwind a single "layer" of the call stack.

> These are fully equivalent in outcome

They are so different in DX, ergonomics, implementation and traceability that I'm not sure this is true other than in the most abstract sense

Post reply on HN