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?

  • @AgreeableLandscape@lemmy.mlOPM
    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?

    • @BlackCentipede@lemmy.ml
      2•3 years ago

      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?

      Sure, Rust could do that with LLVM IR, but when deployed on the server with compiled code, it doesn’t have it’s code in IR form unless you ship that with it explicitly which probably over-complicate your implementation significantly, runtime is basically shipping that by default with all of the toolset built for you to do it right out of the gate. The IR in C# have object oriented with generic IR rather than LLVM IR which is pretty “raw” as in no “wrapper” for OOP programming, so that a big difference there. The CIL (IR for C#) is closer to C# than it is to machine code if that make sense, that just how abstracted it is.

      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?

      It’s really depends on the runtime, in CoreCLR that isn’t true, because it doesn’t apply optimization specific to your processor on the IR output in the source code to IR transformation (C# Compiler), but in IR to Machine code transformation (IE the Runtime itself) it would then apply various optimizations that works best on the processor you’re on that might not be fast on other processor. When you ship C# application, you’re usually shipping C# in an IR form, not native. Everytime you run C# program that isn’t AOT compiled, you’re basically spinning up a JIT compiler and have it compile your C# program code on the fly before it run the first code.