🇺🇦 Go performance channel – Telegram
🇺🇦 Go performance channel
1.49K subscribers
41 photos
410 links
Go performance, runtime, concurrency.

Talks, blogposts and open source projects for gophers.

Not affiliated with Go team.

https://go-perf.dev

(mail: hello@go-perf.dev / @olegkovalov)
Download Telegram
Yay, #golang performance dashboard https://perf.golang.org/dashboard/
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)