Well said! +1 On Thursday, July 4, 2019 at 1:02:45 PM UTC+3, Slawomir Pryczek wrote: > > 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/5a9898a7-d662-4e17-ba2d-047322071636%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
