I love playing with package reflect, which is much more powerful than
generics by the way (you can't implement gob or json with generics).
You could absolutely do that without runtime reflection. It is called
compile time type safe macros ... Oh wait, Rust has them, and generics and
a correct implementation of method polymorphism...
Le samedi 29 juillet 2017 15:44:26 UTC+2, Roberto Zanotto a écrit :
>
> I love playing with package reflect, which is much more powerful than
> generics by the way (you can't implement gob or json with generics).
>
> On Saturday, July 29, 2017 at 3:28:56 PM UTC+2, M P r a d e s wrote:
>>
>> What is overrated is the use of "interface { }" and reflection AKA
>> runtime magics which has no place in a modern statically typed language.
>> It's a cop-out, it's dirty and a direct consequence of the absence of
>> generics in Go.
>>
>> > Please provide some best practices to achieve generic behavior for the
>> most common cases, instead of implementing Generics in Go.
>>
>> You cannot achieve generic behavior without some form of generics. Look
>> at sync.Map it's not compile time type safe. With generics it would be.
>>
>>
>>
>> Le vendredi 28 juillet 2017 14:41:10 UTC+2, dogan...@dodobyte.com a
>> écrit :
>>>
>>> *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.
