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.


On Thursday, July 4, 2019 at 6:02:45 AM UTC-4, 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/cc274c1b-99e6-45b1-bd2c-2270ce30ca17%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to