I'm curious about motivation - bounds checks for corrupted inputs seems like it would be one, but it also seems that fixing corrupted input handling in a C/C++ code base would not be too hard, and probably less of an effort? So why did you choose the rewrite?
And second, did you use any AI tools for the rewrite?
> fixing corrupted input handling in a C/C++ code base would not be too hard
The best programmers on the planet have tried and failed with this task for 50 years now, so I don't think this is true.
The main disadvantage of Rust right now is not supporting some more obscure platforms, but because mold wouldn't support them anyway I don't see that as a problem.
> The main disadvantage of Rust right now is not supporting some more obscure platforms
Last time I checked, I got impressed by the wide platform support, once you go down the tier list (https://doc.rust-lang.org/nightly/rustc/platform-support.htm...). What "obscure platform" specifically are you thinking about, that is currently missing from those lists?
LLVM doesn't have an equivalent annotated list, but it is missing alpha, bfin, c6x, fr30, frv, gcn, h8300, ia64 (aka Itanium), lm32, m32c, m32r, mcore, mep, microblaze, mmix, mn10300, moxie, nds32, nios2, pa (aka PA-RISC), pdp11, pru, rl78, rs6000, rx, sh (aka SuperH), storm16, v850, vax, and visium. For its part, LLVM does have some targets that GCC doesn't have (mostly related to GPU compilation).
The "big" targets that GCC has that LLVM lacks are Alpha, Itanium, PA-RISC, and SuperH, with Itanium being sufficiently weird that it's pretty firmly in the "fuck this" category from a maintainer's perspective, and people are actively ripping out support for it.
Just to be clear, I think this is a very small disadvantage. GCC and therefore C/C++ supports some old stuff like SuperH, Intel Itanium, PA-RISC and a bunch of microcontroller archs that LLVM does not.
However, there is now a Rust codegen plugin for GCC, so even this disadvantage is now basically moot.
I think the claim is that GCC supports a few obscure platforms that LLVM doesn't. Don't ask me which, that is just the claim that I heard multiple times. So it's not Rust that limits platforms, but LLVM. And they say the GCC backend efforts of Rust are meant to deal with that.
There are many. Two big ones are Alpha and PA-RISC. NetBSD and Linux continue to support both. Linux distro choices are pretty much limited to Gentoo though.
1. You've got the causality backwards. LLVM backends don't come for free, you have to write code to enable support for them.
2. LLVM does not support as many backends as GCC does, so even if you did get 100% of the LLVM supported backends up and running, you'd still be missing some.
Worth adding to this: there may also be code needed in the rust part (not just the llvm part) to enable support for a target triplet. There certainly will be for the OS and libc part of the triplet: what specific syscalls exist and should be used to implement the standard library on a particular flavour of BSD etc.
But even for the architecture part there can be differences. For example, my understanding is that a lot of the calling convention details need to be handled by the frontend in LLVM, leading rustc to duplicate logic from clang here. Things like varargs FFI with C code can be particularly gnarly.
My very naive understanding is that a part of what makes mold fast is concurrency, which I'd expect to be a lot more error-prone in C/C++. Not having to worry about data races might give more confidence with trying out more complex techniques for how to split up work in a way that ends up making things faster
I suspect fearless concurrency is another motivating factor. Better perf can be achieved by squeezing more parallelism, but without borrow checking it's difficult to do fine-grained parallelism correctly.
It's possible to write safe code in C or C++ but it's extremely difficult to read existing code and prove it's safe, without using as much effort as it takes to write it in the first place. This includes the code you wrote last month whose surrounding code has changed. And you have to be right every time while the attacker only needs you to be wrong once. The problem is not writing the code, it is continually verifying it.
As someone who worked professionally with both C++ and Rust, I mostly agree with this, but I would say that writing the concurrent code in C++ is also hard.
The only way I found that works reliably is stick to a small well defined set of mostly safe primitives. E.g. at work we use message passing / event bus architecture everywhere, which works great for a robotics / industrial context. But even then, if you somehow mess up and have a variable accessed from event handlers in two different threads, it is tough to spot other than if you get lucky and observe it with a build using TSAN.
With rust that class of mistakes is just entirely eliminated, which makes it easier to to concentrate on the hard things that actually matter (like the domain specific logic).
Apparently the old mold version had a couple of plain C source files in the source tree (both vendored 3rd party libs but also in the 'regular' source code), so technically C/C++ is correct in this case ...and looks like the Rust version also has some (very minimal) C code left (looks like mostly varargs stuff, I guess Rust doesn't have a concept of varargs?), so it could be called a C/Rust project ;)
There a flavor of CUDA runtime libraries that binds at runtime, so you can have a single binary that runs with CUDA and without it. I did this at work.
Obviously you need to check if CUDA is available before trying to execute kernels, or it will error out.
If I recall correctly, the Golang team got bitten by this on MacOS.
They initially implemented the Golang runtime directly on top of MacOS syscalls (not the C runtime library), just like they did on Linux - and then those syscalls changed, breaking Golang.
They had to switch to the official stable API which on MacOS is the C runtime library, not syscalls.
For me search has been that way since the first MacOS 26.0 upgrade and apparently never fixed.
But speaking of quality overall (outside of the search glitch) - I use dual 5k LG monitors with my work MacBook and can get the MacOS Display Manager process to crash if I just enable variable rate refresh and put the computer to sleep, then wake it up. Apparently a known issue for a few years, still not fixed.
SOAP 1.2 strikes me as really reasonable - it's a mature format with interop to several languages and has schema validation.
The inconsistencies you describe above are probably due to each org in the government implementing the common spec independently of the others, and introducing differences without even knowing. Documentation is key here, but as with any large system, there can be gaps.
It's really cool that you mapped it all.
And kudos to Brazil for creating a common computerized platform.
I once had to write some middleware for some warehouses based of an erp/crm subsidiary of the megacorp that rhymes with whoracle, the documentation was sparse specifically for the field I needed to modify, and once I got it working I saved 40MB of memory per PHP process by nuking the client side validator, fun times! The thrill of cobbling that together started me down the dark path to working for an API gateway appliance company, the darkness was immeasurable.
And second, did you use any AI tools for the rewrite?