> None of these alternatives really solve any real problem generics would solve.
True, and the article does not mean to imply this. But often it would seem that there is no alternative to using generics for solving a given problem although there is one if you look close enough. Of course this depends on the nature of the problem to solve, and I am far from saying that generics are superfluous. > It's not being blind to another solution, Sometimes it is. > every other solution has drawbacks generics don't have. Generics have drawbacks, too. It’s always about pros and cons, there is no ideal approach. > But let's not pretend than there is an alternative to generics "people can't > see" within Go. The alternatives are there, depending on the problem to solve. Agreed, there are domains where the alternatives are cumbersome to implement, use, and/or maintain, but it is not true that there are no other options. > Let's not patronize people who see the obvious flaw in that logic. If anything I wrote came across as patronizing, then I apologize. I only try to help people by pointing out other approaches. If someone is new to the language, they might not yet have heard of the techniques I listed in the article. > people coming from Java, C# or Haskell will have harder time working around > the lack of generics in Go because they are used to that feature to solve > their problems. That’s the point. Asking why Go does not have feature X of language Y is pointless because Go is not language Y. Every language is the result of a series of design decisions, and so is Go. > To the latter I'd say that if Go feels tedious for a task then use something > else, really. Absolutely. I see we’re on the same page here. To add some other aspects to the discussion, in a recent talk, William Kennedy shares some very interesting thoughts about Generics: https://www.youtube.com/watch?v=7YcLIbG1ekM&feature=youtu.be&t=49m29s <https://www.youtube.com/watch?v=7YcLIbG1ekM&feature=youtu.be&t=49m29s> (This link starts at minute 49:29 - ensure to watch at least past minute 54.) > Am 14.01.2017 um 12:27 schrieb paraiso.m...@gmail.com: > > > Some time ago I collected a number of alternatives to using generics - > > see: https://appliedgo.net/generics <https://appliedgo.net/generics> > > None of these alternatives really solve any real problem generics would > solve. Generics are types, just like first class functions. Lamenting on the > lack on generics is useless as well, Go will never have generics because of > forward compatibility. > > But let's not pretend than there is an alternative to generics "people can't > see" within Go. Go just wasn't built for code re-use in mind or writing > abstractions at all due to the lack of polymorphism in the language. So > people have to write specialized code when it comes to writing logic > involving containers, that's the only truth there is. > > > If you have a particular problem and you think, "I do need generics to > > implement that!", then you might become blind for other solutions. > > It's not being blind to another solution, every other solution has drawbacks > generics don't have. Code generation involve writing pre-processors and > maintaining manifests, opting out of Go type system with interface{} > everywhere is obviously problematic. That's not solving what generics are > here for in languages such as Java C# or Haskell. Basically you are asking > developers to pay a price the compiler doesn't want to pay. Let's not > patronize people who see the obvious flaw in that logic. > > Again while it is useless to complain, people are complaining for a good > reason, it can be difficult to understand what led to the absence of generics > at first place in Go design. People coming from C,Python,Javascript and Ruby > might not care, people coming from Java, C# or Haskell will have harder time > working around the lack of generics in Go because they are used to that > feature to solve their problems. > > To the latter I'd say that if Go feels tedious for a task then use something > else, really. Go wasn't designed to please people who like expressive static > type systems. There are many alternatives such as D, Ocaml, ... > > Le samedi 14 janvier 2017 10:35:33 UTC+1, Christoph Berger a écrit : > Hi Yu, > > Generics have their use cases, e.g. when designing general data containers or > in the context of numeric computation (matrix type of int, float, etc). In > other areas, however, their use may be overrated. > > If you have a particular problem and you think, "I do need generics to > implement that!", then you might become blind for other solutions. > > Some time ago I collected a number of alternatives to using generics - see: > https://appliedgo.net/generics <https://appliedgo.net/generics> > > Best, > Christoph > > > On Saturday, January 14, 2017 at 7:42:43 AM UTC+1, Yu Liu wrote: > Agree. > > Only generics missing is disadvantage of Go. > > Yu > > On Friday, January 13, 2017 at 10:56:07 AM UTC-8, simon place wrote: > sorry but for me, excepting generics and maybe a float32 maths lib, these are > all just your problem. > > particularly wrong is the idea of native conversion of bools to/from numbers, > albeit widespread and long-standing, perpetuating these mistakes just means > preventing any development of languages. > > -- > You received this message because you are subscribed to a topic in the Google > Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/AcUcEIOUfh8/unsubscribe > <https://groups.google.com/d/topic/golang-nuts/AcUcEIOUfh8/unsubscribe>. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <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.
