The US has planned their move to Rust (it's wild)

TRACTOR is a wild project. A program to port all C code to Rust? By the US government?? Wild.

SOURCES

SHOUTOUT @letsgetrusty FOR COVERING THIS INITIALLY 🫡

S/O Ph4se0n3 for the awesome edit 🙏

[Tabonx_]

Fun fact about how government can also work. In the Czech Republic, the government created an order/contract for a highway stamps e-shop for about 17 million US dollars. People thought it was unacceptable to pay that much for an e-shop, so one company created something like Hackaton with about 60 people and said that they would have that site ready in 48 hours for free. They delivered the site after the weekend, and the government ended up using it. This not only saved 17 million dolars but another 20 for some other thing the government ended up canceling based on this.

[Shenepoy]

rust can't save you from bad programmers

[Mempler]

The US Government literally just said: "Let's rewrite C in Rust"

[iamtheVRTEX]

@7:00 The Youtube Channel "No Boilerplate" described this elegantly about a few core Rust packages: "Their last updates were years ago. They're not abandoned--they're **done**". Rust lets you finish projects...when "finished" is well-defined, of course.

[zactron]

Easily the best Rust take you've had. Government software, foundational libraries like OpenSSL, software in abandoned hardware (e.g., IoT smart devices, etc.) are all places where the cost of Rust is massively outweighed by the potential costs of not using Rust. I dont think I want every developer to stop writing NodeJS apps, but i definitely want the NodeJS filesystem API to be written in Rust, as an example.

[quantum_dongle]

Government software acquisition is changing. There is a general recognition that the way we do it now is unsustainable. As such, most of the DoD is adopting more iterative development practices using different types of acquisitions contract constructions.

If you are curious, google "bending the spoon" and "there is no spoon" (both written by will roper, a former high level DoD acquisitions lead)

[cooltrashgamer]

Rust began as a personal project in 2006 by Mozilla Research employee Graydon Hoare, named after the group of fungi that are "over-engineered for survival"

Nothing to do with actual rust like on metals

[sturdyfool]

The fun thing about strings is that C++’s std::string addresses most of the string based issues on a language level, but people don’t know how to validate anything properly, mega skill issue

[pokefreak]

Yeah I can't imagine this ever going well... Rust and C are completely different languages. You can't just translate a C codebase into idiomatic Rust, the right abstractions will be different for every project and should be carefully engineered by people with both domain-specific experience and experience with Rust.
The code reviews on serious government projects like this should take 20x longer than the actual implementations anyways, so unless they're blindly trusting the code output by their translator I don't see how this would save any time.

[stephenjames]

For me the biggest challenge is how to determine if the conversions are correct. Having worked on many legacy rejects there are so many hidden behaviors that are almost impossible to test.

[jaredvizzi]

You had me at “the software engineering community has reached a consensus”.

[starbrandX]

A lot of the US military has been using Ada for a long time

[_stix]

Regarding compile times, the customer doesn't care how many minutes it took you to compile your code, suck it up and watch the loading bar

[DevynCairns]

Converting sync to async is an extreme example because Rust works very, very differently depending on which you're using. I have done it but it takes a while. Compile times are also better for sync code and there are a lot of things that you just have to know about async

But I really disagree that Rust makes it harder to iterate. I think it's actually easier in some ways because the compiler catches so much of the potentially wrong behavior and it does so pretty quickly with great feedback. With an LSP you can just jump around and fix everything. By the time it compiles and you run your unit tests, the likelihood of everything just working is higher than typical for many other languages. It's a comparable experience to Haskell but with better diagnostic messages and more LSP features

[tinrab]

The lower speed of development argument is not accurate. I don't think writing Rust slows me down at all. I can even do leetcode in Rust. There was also that report from Google about how productivity doesn't suffer. Also, keep in mind that the goal of Rust is being a well-designed language without many compromises. So, it is harder to learn, but the code is healthier.

[fpeng]

I believe there’s a good saying to fit rust development: “Good things take time”

[Elesario]

I'm a bit dubious of the whole concept. The number of challenges to face into and whether the result code will be worth it is dubious.
1. You're just going to get Rustified C. Unless they have some very fancy tech that can take C concepts and turn them into Rust concepts, you'll get code that doesn't take best advantage of the concepts of the language.
2. It's a false premise that just by translating into Rust your code is automatically "safe". Rust is built around achieving memory safety, but there are other code flaws that could cause problems it won't auto find for you.
3. If you can write code that can turn runnable C into runnable Rust, then you're pretty much making a borrow checker to get the translation right. By the end of the project you've got a tool that can scan C and tell you were the memory errors are anyway.

Most likely outcome is you make a tool that does a basic equivalent code to code translation, that probably won't compile without manual intervention. It might act as a good starting point to have a team of developers recode critical areas, while the boilerplate is taken care of by the translation tool. However, as was pointed out in the video, if you make certain choices early in Rust, it can become difficult to redirect the code later without refactoring the code to some degree, and with a tool like this, the choices come from the translation.

[benmeehan]

What can go wrong? You have a legacy code base that has largely known behaviour, and most of that is probably not codified in terms of tests (or with limited coverage), but just real world experience of its operation. You convert the code base to a new language, now what do you have? Whilst I'm sure part of the point of Tractor is to ensure equivalence, how do you prove that? Do you just ship it and hope for the best? It might well remove a class of software defects, especially around vulnerabilities to bad actors, and that might be a worthy goal, but this seems to be arguing the case against "if it ain't broke don't fix it" because we don't know the ways in which something might be broken, and indeed, it might not be broken at all. So you might just end up refactoring logic in millions of lines of code that represented no threat, in ways that you can't yet predict. The goal is good, but as with everything, the implementation is what counts, so lets hope someone did thorough risk analysis or we might see another CrowdStrike.

[Turalcar]

8:22 Borrow checker and other types of static analysis take a minuscule amount of time compared to the actual slow parts (i.e. linking)

[davidwhatever]

something like this happened with a defence reaserch institute in the uk, the order came, stop using fortran and start using algol. as a result everything stoped for a year as everyone spent their time porting their fortran to algol and after a year the head of the institution was replaced and everyone went back to fortran.
i hope this move works out better.