> do you want slow programmers, slow compilers and bloated binaries, or slow execution times? Why choose? With generics we can have all three!
[deleted]
Faster Sorting with Go Generics
11–20 of 62 posts
Re: Faster Sorting with Go Generics
#12> The first thing to note is that there is no dynamic dispatch to the Less method. Each loop iteration invokes cmpstring directly. Except about 95% of the arrays I sort aren't comparable with just <. It's less clear how the unmentioned sort.Slice() will improve.
The article argues that even a function call to a “less” function benefits from the elimination of bounds checking.
Re: Faster Sorting with Go Generics
#13Quoted post unavailable.
>we've already learned that Go doesn't respect your freedom given its license choice
What do you mean?
Re: Faster Sorting with Go Generics
#14Quoted post unavailable.
Yeah Go is all about "simple, fast enough, compiles fast"
So I'd say knobs to control this, which, if you get them wrong, lead to slow compiles, would defnly be contra the spirit of Go.
And in cases where absolute max performance really matters, nothing is stopping you from monomorphizin by hand. (But if absolute max perf really matters, you probably picked the wrong language.)
Re: Faster Sorting with Go Generics
#15Quoted post unavailable.
[deleted]
Re: Faster Sorting with Go Generics
#16> do you want slow programmers, slow compilers and bloated binaries, or slow execution times? Why choose? With generics we can have all three!
[deleted]
Re: Faster Sorting with Go Generics
#17Quoted post unavailable.
Yeah Go is all about "simple, fast enough , compiles fast" So I'd say knobs to control this, which, if you get them wrong, lead to slow compiles, would defnly be contra the spirit of Go. And in cases where absolute max performance really matters, nothing is stopping you from monomorphizin by hand. (But if absolute max perf really matters, you probably picked the wrong language.)
There is no language that writes code as beautiful code as go, at a lower level. C comes close, but C++/Rust are plain ugly, while C is older than some HN users and requires a lot of third-party dependencies for basic operations (e.g http requests).
Re: Faster Sorting with Go Generics
#18Earlier quoted context omitted.
Yeah Go is all about "simple, fast enough , compiles fast" So I'd say knobs to control this, which, if you get them wrong, lead to slow compiles, would defnly be contra the spirit of Go. And in cases where absolute max performance really matters, nothing is stopping you from monomorphizin by hand. (But if absolute max perf really matters, you probably picked the wrong language.)
There is no language that writes code as beautiful code as go, at a lower level. C comes close, but C++/Rust are plain ugly, while C is older than some HN users and requires a lot of third-party dependencies for basic operations (e.g http requests).
No post body was provided.
Re: Faster Sorting with Go Generics
#19Earlier quoted context omitted.
Yeah Go is all about "simple, fast enough , compiles fast" So I'd say knobs to control this, which, if you get them wrong, lead to slow compiles, would defnly be contra the spirit of Go. And in cases where absolute max performance really matters, nothing is stopping you from monomorphizin by hand. (But if absolute max perf really matters, you probably picked the wrong language.)
There is no language that writes code as beautiful code as go, at a lower level. C comes close, but C++/Rust are plain ugly, while C is older than some HN users and requires a lot of third-party dependencies for basic operations (e.g http requests).
Object Pascal, Modula-2, Active Oberon.
Just for starters.
Re: Faster Sorting with Go Generics
#20Are there any good write ups on Go Generics vs other languages for those of us who are familiar with Go but do not write it on a day to day basis? I pick up Go every few months to try new things cause its infinitely easy to setup a web server in Go since it is built-in.
I encourage you to explore why generics exist in the first place by exploring topics such as Parametric Polymorphism, Higher Kinded Types, & Higher Kinded Polymorphism. The truth will set you free.
Better to start with the problem than the most abstract formulation of its solution-- which only makes sense after successive encounters with ever more complex problems.
Simply, of course, we can begin with why it should be that data structures have operations in common -- rather than, say, having each their own specific versions.