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

141–150 of 526 posts

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

#141

Post by maleldil »

bsaul wrote: post #49
pif wrote: post #31

Earlier quoted context omitted.

> 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. I kind of see your point. In this very moment, it doesn't matter whether I agree. What I don't understand, though, is why (typically) people who abhor exceptions are among the fiercest defenders of garbage collection, which does add a “magic” and uncontrollable layer to object d…

How does RAII works in concurrent systems ? It seems to me you need to add compile-time object lifetime evaluation (as in rust) which so far incurs a high toll on language complexity.

The exact same way it works in Rust. C++'s RAII works the same as Rust's Drop trait. The object is released when it goes out of scope, and if it's shared (e.g. Arc), it's released when the last reference to it drops.

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

#142

Post by poilcn »

poulpy123 wrote: post #110

It's weird. At a time I was looking for a "better" python. Something simpler and safer than C/C++ but faster than python and more importantly that can produce a single binary. So I looked at everything from Rust to obscure language like Hare. Go should have been the obvious choice but for a reason I don't understand I dislike its syntax. For Rust I understand: it uses a lot of special characters that aren't easy to r…

>and the fact it's so tied to windows

Dotnet Core is not tied to windows except for certain frameworks like wpf (and there are alternatives for it that work everywhere), credential store.

And it's actually really good to use these days.

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

#143

Post by nulld3v »

dondraper36 wrote: post #131
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…

I am not going to answer the questions, but this is a very strange complaint, to be honest. For example, passing by value/passing by reference is something covered immediately in the Go FAQ document once and for all. Everything is passed by value in Go, that is it. There should be no confusion at all. If you spend 15 minutes reading Russ Cox's post on the internals of the most common data types, you will also underst…

Well yes obviously I know everything is passed by value, just like in literally every other popular language. I'm talking about the difference between pointer parameters/receivers vs value parameters/receivers.

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

#144

Post by guappa »

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…

In my personal experience your average go developer that likes go, likes it because he doesn't really know anything else.

As a result most things written in go are, in my own experience, of lower quality compared to things written in other languages.

So using things written in go is usually my last resort, because I expect they won't be high quality before even downloading them.

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

#145

Post by zwnow »

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…

Commercial software is what pays my rent though. Why would I bother about open-source software other than personal interest?

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

#146

Post by maleldil »

euroderf wrote: post #74
misonic wrote: post #36

While the article raises some valid critiques, it often overlooks the fundamental tradeoffs that make Go successful in its niche. Go’s simplicity is not a flaw but a deliberate choice, enabling rapid onboarding and maintainable code for large teams. Its explicit error handling may seem verbose but ensures clarity and avoids hidden surprises common in exception-heavy languages. The complaints about ecosystem isolation…

This. And there is one technique that would help in this. Too often I see code like "xyz := pkg1.SomeFunc(a, b, c)" that makes xyz's type non-evident, especially when interfaces are involved. Please write Go code like var xyz pkg2.SomeType xyz = pkg1.SomeFunc(a, b, c) My 0.02€, YMMV.

I don't get it. Why not use a code editor that shows the inferred type on hover?

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

#147

Post by pema99 »

KingOfCoders wrote: post #61
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…

Exceptions are sum types, they just have different syntactic sugar.

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.

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

#148

Post by im_dario »

I remember it took a me a bit of investigation to make Ruby call Go functions, but it wasn't really hard: https://dario.cat/en/posts/portal-between-ruby-and-go/

The argument about FFI and CGO was the most unappealing to me. If you really need to do that, it feels that at some point some decisions were made that weren't the right fit for the project.

Also, I feel that many arguments in the article are potential pitfalls for unintended side effects I've experimented in other languages, like Ruby itself. Keyword arguments are nice, but I know that they've bitten me several times.

Go forces the developer to be explicit about their intentions, that's why I also don't find something bad that your struct functions need to have the pointer receiver. It can be annoying when you forget, but that's what linters are for.

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

#149

Post by underdeserver »

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#?

When last I tried it, maybe around 2014? I found it a kinder, cleaner Java with better tooling. Visual Studio (not Code) is still the best IDE I've ever used.

Unfortunately it's not popular in the circles I hang around in and the places I've worked. Now that .NET core is the one true runtime I'd welcome an opportunity to try it again; alas, I doubt I'll have such an opportunity (at least not through work).

I remember the upsides but I'm sure there are downsides I'm not aware of. I'd love to read a critique from someone with real world experience.

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

#150

Post by dwattttt »

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…

I very much care about whether a function can fail or not, and I encourage all the function colouring needed to convey that.
Post reply on HN