4 ms·
> Obviously, Java has shown that you can survive without a macro pre-processor. That was even a point Gosling+Co made in a white paper I read way back in the da
by throwawayish 10y ago
> Obviously, Java has shown that you can survive without a macro pre-processor. That was even a point Gosling+Co made in a white paper I read way back in the day. But I do believe that if you are going to have a macro processor, it should be an expedient. Rust's macro processor is not expedient. It is its own impediment.
Annotation Processors (iirc Java 1.5) are clearly a form of a pre-processor. It's not macros / textual expansion, though.
Similarly C++ mostly gets along without macros since it contains a capable meta-programming system -- and I think this is the more important point here; for many tasks meta-programming is just a handy thing to have. Dynamic languages don't have that problem, since their runtime is their meta-programming system as well.
- pjmlp 10y agoAnother thing that has helped Java was the decision to use a JIT. Most Java JITs are able to remove code if it is proven unreachable, which allows to use pure Java code for what would be #ifdef in C, with the caveat that all branches must compile.
- CalChris 10y agoYou would think that AOT would be the right time to remove dead code.
- pjmlp 10y agoOnly if it can be fully determined at compile time. For example a debug flag can depend on a command line parameter, but it will be used to initialize a constant variable. So the code can be shipped with both versions, and the JIT will just remove the unused branches.