Using Rust for kernel development

Posted Sep 28, 2021 7:21 UTC (Tue) by tux3 (subscriber, #101245)
In reply to: Using Rust for kernel development by jgg
Parent article: Using Rust for kernel development

Mozilla seems to think having two languages in the same codebase is reasonable. Given Rust was created at Mozilla and used to ship major Firefox components, I imagine they have thought about this quite a bit.

Unsurprisingly, Mozilla is not trying to convert their existing C++ codebase into transpiler output.

Using Rust for kernel development

Posted Sep 29, 2021 6:29 UTC (Wed) by maxfragg (guest, #122266) [Link] (3 responses)

you might be surprised to learn, that mozillas codebase started with transpiler-output, as what later became the mozilla suit and in turn firefox had a transpiled java core.

Using Rust for kernel development

Posted Sep 29, 2021 9:13 UTC (Wed) by farnz (subscriber, #17727) [Link] (2 responses)

Have you got a reference for this? I can trace the core of Firefox's codebase back to Netscape 1.0, which predates Java, so if a transpiler was involved, it was during the rewrite.

Using Rust for kernel development

Posted Sep 29, 2021 9:33 UTC (Wed) by Fowl (subscriber, #65667) [Link] (1 responses)

I don't know if there is any transpilation in the "original" Mozilla, but the HTML (5, at the time) parser was converted from Java to C++ - https://johnresig.com/blog/html-5-parsing/

Using Rust for kernel development

Posted Sep 29, 2021 10:41 UTC (Wed) by excors (subscriber, #95769) [Link]

> I don't know if there is any transpilation in the "original" Mozilla, but the HTML (5, at the time) parser was converted from Java to C++ - https://johnresig.com/blog/html-5-parsing/

The HTML5 parser is a special case since it's a large amount of mostly very repetitive code, defining a complex state machine to turn characters into tokens and another to turn tokens into a DOM tree. (There's enough special cases and weird rules, for backward compatibility reasons, that it's not very practical to implement the state machines declaratively - it's easier to write as imperative code. Plus the code closely mirrors the structure of the HTML5 specification, which makes it easier to verify that the spec and implementation are consistent.)

Since it's so repetitive, it's relatively easy to mechanically translate between languages. And I think in this case the transpiler was custom-written for the HTML5 parser, and the Java version of the code was modified to be easy to transpile. E.g. compare "startTag" in Java (https://hg.mozilla.org/mozilla-central/diff/8b5103cb12a6b...) and C++ (https://hg.mozilla.org/mozilla-central/diff/8b5103cb12a6b...): the Java has some explicit "// [NOCPP[" markers for sections to omit from the C++, function calls like err() are deleted from the C++ (because the Java version was meant for use in a validator, which needs to report parse errors with as much detail as possible, whereas a browser doesn't), enum values are renamed to Mozilla's naming convention, string literals are replaced with global constants, etc, so there's a lot of translation rules specific to this codebase.

This is very different from general-purpose transpiling of arbitrary code that wasn't designed for it.