General thoughts about new proposals

[Slawomir Pryczek]

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 ;)

[Michael Ellis]

Well said, Slawomir. Your sentiments put me in mind of a favorite quote about writing prose.

Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all his sentences short, or that he avoid all detail and treat his subjects only in outline, but that every word tell.

-- Strunk & White, The Elements of Style

I've treasured that advice since I first encountered it more than 3 decades ago.  I've become enamored of Go because it embodies the same commonsense spirit. Let's not screw that up.

[jessie....@rococoglobaltech.com]

is there a hope for generics like this?

gen[A]ToStringer

gen[string].ToString()

Noong Huwebes, Hulyo 4, 2019 ng 6:02:45 PM UTC+8, si Slawomir Pryczek ay sumulat:

[Slawomir Pryczek]

Oh gosh, i'd rather call it a disaster :D You written something bigger in C++ or Java? If yes you really want to go back to all this mess, where you're not even sure what the "=" or ">" operator is doing? IMO this is totally unfit for code people are writing nowdays. You can no longer afford a luxury of having fragmented, unreadable code because codebases are huge and time to market is low.

Sure, it's little easier to write, then after a month when some small change is needed you realize it's better to write it all from 0.

[Space A.]

Well said! +1