I think that would be a miss. The size/speed trade-off cannot often not be made accurately when viewed in isolation. E.g. it may be the best course of action to generic 16 different implementations in some cases, but as a general rule exploding every implementation x16 is probably unwise.
Being able to turn knobs on these decisions will be critical to achieving optimal overall application performance. > On Feb 27, 2022, at 12:03 PM, 'Axel Wagner' via golang-nuts > <golang-nuts@googlegroups.com> wrote: > > On Sun, Feb 27, 2022 at 6:33 PM robert engels <reng...@ix.netcom.com > <mailto:reng...@ix.netcom.com>> wrote: > I disagree that it wont be formally published - or at least have knobs to > turn to control it - otherwise it will be nearly impossible to make the > determination of when your generic’s usage will result in a performance > penalty. > > This doesn't seem substantially different from escape analysis. Where there > is also no spec or any other formal description, but just a flag to log > decisions. > I would expect generics to work similar in that regard. > > This probably won’t matter for 95% of the code - but it if does matter - your > only solution would be to always avoid generics and roll your own - which > defeats the purpose. > > I can see build labels controlling the generation options. > >> On Feb 26, 2022, at 5:51 PM, Ugorji Nwoke <ugo...@gmail.com >> <mailto:ugo...@gmail.com>> wrote: >> >> To your direct questions, the answer is a mix of both: C++ style where the >> generic block is a template and code is essentially generated for each type >> known at compile time with static dispatch, and java-like where it is >> similar to an interface call with dynamic dispatch. The compiler will strike >> the right balance of binary size, compile time and execution speed. To >> follow its heuristics rules (which will likely not be formally published to >> prevent people from depending on it), you might have to stay close to the >> development for that. >> >> On Friday, February 25, 2022 at 5:15:47 AM UTC-5 markus....@gain.pro >> <mailto:markus....@gain.pro> wrote: >> Correction: >> >> - it must be possible to express that T is comparable (so that you can use >> map[K]V, were K must be comparable) >> - it must be possible restrict T to a concrete list of types (f.e. min(a, b >> T) T must be possible to write) >> >> On Friday, February 25, 2022 at 11:13:01 AM UTC+1 Markus Heukelom wrote: >> I think the consensus in the Go community is to refrain from comparing Go >> language features with other programming languages. Rationale ~: >> >> - it is highly contentious >> - it is very difficult to answer, it's like asking "is purple more blue or >> more red" >> - no matter the answer, it will not help you a lot to write better programs >> or be more productive in Go >> >> However, maybe your real question is more like "what are/were the guiding >> principals for generics in Go?". As far as I understand, generics in Go >> follow the same principles as other language features in Go: >> >> - compilation should be very fast, but trade-offs are allowed so it does not >> need to be maximally fast >> - language features should be as orthogonal as possible, but trade-offs are >> allowed so they don't need to be maximally orthogonal >> - it should be a simple as possible but no simpler >> - ... >> >> For generics this has resulted in: >> >> - exotic use-cases are not supported (for example having an integer >> *constant* as *generic parameter*, such as you see in C++ fixed size matrix >> templates, is not supported) >> - it must be possible to express that T is comparable (f.e. min(a, b T) T >> must be possible to write) >> - it must be possible restrict T to a concrete list of types >> - it must be possible to restrict T to a type with method set that equals >> that of some interface (I *personally* think this violates the principle of >> orthogonality too much and will lead to confusion and design debate) >> >> Of course, neither list is exhaustive and is only my personal understanding >> of things. >> >> -Markus >> >> On Wednesday, February 23, 2022 at 9:41:14 PM UTC+1 Jason E. Aten wrote: >> Back in 2009, Russ wrote a blog on generics, talking about the tradeoffs in >> providing generics: >> >> "The generic dilemma is this: do you want slow programmers, slow compilers >> and bloated binaries, or slow execution times? " -- >> https://research.swtch.com/generic <https://research.swtch.com/generic> >> >> I haven't had the bandwidth to follow the generics detailed discussions. I >> was just curious, at a high level, for creating a mental model of Go's >> generics: which approach was taken? >> >> Thanks! >> >> J >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com >> <mailto:golang-nuts+unsubscr...@googlegroups.com>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/8edf65b3-f499-4446-908e-8e35d3070739n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/8edf65b3-f499-4446-908e-8e35d3070739n%40googlegroups.com?utm_medium=email&utm_source=footer>. > > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/D2355A50-46F9-475B-8651-5C7B117DFB2D%40ix.netcom.com > > <https://groups.google.com/d/msgid/golang-nuts/D2355A50-46F9-475B-8651-5C7B117DFB2D%40ix.netcom.com?utm_medium=email&utm_source=footer>. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHthjk9Oj5GemTRxXoeYgvOeR_hkism8og3YtWtvoJRVQ%40mail.gmail.com > > <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHthjk9Oj5GemTRxXoeYgvOeR_hkism8og3YtWtvoJRVQ%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/60675EEF-12CA-45DB-AC13-56485992D656%40ix.netcom.com.
