I second this. Linear Algebra code would dramatically benefit from generics. Code would become much more simpler if you could write Tensor and Matrix code independent of the type of the numeric values used by those types. Practical applications are graphics libraries, geography applications and machine learning.
Note also that access through interfaces is always slow. Depending on the way generics will be implemented, there could be huge performance benefits. Imagine sort code would not need to call a function for every element swap and comparison function. Sorting is a very practical application. I agree with the original poster that there is a risk that generics will lead some folks to overuse the concept impacting the readability of the language. An advantage of Go right now is, that most of the problems have to be reduced to slices or maps. Generics could immediately lead to mushrooming of badly designed container types addressing minor concerns. In other languages generics are used for error return values. A lot will depend how Generics are introduced in the standard library. I would recommend a conservative approach. Extend or replace the current container types first and faster sorting for slices. Generics for errors, all kinds of asynchronous shenanigans should be introduced after those new methods have been battle-tested outside of the standard library to filter bad approaches from the good ones. On Thursday, December 24, 2020 at 11:21:10 AM UTC+1 kortschak wrote: > I agree. > > A lot of Gonum code would be greatly simplified with the availability > of generics, particularly the linear algebra part. The graph packages > would be richer and we could do more things with tensor-like > operations. > > On Wed, 2020-12-23 at 23:54 -0800, Marcin Romaszewicz wrote: > > Those are simple examples of real world problems. I've been writing > > Go since the very beginning, having worked at Google when it was > > released and since I enjoy the language so much, I try to write all > > the backend server code in Go that I can. In these years, I've had to > > write many code generators to make my life a little easier, and they > > tend to be for data structures or API models. > > > > Generics would allow for writing less code, and re-using it more. As > > long as it doesn't complicate the base language, why not? You don't > > have to use them :) > > > > On Wed, Dec 23, 2020 at 11:18 PM Martin Hanson < > > greenco...@yandex.com> wrote: > > > I'm sorry, but this is not real life problems. This is exactly the > > > problem with this proposal. It's based on nothing but small > > > theoretical examples. > > > > > > > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3dc07ed3-8587-4b9b-a68b-e5e7abaabd0an%40googlegroups.com.
