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

261–270 of 526 posts

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

#261

Post by LinXitoW »

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 to keep us unenlightened Non-Goers addicted to the Syntax Sugar: Things like sane null handling, sane error handling, less boilerplate, generics, or not creating special cases for everything (generics and tuples) instead of developing one cohesive solution.

Even now, in this thread, the strawmanning continues: Error handling is brought up, and instead of admitting the unmistakable truth that Gos error handling could be much better (s. Rust), people bring up things like JavaScript. As if anyone criticizing Go that JavaScript was the pinnacle of error handling.

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

#262

Post by chrismorgan »

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…

One practical benefit of Rust’s approach that hasn’t been emphasised enough yet is the consequences of Option and Result being just values, same as anything else.

It means you can use things like result.map_err(|e| …) to transform an error from one type to another. (Though if there’s a suitable From conversion, and you’re going to return it, you can just write ?.)

It means you can use option.ok_or(error) or option.ok_or_else(|| error) to convert a Some(T) into an Ok(T) and a None into an Err(E).

It means you can .collect() an iterator of Result into a Vec>, or (one of the more spectacular examples) a Result, E> which is either Ok(items) or Err(first_error).

It’s rather like I found expression-orientation, when I came to Rust from Python: at first I thought it a gimmick that didn’t actually change much, just let you omit the `return` keyword or so. But now, I’m always disappointed when I work in Python or JavaScript because statement-orientation is so limiting, and so much worse.¹ Similarly, from the outside you might not see the differences between exceptions and Rust-style Result-and-? handling, but I assure you, if you lean into it, it’s hard to go back.

—⁂—

¹ I still kinda like Python, but it really painted itself into a corner, and I’ve become convinced that it chose the wrong corner in various important ways, ways that made total sense at the time, but our understanding of programming and software engineering has improved and no new general-purpose language should make such choices any more. It’s local-maximum sort of stuff.

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

#263

Post by trissi1996 »

fasterthanlime wrote: post #211
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…

(author here) in which ways does Gleam come short of that? Because I'm also looking for that middle ground and I was very curious to get a look at Gleam.

IMHO it's just that it's a beam VM language, which is a fatter runtime/ecosystem than is really needed to achieve the goal stated above can bring it's own bag of problems (but also it's own superpowers).

Also to be productive you have to utilize the rest of the erlang ecosystem, so at least some superficial knowledge in elixir & erlang is helpful for for some use-cases.

Syntactically I actually don't think it's that for off, but I dunno what GP was thinking, maybe that it leans more into functional patterns & sugar for those whereas rust/go can also be used in a procedural style. (Though at least personally I am using way more functional patterns in rust than I expected)

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

#264

Post by ogogmad »

zozbot234 wrote: post #209
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).

This doesn't count because the idioms are very different from Go and Rust. And I suspect there's a high learning curve for features like Functors.

If you check the Wikipedia page for OCaml to find out where it gets used, you'll see why it's ocaML. That is, you'll notice that it's mostly a MetaLanguage, or a language for writing other languages. The same observation applies to other languages in the ML family.

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

#265

Post by sshine »

biorach wrote: post #210
zozbot234 wrote: post #191

Earlier quoted context omitted.

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

There is some DX similarity between checked exceptions and Result types.

Because the compiler will fail if you don't explicitly mention each possible exception.

But checked exceptions are coming out of style: They're unchecked in C#, and frameworks like Spring Boot in Java catch all checked exceptions and rethrow them as Spring Boot flavored unchecked ones.

For unchecked exceptions and Result types:

The DX is very different in one critical way:

With Results you constantly have to differentiate between error and ok states, before you proceed. With unchecked exceptions you generally assume you're always in an ok state. It's equivalent to wrapping your whole function body in 'try { ... } catch (Exception e)'. And you can get that with Result types in Rust by using '?' and not worry about doing something half-way.

Ultimately: Are you a happy-path programmer?

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

#266

Post by LinXitoW »

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…

Imho, most features of Rust that people would like to see in Go would still fit into the "concept" of Go. Just like they added generics, they could add just three things: A generic container for errors (Result), one for saner Nil handling (Optional) and a small sprinkling of syntax sugar to make these comfortable to work with (something like an elvis operator equivalent).

Go has the one big advantage that is almost solely responsible for it's success: It was created and directly used by a giant company that could afford to create amazing tooling around it and develop great opensource libraries for it. Already being in use and having libraries feel like the biggest determinants of a languages success.

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

#267

Post by CharlieDigital »

poilcn wrote: post #142
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.

Yup, common misconception for folks that haven't used it in a decade.

Our team uses C#. We dev on Apple silicon Macs. Some use Rider, others just use VS Code. We build on Linux via GitHub Actions. Ship to prod running AWS t4g Arm64 instances.

C# to me is like TypeScript++. The language, syntax, and core constructs are close enough that anyone with a good handle on JS and TS can pick it up easily and be productive.

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

#268

Post by mike_hearn »

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…

Well, I've also programmed for over thirty years and I wouldn't use a language without exceptions and even wrote a whole essay defending that position:

https://blog.plan99.net/what-s-wrong-with-exceptions-nothing...

> Even junior engineers have a trivial time debugging most go errors

Not my experience at all. I had to do this once. An HTTP request to a production server was yielding a 400 Bad Request with no useful information for what was bad about it. No problem, I'll check the logs and look at the source code. Useless: the server was written in Go and the logs had no information about where the error was originating. It was just getting propagated up via return codes and not logged properly. It ended up being faster to blackbox reverse engineer the server. In a language with exceptions there'd have been a stack trace that pinpointed exactly where the error originated, the story of how it was handled, and the story of how the program got there.

Diagnosing errors given stack traces is very easy. I've regularly diagnosed subtle bugs given just logs+stack trace and nothing else. I've also had to do the same for platforms that only have error codes that aren't Go (like Windows). It's much, much harder.

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

#269

Post by LinXitoW »

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 not simple, it's easy.

The difference, for example is: Go invents an abstraction just for one use case, and just for the standard library/runtime itself, instead of taking the time to create a universal version of that abstraction. Generics for maps and lists, and tuples for error handling.

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

#270

Post by CharlieDigital »

mjevans wrote: post #16

There _are_ two problems with Golang that I _would_ like to wave a magic wand and fix if that was a power I had. 1) Sum types (E.G. C/C++ union types) - Yeah, something similar to that should exist... it's syntax sugar over #2 2) 'casting' / reshaping perspective on data ; as long as something has the same struct size a programmer should be able to tell the compiler 'but this is actually that'. Which also implies a w…

I started learning Go and when I got to the chapter on slices is when I dropped it.

I can't put my finger on why it was so off-putting, but it just left a bad taste.

Post reply on HN