Thread by @ShadajL

After FOUR-plus YEARS of development, we've merged support for 32-bit platforms (including #WebAssembly) into @scala_native 🎉🎉🎉 (github.com/scala-native/s…). 🧵 on the story of how this happened 👇 (1/n)

It all started back in 2017, on my high-school's robotics team. We had been using Scala (github.com/team846/potass…), but on the JVM. This had a brutal performance impact, with the robot taking 2+ min to boot up and having to use a USB drive for swap (!). (2/n)

At Scala Days 2016, I had attended @den_sh's talk introducing Scala Native (), and was immediately intrigued. Low memory usage, more predictable performance, and efficient FFI? That's exactly what we needed! (3/n)

But it wasn't so simple. At the time, Scala Native couldn't even handle trait inheritance, so porting our FP framework wasn't possible. But by mid 2017, Scala Native had matured enough to cross-compile our core modules (github.com/Team846/potass…)! (4/n)

By December 2017, after finishing college applications, I sat down to try to run Scala Native on the NI ARMv5 platform used in the @FRCTeams competition. But there was a problem! Scala Native assumed throughout its code that it was running on a 64-bit platform! (5/n)

So I (very hackily) implemented support for 32-bit platforms by effectively doing a find/replace of 64 with 32 throughout the code base. And then we took things a little further by merging in the WIP support for multithreading (github.com/shadaj/scala-n…). (6/n)

To our surprise, it just worked! And we soon had a demo of controlling a servo (

https://twitter.com/ShadajL/status/949162958117994496

). With Scala Native (github.com/team846/code-2…), our team made the championships for the first time in 4 years. But this is where the real story begins! (7/n)

Our hacky solution was definitely not ready, since it broke 64-bit support. So the first attempt in Summer 2018 was to treat 32/64-bit platforms as separate targets at the Scala level, so we could switch between Int/Long in the type system. (github.com/scala-native/s…) (8/n)

But after more iterations in 2019 (github.com/scala-native/s…), it became clear that forcing library developers to publish separate JARs for each platform would be too large an overhead. We needed to handle multi-platform support in the linker, where the LLVM is emitted. (9/n)

So mid 2019, we developed a new approach (github.com/scala-native/s…), where Scala Native would include a special `Size` type that opaquely represents either a 32 or 64-bit value. With this, libraries can publish a single JAR that automatically supports all platforms. (10/n)

This is the PR that would eventually be merged, > 3 years later. In that period, we went through many API iterations, developed infrastructure for testing with QEMU, added support for ASAN, and more. But after 181 commits and countless rounds of reviews, it was ready. (11/n)

So yesterday, we finally merged this 3-year old PR, which will be released in Scala Native 0.5. The future is exciting, as this will enable builds with the standard toolchain to target WebAssembly and a wider range of embedded platforms! (12/n)

On a personal note, getting involved with the Scala Native community had a huge influence in getting me interested in PL research. The mentorship of @den_sh and others really got me thinking "hey, maybe I could work on research like this someday!". (13/n)