3 ms·
Agreed. I almost never use sort.Sort in practice, sort.Slice is just so much more usable. Also, based on the recent blog post[0] a method-based approach will b
by cube2222 5y ago
Agreed. I almost never use sort.Sort in practice, sort.Slice is just so much more usable.
Also, based on the recent blog post[0] a method-based approach will be a tiny bit slower than the function-based approach. Not that it matters for most code though.
[0]: https://planetscale.com/blog/generics-can-make-your-go-code-slower https://planetscale.com/blog/generics-can-make-your-go-code-...
- staticassertion 5y ago> This means that a time.Time pointer has the same GCShape as an uint64, a bytes.Buffer and a strings.Builder. > In the current implementation of Generics in 1.18, every runtime invocation of a generic function will transparently receive as its first argument a static dictionary with metadata about the arguments being passed to the function. > That’s right, after the monomorphization step, the generated function shape needs to take as a runtime input the virtual method tables for all its generic arguments. What an odd design. I'm curious to read the justification for this. I assume it's faster compile times.
- shp0ngle 5y agoYeah, exactly that. Faster compile times.
- kgeist 5y agoAnd also smaller binaries. For comparison, our templates-heavy C++ project's binary is 1 GB in debug mode and 200 MB in release mode. It takes 10-20 seconds just to link.
- deleted 5y ago[deleted]
- staticassertion 5y agoAll of that gets removed though