Hi Mike, I don't know what quirk of human nature is that causes so many to want to change a language to fit their whims, when that language has as a principal virtue that it wants to be super readable and almost never change (visit C++ for a strong argument as to Go's posture is so beneficial; Go was in part a reaction to C++ and so actual language changes are very rare), but I'm starting to grok why Lisps gets cult-like fervent adherents. A Lisp bends to any whim, and that must be a powerful human behavioral reinforcer.
Digression aside, and back to the point at hand: Generics are great for type safety and expressiveness. Most folks have figured out by staring at their profiler output that at their current maturity level, they can also be quite a bit slower than non-generic code, on a case-by-case basis. Recall that RSC blog where he posted the 3-way speed trade-offs that generics represent, and realize that those performance tradeoffs still hold, and are still real, despite the tangible gains in usability and type safety that the current "hybrid" generics implementation offers. (Reference: the 2009 blog, "The Generic Dilemma", https://research.swtch.com/generic ) So the point is: if you are optimizing for speed, you don't _typically_ reach for generics in Go. They've got to be compiled fast and not bloat the binary size, so they aren't going to be super runtime efficient. You reach for super simple code, maybe codedgen that allows inlining, and perhaps regular expressions for some lexing scenarios such as floating point numbers, because they compile to a little finite state machine that can end up being very fast while being relatively easy to specify and check that it is correct. You can always write assembly or SIMD AVX512 code if you really need it to go faster. That's all supported today. And LLMs are not half bad at assembly these days. Best wishes, Jason On Wednesday, March 19, 2025 at 9:48:03 PM UTC Mike Schinkel wrote: > > On Mar 19, 2025, at 5:34 PM, Robert Engels <ren...@ix.netcom.com> wrote: > > > > I suspect if you wrote a small real world parser you would find a > negligible performance difference. > > I am writing a real-world parser. I'll benchmark it when I am done. > > -Mike > > -- 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 visit https://groups.google.com/d/msgid/golang-nuts/ba5818b9-cf1a-4fc9-af7b-fc051f311954n%40googlegroups.com.
