in my concern i could agree with everyone..... so it does not go anywhere, does it ?
Axel resumes it well. I d just add one notion, complexity to build the desired generator. Even though a great work has been made so golang compile in go, it is not an easy api to handle. So if go intends to reach a broader audience, compete on the field of dynamic language, well maybe, it is questionable to stay on the consensus that code gen is the way to go, even though there are has good reasons. I back this Q on this quote https://youtu.be/7VcArS4Wpqk?t=13m50s Then about the form of any evolution, this quote about sophistication talks by itself https://youtu.be/7VcArS4Wpqk?t=3m4s That being said, back to generics, from known implementation, it is not an option to put that in the language, but, so many times people want to parametrize the types. Also, in the first quote it says, to be as expressiveness and convenient as dynamic language, but, by design it can t, because all types representation available in the language are destructive. take this code type A struct{} func (a A) Hello(){} func (a A) Whatsup(){} type W interface{ Hello() } func sayHello(a W) W { a.Hello(); return a } func main(){ sayHello(A{}) } In a dynamic language, the type out of sayHello can be anything, including the input type. In that example, written in go1, it can be W or anything, but not the input type, the information has been destroyed at the func input signature. There s a duality of types in the value 'a', it is W (and A), when it enters sayHello, the signature used, reduces it to W and looses the original type. That prevents code re usability, because this example is fixable as long as i control the definition of sayHello (it is not imported from a remote repository i don t have hand on). If i don t, and this the case when you try to provide a re usable code, then i m stuck. In a dynamic language, as types are not defined, the idea of returning the type that was inputed without knowing it is *totally implicit*. // the return type is: whatever provided func sayHello(a) { a.Hello(); return a } // within the body i want to use a W This kind of ideas, and the lack of parametric type, participates to the situation where i can t totally, deeply, blindly agree to that: ... go provides the expressiveness and convenience of a dynamic typed interpreted language. ___________________ If that speaks to anyone else, this might be a way to represent the flat type hierarchy of golang, where moving a structs to an interface clearly states it is less, and even less when it is moved to interface{}, in contrary the type assertion permits to navigate the other way around. interface{}<interface<(structs|basic) anything<facet<concrete or maybe... interface{} < interface < (structs|basic) < <t> anything < facet < concrete < parametric On Sunday, August 27, 2017 at 5:21:30 PM UTC+2, Axel Wagner wrote: > > While having generics as part of the language and doing the code-gen in > the compiler has definite advantages (ease of use and potentially better > optimization of the generated code), doing it as a separate tool *also* > has advantages. For example, this way no one is bound to whatever notion of > generics will eventually be built into the language. Because it *will* > have limitations and provide a trade-off. With separate tooling outside the > language, people can make their own tradeoff. > > For example, yes, you can do template-like code generation at compile > time. But you could also box values in interface{} and have a tool that > verifies your desired notion of type-saftey statically. It's up to you - > whatever makes more sense for your use case. > > Honestly, right now I'd prefer good and easy to use meta-programming tools > for go. If I can write my own type-checks or code-gen to be run on a go > build, it enables far more powerful tools than generics alone… (yes, it > also has drawbacks. I'm aware). > > On Sun, Aug 27, 2017 at 5:08 PM, <prade...@gmail.com <javascript:>> wrote: > >> > That's how C++ started. >> >> And that's also why C++ is the ugly monster than it is today; with a >> design that wasn't quite thought thoroughly. Talking about C++ like it's an >> example to follow is just preposterous. >> >> Le dimanche 27 août 2017 16:25:54 UTC+2, Jan Mercl a écrit : >>> >>> And there's nothing wrong in it. That's how C++ started. Codegen allows >>> for easier protoyping throwaway experiments. Writing a full blown compiler >>> and realizing afterwards a better language/feature design costs probably >>> much more work. >>> >>> On Sun, Aug 27, 2017, 15:55 <prade...@gmail.com> wrote: >>> >>>> > Codegen can do 100% of what any compiler can do. >>>> >>>> Yes and it is called doing the compiler's job in place of it. >>>> >>>> -- >>>> 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...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >>> >>> -j >>> >> -- >> 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...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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.
