14 ms·
Good article! HN's reaction to Go reminds me of Stroustrup quote about C++: ..."There are only two kinds of languages: the ones people complain about and the
by eliben 12y ago
Good article!
HN's reaction to Go reminds me of Stroustrup quote about C++:
..."There are only two kinds of languages: the ones people complain about and the ones nobody uses"
So much complaining about how Go lacks this and that features of shiny new (and sometimes unfinished) language X. In the meantime, as time goes by it seems that more and more real companies use Go code in real production and are quite happy with it, despite all the shortcomings frequently listed here.
- deleted 12y ago[deleted]
- eudox 12y agoThanks for contributing to the gradual destruction of computer science.
- ecnahc515 12y agoGood thing production software deployment and maintenance has a much smaller focus on computer science theory than real world use cases. If all business decisions were based on pure computer science we might very well have much better software, but im inclined to believe we wouldn't have so many different and great products out in the world.
- pjmlp 12y agoNo, nowadays business decisions are taken where and what to offshore.
- emeraldd 12y agoThese are all considerations that should really be part of computer science in the first place. There's too much focus on the "Spherical Cow" part of writing software and not enough/any focus on how that software actually behaves at a modern scale/style of deployment. (At least in the curriculum I remember).
- eliben 12y agoHuh what? Care to elaborate?
- valarauca1 12y agoI'll take a swing. These aren't 'destroy computer science' worthy, but they are a MASSIVE step back in the development of languages. :.:.: Go lacks a lot of basic functionality a lot of other languages take for granted. I.E.: In Rust you can type fn id<T> ( item:T) -> T { return item; } And you assign the type to the function. This is possible in Go by double casting the type. Which is really messy, and what java did in 2004 for generic functions (and was ultimately useless). :.:.: Lets say you want to iterate over a array in say java. for(byte a: bytes[] { x += a; } This also doesn't exist in Go. Yet does in python, java, and several others thanks to iterators. :.:.: Lets say I'm adding vectors and dark magic has told me to use '-' for the dot product. In most languages (Rust, C, C++, Haskell) this is completely possible, as - is just a function. __subtract__() in rust. You can't in Go. :.:.: Now lets talk about pointers. When you want to signify data doesn't exist in Go you pass a null pointer (nil, 0x0). This is wrong on almost every single level. Your not only creating a back door, but your by passing your entire type system. The only thing that stops this from being common practice is that Go has such good message handling, but it still exists! Why?! :.:.: Immutable variables, data structures, etc. are a thing of beauty. In Rust and Haskell all values are immutable by default, but most languages (C, C++, Java) let you delcare variables, data structures, etc. as immutable.... Go doesn't. :.:.: Go has no support for turning off compiler safety features. Much like Rust offers the unsafe{ ... } tag for isolating code that may do strange things, go doesn't. :.:.: TL;DR Go doesn't do anything new. Actually it takes a step back.
- NateDad 12y agoNot sure why you think you can't iterate over an array in go: for _, a := bytes { x += a } No there's no generics. I rarely need generics. Usually I need a specific, and waste time making a genetic. No there's no operator overloading, and thank god. + is numeric add, I never have to wonder if + might be some crazy O(n^2) function. Yes, that makes go bad for Matt and science code. That's ok, go is not for every application. Go has unsafe and reflection, it is just discouraged strongly. Yes, nil exists. Big deal. You know how often I've seen nil pine exceptions in a year of writing go full time? Once. Because go has multiple returns and you never look at the pointer before checking the error. No there's no immutable data structures.... And I've never missed them. You can approximate them with interfaces with only getter methods, but it's rarely worth the effort.
- dscrd 12y agoIf a theoretically weaker programming language is able to destroy computer science, it deserves to be destroyed. (It isn't of course)
- wyager 12y agoThere are also languages that are frequently used, infrequently complained about, and reasonably well designed (like C). I think Stroustrup has an emotional interest in thinking otherwise.
- tptacek 12y agoI'm not sure it's reasonable to say that C is infrequently complained about. I think it's more likely that we've just internalized the complaints about C, and that they now go without saying. (C is my favorite language, for whatever it's worth).
- sillysaurus3 12y agoWhy's C your favorite language? It's mine too; it'd just be interesting to hear your thoughts on it.
- eliben 12y agoC is infrequently complained about? Seriously? The thing with C is, it's been around for >40 years, so all complains have already been rehashed to oblivion. Dozens of "C replacement" languages developed since then stand as a witness to this. I find some philosophy of C and Go similar, BTW. Minimalism is an art.
- deleted 12y ago[deleted]
- kvb 12y agoIt seems like Go is reasonably well designed given its creators' goals, and many people like it, which is great. But I think you're being unfair to (some) critics. It's not that Go is missing "shiny new" features - Go is missing features that have been established for a very long time; generics and sum types have been around for decades and have been proven to work. And to your last sentence, use in production is not a good measure of language quality (except in a tautological sense), because many non-technical factors strongly affect popularity.
- tormeh 12y agoYeah, but the point of Go is to be minimal and easy. Basically, this makes it really hard to be clever. In both senses, unfortunately, but I see how it can be a net win for big projects.
- kvb 12y agoI think that's perfectly fine, though it's not my cup of tea (and I doubt that empirical evidence would show that Go's particular set of features maximizes "big project" maintainability, though such an experiment is sadly impossible to arrange). And I think that the point, "Critics focus on missing features, but Go's philosophy is to be minimal" is definitely valid. But, "Critics focus on how Go is missing shiny new features (that may not even be fully implemented)" is definitely not true (of most critics). Most people aren't complaining that Go doesn't support dependent types, or row polymorphism, or cutting edge technologies. They're complaining that Go doesn't even reflect the state-of-the-art of 30 years ago.
- NateDad 12y agoThere are a ton of anti features that have been introduced in the last 30 years. Things that are clever but make your code harder to understand and harder to maintain. Many of these are things people like, but have proven to be somewhere between not useful and a nightmare.
- 12y ago