While I have over 50 years of programming experience, I am also quite old and sometimes have senile moments.
I once wrote an extremely well-written bug report complaining about the use of the backtick which is not on my keyboard, explained why it should not be used, and then presented a workaround involving ANSI escape codes to enter the character which was not on the keyboard. The response was immediate and quite positive as everyone thought it was a marvelous satire on newbies who suggest language changes without understanding Go first. However, my eldest son Daniel, called me on the phone to remind me that the backtick was in fact on my keyboard just below the ESC key. He also asked me not to comment on Go-nuts on a bad day. Anyone who does not like a Go syntax can do what I do, I write my code the way that I write code in Davsk, then I compile/refactor that into Go code. I have enum, ternary, generics, whatever I want but the implementation is in Go. I am someone who does not believe in writing a lot of code, I prefer to do a domain-specific definition of a problem and then compile my definition into implementation, and the implementation in Go is performant and adequate. The disadvantage of my approach is that I am using the same high-level language I used 40 years ago. Great for me, bad for everyone else. The Go2 preprocessor that lets you test generics syntax is precisely the kind of solution that I approve of, but we cannot have a plethora of standards or we lose readability. GOFMT was a godsend for standardization even if I did not agree with all of the decisions, someone had to make the decision and then the decision had to be enforced. I need for Go to remain standard and unchanging, fast when compiling and linking, fast when running, small footprint, cross-platform, not because I use it to write my programs, but because I use it to compile my programs which some else who does understand go will be able to comprehend. The generic proposal with a plethora of ()()() resulted in a stack overflow for my parser which is implemented in wetware, my eyes saw it all but with or without spaces, just not intuitive in my brain, it lacks readability. Code is written once, read many I prefer the Clojure method of handling generics, I do not mind <>, not sure about [], gen keyword is a favorite for me. I can adapt to whatever the community decides. Error handling can certainly be cleaner but what we have so very versatile, I would hate it if you broke my old libraries. "Maybe the ONLY allowed issues going forward should be experience reports and clear identification of problems/pain points (which have always been requested but are probably the minority of user contributions?), and maybe some process for community input/voting for how significant those issues are (as Max suggested)." I am totally in favor of the Go team making the final decisions, they have my respect and trust. But of course, the real final decision is made in the marketplace by the developers who choose to use or not use the language. On Saturday, July 18, 2020 at 4:05:18 PM UTC-5 Randall Oreilly wrote: > > > On Jul 16, 2020, at 3:35 PM, Ian Lance Taylor <ia...@golang.org> wrote: > > > > The language is stable and is not looking to change in any > > significant way (except perhaps for adding generics). We've realized > > that we need to be upfront about that. > > The Go2 process certainly created the expectation that the language was > looking to change. But I guess the point here is that this window is now > closing? Maybe it would be good to have a new blog post to that effect? > > Expectation management is very important -- if we all recognize and accept > that Go is a fixed language that will never change, then nobody will be > disappointed when it doesn't! > > And why should it change? This idea that languages should constantly be > evolving may not make any sense: once a language is Turing complete, and > highly effective, supporting millions of happy, productive coders, it could > just be done. People can invest time and energy in writing code and tools, > not changing the language. > > I guess the only two major pain points that are widely discussed are > generics and error handling, and it looks like we'll get a good solution > for the first, and who knows about the second at this point? > > Maybe the ONLY allowed issues going forward should be experience reports > and clear identification of problems / pain points (which have always been > requested, but are probably the minority of user contributions?), and maybe > some process for community input / voting for how significant those issues > are (as Max suggested). > > - Randy > > > > -- 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/4ba17bea-3c2b-4f34-844b-72d9eeb006can%40googlegroups.com.
