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

101–110 of 526 posts

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

#101

Post by nulld3v »

richbell wrote: post #75
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...

I wish the discourse that Go is a "simple" language would die. Despite its veneer, once you start writing Go it quickly becomes apparent that it isn't simple. Hidden complexity and footguns are abundant (e.g., https://archive.ph/WcyF4 ). It's nevertheless a useful language, and I use it quite a bit, but it's not "simple".

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 embedded struct is fulfilling the inner interface?

- When should I pass by value and when should I pass by reference? Like I generally know when to choose which, but do I really know without performing a benchmark? And what about arrays? Should I store pointers in them? But it also seems that people just don't care and just randomly roll the dice on when to return a pointer or a value?

- Shorthand variable declaration. How does it work when you shorthand declare two variables but one of them already exists?

Don't both answering the questions, that's not the problem. The problem is that it's just not intuitive enough such that I'm confident I know the correct answer.

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

#102

Post by KingOfCoders »

richbell wrote: post #75
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...

I wish the discourse that Go is a "simple" language would die. Despite its veneer, once you start writing Go it quickly becomes apparent that it isn't simple. Hidden complexity and footguns are abundant (e.g., https://archive.ph/WcyF4 ). It's nevertheless a useful language, and I use it quite a bit, but it's not "simple".

Yes, like "Opening Brace Can't Be Placed on a Separate Line" (from your link).

Everyone can read Go code and understand what happens. There are some minor difficulties like func (*A) vs func (A).,

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

#103

Post by jchw »

pif wrote: post #44
vasco wrote: post #33

Earlier quoted context omitted.

"Manager imposes it on you" just means you work in a team rather than alone. You can pick whatever you like for side projects, of course you're going to use whatever your team uses otherwise.

[flagged]

> People tend to forget that Golang was created on purpose for poor programmers.

Nobody is forgetting that quote. Trust me, it has been repeated a lot[1].

That said, I think this framing of the issue really needs to die. Rob Pike is saying they're "not researchers", that they're "typically fairly young", not that they're poor programmers. Notice that in the list of languages they may have learned, "C or C++" is present. The idea is not that Go is designed for people who can't possibly write C++.

This framing also implies that the language being better for n00bs means that it's also necessarily worse for everyone else. There are some tradeoffs where this is a defensible position, but I think on the whole it's just not generally true. A good example is preferring composition over inheritance: I think the former is generally more understandable and a lot of people actually contort C++ to use it this way too. (For example, in some codebases, only pure abstract base classes are ever inherited; everything else is final.)

When I see this quote repeated as if it implies that Go is just generally designed for bad programmers, I feel like it reads like flamebait. The real answer is that it was designed to be so easy that any idiot can use it. Or in other words, Go is very grug-brained[2].

To each their own, but it's been over 10 years since that quote and Go has evolved a lot. Is it perhaps time to put it to rest and stop reading into it so much?

[1]: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu... - though I'm sure it has been paraphrased and linked even more than this.

[2]: https://grugbrain.dev/

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

#104

Post by RandomThoughts3 »

The article is arguing that Rust is a better choice which is laughable. Go is a small GC-ed language. Rust is an obnoxiously complex language with strong emphasis on memory management. I don’t see any projects where you could legitimately hesitate between the two.

Truth be told I quite like Go. It’s small and simple. It does the job. You can onboard people on it quickly and in practice with the toolchain you don’t run into the issue mentioned.

Would I rather use Ocaml most of time? Of course but it doesn’t have the same ecosystem. Would I rather use Rust? Heck no, I’m not going to deal with the borrow checker and life cycles if a GC is fine.

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

#105

Post by quotemstr »

pyrale wrote: post #66
abtinf wrote: post #25

Earlier quoted context omitted.

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…

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 program and one with exceptions except the Result program being syntactically noisy and full of footguns?

Better for a language to be exceptional from the start. Most code can fail, so fallibility should be the default. The proper response to failure is usually propagating it up the stack, so that should be the default too.

What do you get? Exceptions.

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

#106

Post by orwin »

masklinn wrote: post #82
DanielHB wrote: post #62

Earlier quoted context omitted.

You hit the main gripe I have with Go, its types system is so basic. I get people raving type-correctness of Go when they come from Python but the type system in Go is simply pre-historic by modern day standards.

Go’s type system is not even impressive compared to python’s .

Do you have a pydantic equivalent in go? Also modern typing in python is starting to be OK to be honest (well, if you consider typescript typing OK), so it isn't really a knock on Go :)

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

#107

Post by jchw »

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…

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 capacity and that capacity was usually growing because it was working for them.

Will you regret choosing Go? Maybe. Or, maybe not.

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

#108

Post by quotemstr »

koito17 wrote: post #34
troupo wrote: post #12

Earlier quoted context omitted.

It's actually very rare that it should be the caller who has to handle the errors. Go, however, forces you to spread your error handling over a thousand little pieces with zero overview or control of what's happening. Rust eventually realised this and introduced try! and ? to simplify this

More importantly, Rust has the notion of a result type and it is designed to be both generic and composable. A problem I often face in Go and TypeScript code is code that ignores errors, often unintentionally. For instance, many uses of JSON.parse in TypeScript do not check for the SyntaxError that may be thrown. In Go, it is common to see patterns like _ := foo.Bar() // assume Bar() returns error This pattern exists…

Why would you "check" for TypeError being thrown? Just let exceptions in general propagate until they reach one of the few places in the program that can log, display, crash, or otherwise handle an exception. No need to "check" anything at call sites.

90% of the criticism of exceptions I see comes from the bizarre and mistaken idea that every call needs to be wrapped in a try block and every possible error mentioned.

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

#109

Post by surgical_fire »

forrestthewoods wrote: post #18
afiodorov wrote: post #14

Not sure why Go is compared to Rust all the time, whilst most appropriate comparison is Java.

Because someone decides what language to write a new thing in is very likely to consider Go and Rust. They are very unlikely to consider Java. Are Rust and Go sufficiently different that they should each be chosen in different cases? Sure! But that’s literally why someone would consider both and pick one.

> They are very unlikely to consider Java.

Except they are not unlikely to consider Java.

It's a language with a very robust ecosystem, it is relatively easy to hire Java developers, and a decent job for large, complex projects.

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

#110

Post by poulpy123 »

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 remember and to type with a non qwerty keyboards (plus other unrelated pain points). For the different lisp, it was the parenthesis and the reverse polish notation. But for Go, I'm unable to rationalize why I don't like it.

For the anecdote, I settled on compiling my python code with nuitka. No speed gain that I'm aware of but I can now provides a binary. I'm also looking more and more at C# because of its progressing AOT compilation and although I dislike the verbosity of its base mode and the fact it's so tied to windows.

I liked a lot nim and crystal but the small community was a barrier, although I'm really impressed by what nim is managing to do with such a small community and it may me think it's an excellent language

(I will try to motivate myself to pick up one of the language I mentionned above also)

Post reply on HN