3 ms·
Not being able to have code that compiles in debug but doesn't in release is a pretty serious issue for CPU-bound performance-critical code. Otherwise, you're g
by pcwalton 8y ago
Not being able to have code that compiles in debug but doesn't in release is a pretty serious issue for CPU-bound performance-critical code. Otherwise, you're going to be commenting things out a lot or using preprocessors, both of which are annoying and slow down development velocity.
As an example, checking errors on GPU is enormously slow because you stall the CPU until the hardware FIFO drains every time you do. You can't ship software that checks for errors after issuing each DirectX or OpenGL call. But writing graphics code is also really annoying without a debug mode that checks for errors after each render command, because the failure mode of graphics programs tends to be "black screen" or "screen full of garbage".
- Spivak 8y agoIsn't a preprocessor the right place for something like this? It doesn't have to operate at the level of source code but if you want your actual code/AST, not just the behavior, to be different from dev to prod then you need a language that compiles to Go? Baking that into the language seems like it just replaces Go with that meta-language and hides the Go underneath like how "C" is really CPP-lang with a C compiler underneath.