i have not read this, 1. i do go because the type system is helping me, if i do js, i have no type system, so i have to figure this out by myself, its hard if i d be doing java, i d end up with complex giant scaled type hierarchy,
both cases, it d more a difficulty than an helper to my attempt to solve a real problem. 2. generics / not generics ? i d rather think in terms of *capability*. - i can t declare a func which returns the type it received, i feel like its a lack of basic capability. - i can t generalize easily / elegantly some algo, again this looks likes a basic functionality. should any of this be necessarily over complex, *i hope not*. should any existing implementation is the right one, i believe not, for as much as i know (not that much, true :), because they thought generics as a piece of software to integrate in a complex hierarchy of types (so they needed to parametrized their generics), they made generics in their ways of thinking. The day GO has found its way around those two difficulties *using **its way of thinking*, - how to let the runtime leaks into the static type system (dont pre emptively define the world, locally solves problems) - elegantly provide re usable algo (be DRY) it d be an awesome language to write. As a comparison, quickly i want to talk about php, before php4, there was not a type system, since php5 they implemented a type system with class hierarchy based on Java and co (so called "leaders"), IMHO, a total failure, php is no more php, its not java and co either, it became a bloat, years later, i think about it and wish they took their inspiration from the go language, they did not. Do i want GO to become java because "its a leader", really not please, i d rather keep go 1. 3. compile time worries I found it inadequate to worries yet about the compiler speed without a clear and meaningful change proposal. Also, i wonder if we are worrying about a compilation time with no-cache, or with a hot cache. Said as a question, is it a worry about 1% use case, or the 99% use cases ? The consequence would be, how to re think this worry with new metrics, thresholds, explanations ? On Friday, July 28, 2017 at 2:41:10 PM UTC+2, dogan...@dodobyte.com wrote: > > *Everything in this thread is my personal opinions, they are not > necessarily the truth.* > > My main language was C for a decade. I also liked Python. When i started > learning Go, it almost felt like i knew the language in another life. > Everything was so obvious. > > CSP model of concurrency was new to me though. Interfaces were more > familiar due to unix's open,close,read,write interface, which is the > greatest idea. > > I didn't use generics or templates much (it's kind of stupid for me to > talk about it's necessity), therefore this is more like a meta-research. > > - Go developers created a great standard library and many great software > without generics in the language. > - Many companies switched to Go from the languages that have generics in > it. > - A little copying is better than having a big feature in the language. > - Using generics everywhere is more of a design choice than a necessity. > > > *A language that doesn’t have everything is actually easier to program in > than some that do. (Dennis Ritchie).* > > I wrote many different types of software in C. A country wide (a big one) > server, two AV engines for two major AV companies etc. I needed generics > only few times, but i could handle it in C without using smart tricks. In > Go however, there are much safer, better and elegant solutions to achieve > the same results. Do we really need a big feature for it? > > I didn't hear a complaint about the lack of generics in Go from a C > programmer, although i'm sure there are. > Maybe java programmers use generics more than they are supposed to. Maybe > they should stop writing java in Go. I am confident that they would abuse > generics if Go had one. > > That brings me to my point. > > I believe that generics would divide the Go community. > > It's well known that everybody uses a subset of C++ language. Google > doesn't use exceptions for instance(afaik). I was unfortunate enough to use > C++ in my last company and i felt the pain. > > Rob Pike himself talked about it. > https://talks.golang.org/2012/splash.article (see 4. Pain points) > > Now Go is unique because people come to Go from all kind of different > languages, (javascript, Python, C,...). see > https://blog.golang.org/survey2016-results > > If Go 2 has a new fundamental feature like generics, many Go 2 programs > will look alien to Go 1 programmers. Some people will not use generics at > all while others overuse it. > > For a language like Go, this is disastrous because it's against Go's > philosophy. I love gofmt because it enforces a standart format and saves > our time of debating about indention and other things. What good it is to > have a standard format while you have completely different programming > styles. > > Dear Go experts; > > Please provide some best practices to achieve generic behavior for the > most common cases, instead of implementing Generics in Go. > > Let's end this debate and help keeping Go small and simple. It's the real > virtue of Go. > > Thanks. > > -- 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. For more options, visit https://groups.google.com/d/optout.
