I agree, I've used Go before I learned Rust and seeing the differences really changed my mind. I used to use OCaml before so I understood the value of Option and Result types over try/catch and `nil`, but I used Go because it was easy. However, that easiness comes at a cost, namely maintenance over time. You want to get it right the first time around and not have to face challenges later on.
Not to be flippant, but I've often heard Go described as taking the programming language advances over the last 50 years and throwing them away.
> but I've often heard Go described as taking the programming language advances over the last 50 years and throwing them away.
That's by design, right? Go is very opinionated. They looked at other languages that they hated, e.g., C++/Java and didn't want to replicate them. But then adding their own mistakes along the way.
The brand new mistake that surprised me was that nil does not always equal nil. So just checking for nil is not enough sometimes, one has to "cast" as nil to the type you're expecting. And goland doesn't catch it. C++/Java/Python/C, null always equals null. But not in golang. shrug
The primary issue I have is that go doesn't make it very easy to write unit tests. You have to use interfaces everywhere just to inject your mocks.
I feel like that's the big mistake they made. Any new language needs to make it super easy to write unit tests without forcing major design decisions that affects development.
> That's by design, right? Go is very opinionated. They looked at other languages that they hated, e.g., C++/Java and didn't want to replicate them.
It’s a pity there’s no other languages in the world that they could have taken good design from, rather than looking at a handful of languages they didn’t like and basically throwing the baby out with the bath water.
I've always thought the best languages were just a step up from another language.
C with garbage collection that compiled natively and had a sane FFI to C would be a good addition. Add a decent library to get work done quickly and you've got a great solution.
That's what it felt like golang was trying to do. I do think it's easier to pick up than C. But it's not something I would say, you must write your code in.
People have raised dozens of issues on the Go tracker because they got stumped by this. You don't really need to look hard on a search engine to see thousands of questions/issues.
If you don't believe me, take a project like k8s and starting from its inception, you can see dozens of issues where people have to explain function returns a nil interface and not a nil value. This is explained a stupendous number of times.
Now repeat this for thousands of Go projects.
Of-course you can claim this is not an issue in the same way that anyone can claim that buffer overflows are not an issue in C/C++ for "real" programmers.
I see people say that they're confused by it a lot, sure. But do the bugs get to production? That was my question. Buffer overflows get to production all the time! But do the concrete vs interface nils get to production or are they caught in dev and then someone opens an issue to ask why it doesn't work? I suspect it's more the later.
Obviously, it would be better if Go didn't have this problem. If I made Go 2, it would have blank interface be "none" and blank pointer be "null". Even better, I would add a reference type that can't be null and sum types or something like that. But these things are all relative.
In Python, people using "is" for numbers is a problem. But in practice only very junior developers do that and it mostly gets caught in dev. There was the Digg outage caused by a default argument being [] instead of None https://lethain.com/digg-v4/ and that I see as a slightly more serious bug that can slip by without good code review.
Every language has pitfalls and the question is whether they outweigh the other benefits.
> But do the bugs get to production? That was my question.
Yes, in my case anyway. That code didn't have any unit tests around it. Goland didn't flag it. It's a pattern that was "surprising" to me at least. Particularly since it breaks with tradition.
I consider Goland to be invaluable when coding go. But still, it's not perfect.
> There was the Digg outage caused by a default argument being [] instead of None
FWIW Pycharm flags this now, and can fix this automatically. Not sure about VSCode.
I guess the point I'm making is IDE's should find the novice mistakes, and then a lot of my complaints about languages go away.
Yep. Every now and again I look into contemporary Go and try to give it the benefit of the doubt, but it just looks like intentionally going back to Java 5 [1] and touting the lack of features as a feature. What I find surprising is its apparent popularity among people who also like languages like Typescript and Kotlin, which go in the opposite direction, with high expressibility
To be more controversial, its flaws remind me of COBOL, both in the flawed belief that a lack of expressive power makes your programs easier, rather then harder, to read, and in the sense that both languages seemed completely ignorant of any programming language design ideas outside of their bubble, and just stayed stuck in the past
[1] As of 2022. Prior to that it famously didn't even have generics
Not to be flippant, but I've often heard Go described as taking the programming language advances over the last 50 years and throwing them away.