> Some time ago I collected a number of alternatives to using generics -
see: 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
>
> 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 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.
