πŸ‡ΊπŸ‡¦ Go performance channel
1.5K subscribers
39 photos
401 links
Go performance, runtime, concurrency.

Talks, blogposts and open source projects for gophers.

Not affiliated with Go team.

https://go-perf.dev

(mail: [email protected] / @olegkovalov)
Download Telegram
Forwarded from Daniel Lemire's blog
Go generics are not bad

When programming, we often need to write β€˜generic’ functions where the exact data type is not important. For example, you might want to write a simple function that sums up numbers. Go lacked this notion until recently, but it was recently added (as of version 1.18). So I took it out for a spin. In Java, generics work well enough as long as you need β€œgeneric” containers (arrays, maps), and as long as stick with functional idioms. But Java will not let me code the way I would prefer. Here is how I would write a function that sums up numbers: int sum(int[] v) { int summer = 0; for(int k = 0; k < v.length; k++) { summer += v[k]; } return summer; } What if I need to support various number types? Then I would like to write the following generic function, but Java won’t let me. // this Java code won't compile static T sum(T[] v) { T summer = 0; for(int k = 0; k < v.length; k++) { summer += v[k]; }…

https://lemire.me/blog/2022/07/08/go-generics-are-not-bad/
> We’re all agreed that we want something platform-independent and vector-length agnostic. ARM is especially interested in it being vector-length agnostic because of new SVE instructions.

❀️‍πŸ”₯

Src: #golang compiler and runtime meeting notes (golang/go issue 43930)
Things are getting interesting (#golang PGO for Go 1.20)