4 ms·
This is really getting a bit overheated. I think I understand where the Go team is coming from, but there is so much hype from other quarters that I think is a
by jeremyjh 14y ago
This is really getting a bit overheated.
I think I understand where the Go team is coming from, but there is so much hype from other quarters that I think is at best premature.
I think Go will be a fantastic alternative to C for "systems" programming, once it matures. I think this was one of its most immediate original goals, but really it is not yet ready to do even that. Two main reasons it is not ready for that is that performance is not yet there though I think it will get there; second reason is that it has no support for dynamic linking or code loading. You can't write something like Apache, or even Nagios in a platform that has no support for loadable modules. Still I think there are LOTS of applications where these constraints would not be an issue.
So then we have all this hype and people doing things like building web applications in Go and calling it the next Node.js or Ruby or Python and frankly this is just stupid. Despite some claims it has nowhere near the expressive power of those languages. It is statically typed but has no Generics - and there are quite a few use cases where there is no answer(https://groups.google.com/forum/#!topic/golang-nuts/PYJayE50JZg[1-25] https://groups.google.com/forum/#!topic/golang-nuts/PYJayE50...) and you will just have duplicate code.
It polymorphism but no inheritance - and the way interfaces and composition works while still fairly powerful is not at all what an OO programmer would expect(http://xampl.com/so/category/software/golang/ http://xampl.com/so/category/software/golang/) just naively reading about this feature. Whatever you want to say about the benefits of simplicity, this is LESS powerful than any OO dynamic language. Go's closures are nice, but aside from that on what basis can any other claims be made about its expressive power?
In fact, the language is intentionally very, very limited. They want large teams of mediocre programmers [1] to produce code that is very supportable. Everytime someone in the lists brings up a "why don't we have" question all the answers revolve around this premise, that the language becomes "too complicated" if you have crazy features like generics. So it seems Go is optimized to satisfy the angst of systems programmers who have to work on C code that is thirty years old and been maintained by dozens of people. I get it, but that doesn't mean its really a good language for hackers to use to build the latest social network for people who like cats.
Ok so concurrency. Yes Goroutines are smart. Channels are smart. These are great features. Scala can do the same thing (and more elegantly) with it's Actor constructs. The same thing can probably be done in other languages such as Ruby (https://github.com/igrigorik/agent https://github.com/igrigorik/agent). Its nice that this feature is in Go from the beginning, but its going to make its way into other platforms as well.
Performance. Well...lots of blog articles just keep repeating the mantra of "native code" as though it automatically means something. It doesn't. C isn't just fast because it generates native code, it is fast because it's compiler has been optimized for decades. Go doesn't have that today. In fact today, Go is slower than Java and Scala based on both Google's benchmarks (http://www.readwriteweb.com/hack/2011/06/cpp-go-java-scala-performance-benchmark.php http://www.readwriteweb.com/hack/2011/06/cpp-go-java-scala-p...) and the language shootout (http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php http://shootout.alioth.debian.org/u32/which-programming-lang...). Go will get there almost certainly, or at least very close, but it isn't there today.
Today if you want a static, fast language with good concurrency and an incredible standard library and extended library ecosystem then you want Scala I think. If you want a powerful, expressive language for quickly building web applications then you want Python, Ruby[2] or Node.js or similar. If you want a language is actually very fast and with incredible libraries you want C/C++.
I really do not hate Go. But it is not yet ready to replace hardly anything in my opinion.
edit:
[1]You are right. The "mediocre programmer" comment is really out of line and a major distraction. I guess I actually think this IS a feature of Go: more maintainable code than C/C++ from mediocre developers. I'm bitter and tired ofdebugging twenty-year old C programs and I wish they were all written in Go. I shouldn't read that into Thompson's or Pike's intentions though.
[2]May brain stopped working here - I meant Ruby not Java.
- pkieltyka 14y agoshabam! well put.
- batista 14y ago>It is statically typed but has no Generics But, as Go advocates will tell you any Generics related discussion in the golang list: "just try programming in Go for a while and you'll find you don't need Generics". Why do they assume that people complaining haven't used the language "enough", is beyond me. Plus it seems they believe that there is some amount of time of using a language, after which fundamental issues and well understood design issues disappear... But, by that logic, why abandon C in the first place? "Just use C long enough, and you'll find out you don't need garbage collection, built-in collections, closures and memory safety". Or: "Just use assembly long enough, and you'll find out you don't need all those fancy functions, and variables, and looping constructs, and stuff".
- jeremyjh 14y agoYes exactly. Although I think with Generics they will probably come around at some point. If you read the link I posted they do recognized there are unsolved cases without Generics and while some people DO say "just rewrite your collections over and over when you can't use maps/slices", others recognize that this will lead to redundant code which is not something you want in a language touted for its maintainability. Other problems though such as default function parameters are less likely to be addressed (it seems to me). This is a problem because it means lots of code will be written in which there are implicit defaults (just pass 0!) that are not well-understood or guaranteed by the interface. The answer there is "just write another method with a different name and parameters". Ok so now I have to think of sensible names for the methods that are exactly the same as another method except they apply defaults...and write and maintain more code of course - especially if its in an interface you re-use.
- EdiX 14y ago> Other problems though such as default function parameters are less likely to be addressed (it seems to me). It's unlikely to be addressed given that Google style guide forbids using default function parameters even in C++. > This is a problem because it means lots of code will be written in which there are implicit defaults (just pass 0!) "Just pass 0" is not a good way to implement defaults.