4 ms·
It's very interesting to me how bad design decisions in Go are accepted by the users with little protest. There are other things - the Go path, error handling,
by papito 7y ago
It's very interesting to me how bad design decisions in Go are accepted by the users with little protest. There are other things - the Go path, error handling, surprising conventions in a language with no "magic", etc.
Yes, it was created by behemoths of computer science (but more accurately in this case, dinosaurs), and they clearly have not been writing and debugging large production systems for decades now. That's why the whole thing is clearly missing the lessons learned from modern language design.
- SEJeff 7y agoWell they did port dl.google.com from a very large C++ codebase to go. Do you have any apps you've worked on that are higher traffice than dl.google.com?
- papito 7y agoI didn't say Go is unusable - I said it's full of bad design decisions. Google has a LOT of people who are Go fanboys. It's their in-house language. Terraform is also written in Go, and even though I refer to it to see how they manage a larger Go codebase, my question is - "so"? This is my opinion from writing Go, I have no problems pointing out what I don't like, even though at Google, I am sure, it would be unforgivable blasphemy.
- azth 7y agoThat's not an argument. There are many websites that are higher traffic, yet written in slow languages like Ruby and Python.
- papito 7y agoGive me a fast language and I WILL find a way to achieve horrible performance.
- SEJeff 7y agoSure, instagram is a giant django app running ontop of many postgres databases. But I was pointing out that Go can be used for very large codebases running high traffic sites.
- papito 7y agoIt compiles to bytecode, of course it is fast - we are specifically discussing language features and developer experience.
- didip 7y agoThe only bad design I see is the missing generics. The path, modules, and error handlings are features to me, not drawbacks.
- papito 7y agoThe Go path is going away. This is being replaced by modules (the feature that I actually like a lot, especially the vendoring). The problem is, why did it take almost a decade for a modern language, at Google nonetheless, to get a proper dependency management feature? To me it says that the Go vetting process at Google is seriously constipated, perhaps because people there just say "this does not look right, but who am I to question the decisions of Rob Pike and Ken Thompson?". And then we end up with these language design decisions from the 1970s. And also, amazingly, error management in Go may have actually been made worse in 1.13: https://www.reddit.com/r/golang/comments/biexq0/go_113_xerrors https://www.reddit.com/r/golang/comments/biexq0/go_113_xerro...
- apta 7y ago> perhaps because people there just say "this does not look right, but who am I to question the decisions of Rob Pike and Ken Thompson?". And then we end up with these language design decisions from the 1970s. Yep. golang is one big appeal to authority fallacy at work.
- erik_seaberg 7y agoGoogle develops everything at #head of a monorepo, so their dependency management problems consist of “please rollback ASAP, your changelist broke the world”.