alt Hacker NewsIf someone wanted to replace C, they are likely seeking to do so for reasons intrinsic to C, such as the risk of memory over/underflow, use after free, problematic numeric promotion, lack of proper strings and bools, etc.
Transpiling to C is the worst possible way of trying to address these issues. If you write `x + y` in your newlang, and that transpiles to `x + y` in C, you have simply inherited all of C's implicit type conversion nonsense. If, alternatively, you write a whole bunch of machinery to ensure x + y is always safe, congratulations, you're now writing a VM in C, which is even harder to get right and do safely. If you're trying to reduce your use of C, and you wind up maintaining a VM in C, I rather think you've somewhat catastrophically failed in your objective.
It's for this reason that languages trying to replace C don't generally transpile to C, despite your claim. The biggest C replacement candidates right now are Zig and Rust, both of which target LLVM IR, not C. There are precious few use cases where you'd want to leave C in as an unnecessary, problematic middleman, when LLVM IR is available.
Similarly, transpiling to JS inherits all of JS' baggage and issues, of which much has accumulated in the last thirty years. It would be an undoubted improvement to be able to bypass that layer when it isn't useful, regardless of one's opinion on JS.
Just as C replacements compile to pure LLVM IR, a JS replacement should be able to compile to pure WASM.
> Transpiling to C is the worst possible way of trying to address these issues.
It's really not. Compiler writers, in your words, "write a whole bunch of machinery" so that the code has the intended semantics. It's not fundamentally that different to generating LLVM IR.
I never said every single language compiles via C. Sure, you're right, Zig and Rust generate LLVM IR instead (edit: iirc Zig is moving to their own backend, but I don't think that's relevant), and there isn't much reason not to target LLVM these days, unless you want to target niche platforms that LLVM doesn't support.
> It would be an undoubted improvement to be able to bypass that layer when it isn't useful, regardless of one's opinion on JS.
I will ask you clearly: you are asking for a lot of work from browser makers. What use cases, concretely, will that work actually enable?
If you hate the baggage of JS -- which is fair enough, there's a big mismatch between it and many other languages -- Wasm can be used for most of the heavy lifting, and it lacks that baggage. The JS only needs to be a little layer between Wasm and the browser.
But what will getting rid of that layer enable? What will it let people do that couldn't be done before?
I'm not trying to be mean, so I'm sorry if it came off that way.