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

351–360 of 526 posts

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

#351

Post by jonathaneunice »

I see this false promise all the time: Simple tools are simple to use.

NO. Not necessarily. Use a handsaw to fell a forest if you like, or a hoe to till 1,000 acres. But I will not. Tool simplicity will come back to bite you if the task you're trying to accomplish is complex or high-scale. And simplicity of design in no way correlates to simplicity of outcome, or of your workflow using the tool.

Golang has, to be fair, more going for it than just its relative simplicity. But in many ways the OG criticism rings solidly true. The "we'll do just enough language features and tooling" becomes an abdication and an excuse in a complex world.

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

#352

Post by atemerev »

gspr wrote: post #194
atemerev wrote: post #111

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…

I do miss several of the things you list, too, especially (safe) self-referential data structures. But Rust is a fantastic compromise solution if your number one priority is to match the performance (or rather, performance possibilities) of C and C++, and have memory safety while doing it. If your number one goal is to be able to write memory safe ideomatic code that is entirely comparable to those languages, and the…

I am fine with C++ memory safety if I am mostly working with RAII and explicit move semantics when needed (it is not perfect, but it will get us through the night). However, fighting the borrow checker drastically _decreases_ my quality of life, and I couldn’t find the way to get myself to free flowing code as I had in other languages.

Interestingly, I have the same feeling when trying to write something with Vulkan — the amount of ceremony and boilerplate before you even get to the first triangle is a huge barrier for my productivity. I want something more immediate.

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

#353

Post by jchw »

coldtea wrote: post #257
jchw wrote: post #235

Earlier quoted context omitted.

If anyone tells you C is "boring", that's just plain and simple bullshit. C gives you undefined behavior, buggy compilers (yes even for simple C code, MSVC is especially bad at plain C but there are other offenders) and the world's worst standard library for manipulating strings. Using C in embedded development is probably OK, even if you have to suffer with whatever crappy vendor compiler you are stuck with, but tha…

> If anyone tells you C is "boring", that's just plain and simple bullshit. C gives you undefined behavior, buggy compilers (yes even for simple C code, MSVC is especially bad at plain C but there are other offenders) and the world's worst standard library for manipulating strings. Boring doesn't mean "has no issues" or "takes care of everything for you". It means, stable syntax, lots of mature tooling and compilers,…

> It means, stable syntax, lots of mature tooling and compilers, and any problems the language has are well known.

In case of C what it really means is that the compiler codebases are extremely old and sometimes in rather bad shape.

Speaking of stable, C hasn't just stayed still: The C23 standard adds plenty of fun new things, like an annotation for unreachable code. Modern C has threads and synchronization primitives, #embed, complex numbers, and plenty more.

> Of the various languages around, C is the least likely one to have "buggy compilers"

C compilers are still routinely buggy, because the memory model is surprisingly tricky, there are many edge cases in the specification that are subtle and despite being fairly basic are not stressed often enough to come up, and because optimizing C while adhering to its rules about defined behavior is an unending arms race about what is still "technically" compliant with the standard.

Again, this is especially true if we're considering embedded development where the compiler you have might be a random hacked up old build of some vendor compiler rather than at least being recent GCC or Clang. In that case, even if you only consider a small subset of C99, there's still plenty of room for things to go wrong.

By any standard you can come up with, C is just plain-and-simple not a boring reliable solution. As it turns out, something being old and relatively simple isn't enough to make it boring; you can still have a pathological case that is just an absurd clusterfuck.

I will grant you one thing: it is the most boring embedded development solution. But come on. The best modern competition is Rust. Being more boring than Rust is not exactly an impressive accomplishment, especially when you consider how much practical value Rust has to offer.

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

#354

Post by cowl »

Yoric wrote: post #292
cowl wrote: post #179

Earlier quoted context omitted.

this part of error handling is pure religion. it goes even against one of the most basic go tenents. that code should be easy to read not write. Try reading and understanding the logic of a particular method where 75% of the lines are error noise and only 25% are the ones you need to understand what the method does. yes it's noise because whenever read a codebase for the first time you are never interested on the the…

Do you have examples for the latter?

the most basic example was the declined proposal https://github.com/golang/proposal/blob/master/design/32437-...

