> Rather than one large survey each November, we plan to launch two smaller surveys at roughly six-month intervals during the year.
https://go.dev/blog/survey2022-q2
(no idea why this blogpost wasn't tweeted by @golang 🤷♀️)
https://go.dev/blog/survey2022-q2
(no idea why this blogpost wasn't tweeted by @golang 🤷♀️)
go.dev
Share your feedback about developing with Go - The Go Programming Language
Help shape the future of Go by sharing your thoughts via the Go Developer Survey
🇺🇦 Go performance channel
User Zik have combined and benchmarked @bboreham patches related to the #golang regexp package and...results are astonishing! Well, if all these patches will be merged in 1.19 we can get 30-40% better perf! https://github.com/golang/go/issues/26623#issuecomment…
> "exceptionally small" yet powerful CL mentioned previously has been merged for Go 1.19! 🎉
https://github.com/golang/go/issues/26623#issuecomment-1146708013
CL https://go-review.googlesource.com/c/go/+/355789/
https://github.com/golang/go/issues/26623#issuecomment-1146708013
CL https://go-review.googlesource.com/c/go/+/355789/
GitHub
regexp: investigate further performance improvements · Issue #26623 · golang/go
Languages Regex Benchmark: Language Email(ms) URI(ms) IP(ms) Total(ms) C PCRE2 25.00 25.02 5.65 55.66 Rust 31.31 31.73 6.75 69.79 PHP 54.39 50.22 5.80 110.40 Javanoscript 74.88 63.09 2.02 140.00 D ld...
Nice patch for #golang bigint:
math/big: make NewInt inlineable and zero allocation
Mark the assembly routines as not escaping their arguments.
https://go-review.googlesource.com/c/go/+/411254/
math/big: make NewInt inlineable and zero allocation
Mark the assembly routines as not escaping their arguments.
https://go-review.googlesource.com/c/go/+/411254/
#golang proposal: add package for using SIMD instructions
https://github.com/golang/go/issues/53171
(Check this too https://github.com/mmcloughlin/avo by @mbmcloughlin 😉)
https://github.com/golang/go/issues/53171
(Check this too https://github.com/mmcloughlin/avo by @mbmcloughlin 😉)
GitHub
proposal: add package for using SIMD instructions · Issue #53171 · golang/go
SIMD has the potential to greatly increase performance of a lot of data processing applications. Since #35307 was closed with the remark We agree that there is an opportunity here, but we don't...
Yay, #golang performance dashboard https://perf.golang.org/dashboard/
Scaling our Spreadsheet Engine from Thousands to Billions of Cells in #golang
https://www.causal.app/blog/scaling by @CausalHQ
https://www.causal.app/blog/scaling by @CausalHQ
causal.app
Scaling our Spreadsheet Engine from Thousands to Billions of Cells - The Causal Blog
From Maps to Arrays
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/
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/
🇺🇦 Go performance channel
https://twitter.com/calebspare/status/1546928290123812864
Twitter
New #Go memory model seems to be like Java: no undefined behavior due to data races, only race conditions (all variables are atomic-ish). This inhibits lots of compiler optimizations C/C++ compilers typically do.
But races on strings/maps still lead to arbitrary…
But races on strings/maps still lead to arbitrary…