Hacker News new | ask | show | jobs
by e79 4078 days ago
This demonstrates the power of Go generators. We're seeing what are typically language features such as generics and debugging being implemented before runtime using code generation. The result is more functionality without an overall increase in runtime size or decrease in runtime performance.

It's unusual and it's opinionated, but it works.

3 comments

> This demonstrates the power of Go generators. We're seeing what are typically language features such as generics and debugging being implemented before runtime using code generation. The result is more functionality without an increase in runtime size or a decrease in performance.

Monomorphization is a bog-standard implementation technique for generics. It's not at all unusual.

source?
Just off the top of my head, C++, .NET (via a JIT), Rust, D, MLton, and (I think) Swift all do it.
I was hoping for some article or wikipedia entry that would tie your comment with the parent's comment, and with the original article. Monomorphization is, to my understanding, taking a polymorphic function and instantiating it to the specific type requested. This is done at compile time. Now, the tool in this article interleaves debugging code with original source code. So the connection is... both monomorphization of generics/templates and this tool operate by emitting source code prior to compilation?
The original comment was about how both debugging and generics are being implemented with code generation before runtime in Go and described this as "unusual." The response was that this precise technique is how generics are implemented in many languages already; in fact, CFront (the original C++ compiler) was entirely implemented as code generation on top of C. The response specifically discussed generics, not debugging, so I'm not sure why you thought it was talking about debugging.
To be fair, this does increase runtime size and decrease performance, but that's a necessary cost that comes with the debugging capability
"that's a necessary cost that comes with the debugging capability"

I'm doing some research that shows this isn't the case. You can have a system where enabling the debugger has zero impact on runtime performance, via dynamic deoptimization.

http://www.lifl.fr/dyla14/papers/dyla14-3-Debugging_at_Full_...

What is the difference between the generators in Python vs Go?
They're not the same thing. This is about code generators (https://blog.golang.org/generate) while in Python context you're most likely talking about iteration.