Some people didn't like the "try" keyword it reminded them too much of exceptions, some people didn't like that they couldnt see a return inline (which was the purpose of the proposal in the first place).

it's not that there are no solutions. the main problem is the go team's insistence to have "one true way" (tm) of doing something and unfortunately this gap between people who want to see every return inline and people who want to see the clean solution separate from the error handling is not something that can be bridged by technical means. the only solution is to implement both ways and lets see which one wins.

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

#355

Post by funcDropShadow »

dwattttt wrote: post #150
quotemstr wrote: post #122

Earlier quoted context omitted.

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.

As almost always, we programmers / software developers / engineers, forget to state our assumptions.

In closed-world, system-software, or low-level software you want to have your kind of knowledge about everything you call. Even more: can it block?

In open-world, business-software, or high-level software it is often impossible or impractical to know all the ways in which a function or method can fail. What you need then, is a broad classification of errors or exception in the following two dimensions: 1. transient or permanent, 2. domain or technical. Those four categories are most of the time enough to know whether to return a 4xx or 5xx error or to retry in a moment or to write something into a log where a human will find it. Here, unchecked exceptions are hugely beneficial. Coincidentally, that is the domain of most Java software.

Of course, these two groups of software systems are not distinct, there is a grey area in the middle.

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

#356

Post by adsharma »

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…

Nuitka is compatible, but comes with the shortcomings of python C-API

There are other approaches which give up on C-API and build a bridge to languages such as Go and Rust.

I've spent a few years working on py2many. Would appreciate feedback on the approach.

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

#357

Post by Groxx »

LinXitoW wrote: post #261
spirit-sparrow wrote: post #217

I wonder what makes someone go such a great length to bash a language, any language. I say bashing, because even the few valid points in the post are not written in a constructive style. After all is there a language that can't be criticised? Is the post written to make one feel better having a failed a project the language? (It's not me, it's the language) Or is it the failure to understand that not everyone thinks…

One very subjective, very irrational factor for my borderline hate for Go is that for years the Go zealots gaslighted everyone about every single part of Go. Anything that Go did, no matter if it was the most basic implementation or if other languages already did it (better), was essential, the best and only way to solve that issue. Anything Go did not do was superfluous and downright a conspiracy by Big Complexity t…

Yeah, this was/is a part big part of my frustration with the ecosystem too. It set a LOT of very problematic patterns in place in the beginning, and many of them are still not unwound.

Stuff like "Go doesn't need dependency injection because it's simple". I heard that literally dozens of times. The opposite is true! It's an even bigger pain without DI because the language is so simple! DI everything or make your users suffer!

Or a personal favorite: "Go doesn't need a package manager". We see where that went, and how much insanely better it is now that we have it.

Or errors. Without wrapping. Oh boy we're gonna pay for that for decades.

There's stuff to like in the language, but the zealots (especially early ones) really did not know which parts they were.

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

#358

Post by stouset »

theshrike79 wrote: post #87
liotier wrote: post #59

Earlier quoted context omitted.

Unsure if this is the right place to ask, but this conversation inspires me this question: Is there in practice a significant difference between try/catch and Go's "if err" ? Both seem to achieve the same purpose, though try/catch can cover a whole bunch of logic rather than a single function. Is that the only difference ?

You can decide not to catch a thrown exception, it travels upwards automatically if you don't catch it. I think that's the biggest difference. With Go you need to specifically check the errors and intentionally decide what to do, do you handle it right there or do you bubble it upwards. If you do, what kind of context would the caller want from this piece of code, you can add that too.

> With Go you need to specifically check the errors and intentionally decide what to do, do you handle it right there or do you bubble it upwards.

Is this really all that interesting or worth the LOC spent on error handling when 99.9999% of the time in practice it’s just bubbled up?

And any “context” added is just string wrapping. Approximately nobody types golang errors in a way that lets you programmatically know what went wrong, to be able to fix it in-line.

I think I would be more empathetic to the arguments defending golang here if I’d ever worked or seen a project where people actually handled errors instead of spending 2/3 of their time writing code that just punts on any error.

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

#360

Post by yegle »

the_gipsy wrote: post #29
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…

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…

https://github.com/pkg/errors provides stack traces support. This unfortunately did not get included in the Go1.13 release when error wrapping was introduced.
Post reply on HN