Following this group for couple years and I think that from some time the community is in some kind of crisis, because it seems that go1 is so good that there's a lack of some feature which will distinct go1 from go2, so everyone's trying to invent some code breaking change which will "distinct" 1 from 2 just for the sake of breaking backward-compatibility. There are no real issues with language design, so people seems to be "inventing" problems ;)
So we're having a flood of different specs, which are trying to "fix" something that's not broken by adding needless complexity or adding a "feature" from C or Java which is more complicated than the whole go1 when we look at it for more than 2 minutes. And go1 is so good it seems so easy to introduce couple of very bad ideas into the language because in the end it'll still looks nice. Generics, operator overloading, memory ownership, try-catch, precalculated functions, and the list could go on-and-on. There's C++, everyone's favourite "missing feature" is already there ... probably that's why it's such a delight to write anything in it with >1 person in team ;) And if you "just" miss try/catch and generics it's called java. So much effor went into making go simple to read and develop, and to remove all "dust" which C++ gathered over the years, now I think so much thinking goes into bringing it all back. I think when creating specs people are totally missing the point... we thankfully don't have to deal with overloading or 3 different kind of for-loops so we can focus on algorithms because code is easy to read. Since when replacing 3 different loop keywords for 3 different conditional keywords plus adding code fragmentation sounds like a good idea? So when reading single line, we'll have to check specs and maybe 4 other places in the file to be kind-of-sure what it does, like it happens in C++, just to save a newline... It's really not about the specs, but the amount of support every change usually gets, seems just for the sake of changing something. I'm afraid some of these could be introduced, and the language will be going towards becoming some kind of bad c++ clone. And we could end up with something even as bad and unstable as node-js very quickly, because it seems that currently google is the only force which keeps potential feature creep in check. Really surprising how fast people forgot how horrible try/catch or generics are. And (especially for generics and overloading) - how unreadable and unmaintainable code using it really is. For sure there's room for improvement by inventing some new ways of doing things... not forcefully porting bad, decades old, error prone "ways of thinking" from C'ish languages, so we can spare a newline here and there or avoid typing 3 chars... So just my 2c for keeping simplicity. And if go2 can compile go1 code without changes, that's actually a feature not a "problem" and anyone can create overly complicated system, so yes simplicity isn't a "problem" as well ;) -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/5048648f-0c00-49dd-ab7d-f0b1f95ad3f8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
