Most programming languages today fall into the paradigms of native machine code compiled ones like Rust, C, C++, etc or Bytecode compiled like Kotlin, Java, C#, etc. Even some interpreted languages like Python can be thought of as Bytecode compiled since the interpreter store the bytecode which is executed instead of the source file unless the source file is changed.

I think the main benefit of bytecode compiled programming languages is that they’re usually platform independent as long as there’s a runtime for the platform you want to use, but I also don’t know how much this matters anymore, or whether the inefficiencies of bytecode makes it worth it.

What do you think? Should new programming languages always be native machine code compiled, like Rust or C?

  • @AgreeableLandscapeOPM
    2•3 years ago

    Meta-programming capability, when you have IR representation, it’s pretty close to source-code representation, therefore you can dynamically emit new code and adjust your program behavior while it’s running on the fly.

    Doesn’t Rust have a comprehensive metaprogramming toolset despite being compiled? Though it does compile to LLVM IR first before going to machine code. Would a language that only compiles to IR be even better at metaprogramming?

    Tiered Compilation, you can immediately JIT the iR code to machine code that might be inefficient at first, but runtime can go back to that when the program is not using the resource as intensive as it normally would and then apply various optimization and analysis passes on the IR code for better native code compilation.

    I did hear that compiling the source code on the processor you’re going to run it on will produce a more optimized binary for the chip than one compiled on another machine, such as the binary provided by the developer. Is that true, and does that have something to do with your point?