@@tylerknight99As a bad programmer, I concur. But man, JS allows you to get away with such insane amounts of stuff that wouldn't fly in any other language that I kinda have a soft spot for it.
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.
It sounds like the Czech Republic learned from Google and their Summer of Code program (and hackathons). And, of course, Google is not the only company sponsoring hackathons. That said, imagine if we trained doctors by having them hack for free on people before they were licensed. Ignoring the disturbing connotations of unqualified surgeons, I'll point out that some of the software hackathon participants are among the best programmers I've seen, particularly in the hackathons where professional programmers participate because they are short and over a weekend.
@7:00 The RUclips 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.
That's interesting, because one of the things that's been keeping me back from really diving into coding at all, is that constant need to create updates. I mean, if the update is truly needed, then so be it, but otherwise that 'finished' aspect sounds nice.
@@LoneHawk You are correct, but this particular take is very close to the truth: When your end goal is strictly defined, it is possible for a software package to reach a stage where it is done and needs no maintenance. Rust makes this easier than most other languages because it guarantees you that you haven't made any memory related bugs or exploits. Of course you can still have bugs in the behavior of your solution, or requirements might change, or Rust might eventually reach a point where they need to make a breaking change. This also applies to other languages, you'll just have a higher barrier to reach "done" and dependencies are often more volatile due to the chicken and egg problem (if it's harder to reach "done" then your dependencies are more likely to go through breaking changes which means your package will also need updates to leverage the improvements in your dependencies)
You will never get javascript developers to accept this. "This library is dead, it hasn't been updating in years" "But its a test-passing implementation for a spec that hasnt been updated in a decade" "No, it needs constant updates!"
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)
Fed contracts at my company are still usually fixed scope but state and local municipalities love having us use continuous delivery to get critical functions rock solid.
I do think for non safety critical code a more iterative approach would be advantageous. One of the major problems with this style of writing software is that it is very hard to adapt it to changing requirements. What happens is that fed up users develop hacks and kludges to half implement new features because it's too expensive to update the code. They may even end up using the software for things it wasn't intended for just because it's too expensive and burdensome to do things properly. This goes on until everything becomes such a tangled mess the government is finally persuaded to fund an upgrade.
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
habits are hard to die, people for a long time used the old methods and most resources are for the old methods therefore people will keep using these same old bad habits.
The issue is not that there's no way to write memory safe programs, its that you CAN write memory unsafe code. Using Rust makes sure nobody has to manually go through and verify everyone's code to make sure it's ok, because the compiler does that automatically.
@@P-39_AiracobraNobody is "manually going through and verifying" code. Safety has been a solved issue in C/C++ for a long time. All of this is automated. We don't worry about this at all, which is why we didn't adopt Rust over the past decades, you know. Our problems are maintainability and interoperability. Rust is pretty much the last thing C/C++ engineers want. This detached-from-reality online-hype culture is really messing with people.
@@P-39_Airacobra > Using Rust makes sure nobody has to manually go through and verify everyone's code to make sure it's ok, because the compiler does that automatically. This is a fallacy. Rust prevents some memory safety concerns but it does not prevent unsanitized input, memory leaks or unchecked uninitialized memory. On top of that, if you need something to be more performant and effcient, chances are that you have to resort to unsafe code in some cases - this does not mean unchecked code, but it does mean that it's allowed to work with the raw pointers and the compiler can only help you in very specific cases. Write any type of cyclic data structure in Rust, and you'll likely come to the conclusion that it's not that easy without some unsafe code, or end up with less than much less efficient solution due to the compiler adding additional runtime checks. What Rust does help with is manage unsafe code in blocks, rather than globally. But it does not prevent it.
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.
@@JoseHenrique-xg1lpOk, why? Its not like it has the same memory security concerns as c or c++ as it is a gc language. Are you worries about null pointers or something? Or is the speed just too slow for you?
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
Fascinating. Is there a word for this kind of thing, or more examples? I.e. guessing/reinterpreting why something was given a certain proper name, and which symbolism or metaphor the author intended to evoke. It's a special case of folk/false etymology, closely related to backronym, and maybe in the same ballpark as retronym and dead metaphor.
And, the creator of Rust is disappointed with the current state of Rust, Rust didn't have to be complex, with every feature imaginable. They ruined Rust by taking it in the direction of C++
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.
It's pretty easy to translate C to Rust Code, people like you didn't even tried it once but have strong opinions xD Makes no sense. Because of Rusts abstractions it's even less Code in the end
@@ITSecNEO Yeah no lol. In C we make our own data structures and string types. Even just determining wether to rewrite those to the Rust builtins or keep the bespoke implementation is an incredibly complex decision. Then you have pointer-heavy code, gotos, longjumps, custom allocators, platform-specific data types, opaque structs, inline assembly... And then in rust you need to reachitect the entire application to make use of traits, pattern matching, operator overloading, slices, modules etc, all while appeasing the borrow checker. It's not happening.
@@pokefreak2112 You can already transpile C to (unsafe) Rust - all you have to do then is to go through all that generated code and convert it to idiomatic and safe Rust. It's a lot of work, yes but also very doable and many have done so actually. It's one of the standard Rust challenges to convert some legacy C-lib to Rust ;) Also not all code will be difficult, that really depends.
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
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.
Yeah I don't buy it either. The only thing that is slow is a full build. But the programming workflow in rust is more compiler driven than "compile and then run it" driven. So if you are doing rust "right", you are spending a lot of your time doing incremental compiles and modeling your data in a way that if it compiles it probably works first try. You fix most of your issues by fighting with the compiler on an incremental build until it doesn't give you errors (errors that would have happened at runtime in another language). And that loop is fast. You still run tests, but it isn't the 90% of your time that a traditional test heavy workflow is in another language.
@@OldKing11100a lot of it is just getting used to it and getting your flow down I used to be faster in python but I can now do better rust code in the same time as python. In the end it takes time to get to the speed of a lang you’ve been using for awhile
i feel the same way as well. i think initially it can be slower but once you get comfortable it's fairly fast. i'm faster with go but i prefer writing rust code.
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.
Or Good Old-Fashioned AI that actually proves equivalence according to specified criteria, using search and formal logic. LLMs might actually be a great way to provide better heuristics (i.e. possible solutions to try out), but I hope it doesn't mostly rely on it end-to-end. Automated theorem proving & co aren't as sexy, so maybe they wanted to benefit from the ML hype?
It might work if they parse the C to an abstract syntax tree, use LLM to convert to a Rust abstract syntax tree, then render to Rust source. The C preprocessor will give them grief. I wrote a 6000 subroutine C program that converted a domain specific language to another DSL and preserved the conditional compilation from the preprocessor. I was lucky that both had a preprocessor. Rust does not.
@@JeffBartlett-kj6sq rust does have a preprocessor, its macro system, and it sits somewhere between a traditional c style tokenizer and template expansion build tools found in c++, but it also extends beyond that in its expressiveness. a famous example is a macro from a library that takes in an SQL query, tests it for correctness, and then produces rust code to express that query, all within rust's build tools.
Don’t judge LLM’s based on prior experience if it’s not recent, I find gpt4o to actually write very decent code. Especially if I get it to debug itself. Literally 10x faster than I can actually even type it myself
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.
I find rust iteration time at least for proper code is actually pretty fast. Also the slowness is really only on the first builds after the first are pretty dang fast. As for the making a function that wasn’t async async the big question is why didn’t you just code it async in the first place? Pretty much haven’t touched sync rust since I started learninh
Sync is better in some ways if you're not really going to be I/O bound, and because of the way async code is internally represented it tends to make compile times absolutely explode on large projects if you're not careful to set up some boundaries to prevent the type explosion
@@_stix That's not a real solution. If you think like this developers will do the bare minimum to comply with whatever quality standard they're being held to and won't put in any effort beyond that. If you want actually good software you should create an environment where developers feel intrinsically motivated to do a good job, fast compile times are a part of that.
@@pokefreak2112 Keep in mind that unless you have a truly massive codebase, most of the compile time will be spent on your dependencies. Because Rust uses incremental compilation, you only have to compile those dependencies once, so the effect on iteration speed isn't as high as it seems.
@@pokefreak2112I never have been in an environment where I am intrinsically motivated to do a good job. I still exceed expectations even when I have to fight the behemoth so I am allowed to do the right thing. Maybe that’s because I am a professional and take pride in my skills and craft. I don’t know what you are smoking.
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.
Go or (procedural-style) Java/C# would at least be more straightforward to translate, if your main concern is memory safety. Though, given my near-zero experience with production C code, maybe I'm underestimating how often it involves actually clever pointer pro gamer moves, instead of just implementing string processing and trees etc. the hard way. Embedded probably more often, and there the performance hit of these VM languages would be a concern. In either case, there you'd also have trouble translating those into Rust.
Those kinds of tools already exist for C anyway, both static and dynamic analysis. The paper makes the disingenuous argument that such tools aren't enough even though they're already better than what the Rust compiler provides and more feature complete.
@@jakelexington7610 Was that supposed to be directed at me, because I see no one else even using the word better. If it was, then you may need to reread what I wrote to come to actually understand it.
@@nibblrrr7124 I have a lot of experience with production C code, and it tends to do lots of things like casting pointers to integers and back, or using unions (sometimes just to optimize storage, but sometimes for type punning purposes). And all sorts of other stuff. Even well-written code would be difficult to translate, and the majority of "production" C code I've seen (especially if it's been around a while) is quite horrifying. There's also the fact that Go, Java, and C# use a garbage collector. C uses manual memory management, which is inherently unsafe (e. g. use-after-free bugs). Rust makes manual memory management safe, but to do so it requires coding in a certain way, and adding a lot of annotations to code (i. e. "borrowing" versus ownership).
What ever happened to Ada? That was the Federal government's previous effort at software security / standardization. It's actually a pretty nice language.
It's mainly used by the military for on board computers in vehicles, from what I've seen, I have not seen it being used in other government branches, mainly Java and C/C++ for their projects.
I believe it was phased out because it was an incredible pain to code in it. I remember it took 45 minutes to compile a 300 line programs. Granted it was when the student were all compiling simultaneously. It's still longer than C. Once Borland came up with TurboC, everything else faded into obscurity.
that's what happens when unsupervised childrens get access to an unlimited supply of money: let's rewrite 1 million lines of legacy code that already works using an llm technology that doesn't exist yet and needs to be funded(gpt cant convert 1m+ lines), even if it introduces a thousand new potential points of failure, since the code needs to be rewritten in its entirety by a black box AI transpiller
Define “already works.” They’ve clearly identified the millions of lines of legacy code as a national defense liability. Do you want our power grid, communication systems, weapon systems, etc. running millions of lines of code riddled with exploitable memory bugs? The number of domestic and foreign cyber attacks will only increase going forward, and I would prefer our critical infrastructure to not be so vulnerable, thanks. Read up on DARPA. They have pulled off some of the greatest technological innovations in history. I’m very glad that people much smarter than you and me are trying to tackle these issues, just let them cook.
Yeah, that’s the part that worries me but attempting to refactor as much of the C stack as possible is not a bad idea. I just don’t agree with using llms. They obviously do not understand machine learning.
@@kiseitai2 "attempting to refactor as much of the C stack as possible is not a bad idea" as I said, if a billion lines of legacy code already works, why would you even think about changing it. there's nothing wrong with c. why waste the taxpayers money funding something useless that doesn't even need to exist when there's so much inflation going on for example
Well, it's DARPA. If it isn't filled to the brim with scientists given all the moneys and told to channel their wildest ideas into something plausibly useful for the Pentagon, then what in the world are they actually doing? And I will also remind you that they have a bunch of AI powered projects in the works from Wikipedia, let alone stuff that's classified.
16:08 What I've noticed is that LLMs can tell you the rules of Rust but it sucks at following them. It will therefore give you code that won't compile.
I don't know how they're planning to do it, but personally I would use LLMs to recognize idioms in C code, and figure out which Rust idioms to translate it into. But then use a hand-written translator (that you know will produce equivalent code) to actually convert the C to Rust, using the "strategy" laid out by the LLM. That way, if the LLM fails, you'll just get "weird" code that uses very different idioms than a human programmer would, but that still compiles and still produces the same result as the original C code.
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.
It always baffles me how completely oblivious the figure heads at the top can be. Of course, change is hard and costly, and in the beginning it always looks like things are not improving. But long term, the cost of not changing is always higher. It's like if a heavy smoker started going jogging, and then after like 3 days, decided that his lungs are in poor shape because of the exercise.
Is it fair to assume Theo never shipped a Rust-based project to production and maintained it? If so, it's interesting to see him speculating on something he has little to none experience.
This is not the solution they think it is. This is the equivalent of having an issue with your neighbor and contacting your congressman to help pass a law that makes it illegal for your neighbor to be annoying.
Unfortunately anything put forth by DARPA will fall on deaf ears by the majority of government. A great deal of development within the US government is done in silos, meaning things vary greatly by organization down to the individual offices. I was a government contractor for many years (3 different agencies, 6+ different departments within said agencies) and always heard the term "modernization" everywhere I went. It was 100% of the time lip service as budgets and office politics ALWAYS determined efforts. A whitepaper will not convince a GS14/15 or low-level SES to focus on modernizing or quality. The work that gets them recognized for a promotion will always win, and that never involves evolving tech, always how they used their budget.
I really hope they do a proper evaluation on LLMs and end up abandoning them as a technique option as suggested in the initial description of TRACTOR. We *NEED* provable correctness for a program that is designed on the premise that auto-converted C to Rust is going to be safer than the existing codebase. LLMs cannot give us mathematical certainty for their outputs.
@@thegoldenatlas753 because other methods for cross-compilation and translation are well tested and mathematically provable. That provability is critical when the entire reason for this exercise is security.
There is similar work happening around converting government mainframe assembly and COBOL to Java. The US government version of Rust is going to be something like being pinned to the 2015 Edition and being limited to a few security-approved packages/crates installed via a private git repository. Given that we're talking about auto-translated blobs of source code, the Rust source code will very likely be large and confusing monoliths with C shared-state and weak types mapped to Rust shared state and weak types. Getting to that point is really the "starting line" for refactoring, but federal leadership will likely view this as the "finished line." As you pointed out, the actual problem is that the Federal government does not view software development as a continuous and iterative process. Federal executives generally have very poor understanding of software because that work is outsourced, so it's lawyers and contract managers and policy enthusiasts that run everything.
At least in DoD, few 'important' systems can in fact be iterated, unless one considers deployments every 2-4 years (if you're lucky) 'iteration'. The closer you get to the pointy end of the spear, the longer the software deployment cycles, IME--except in a few restricted cases. It wasn't unusual to miss a deployment cycle because the platform wasn't available because it was redeployed to go blow something up or fill a gap due to some other mechanical failure. Furthermore the more extensive the changes, the more likely it is your accreditors will insist you go through much more extensive testing cycles, taking more time and increasing the risk in the schedule. Back in the day it was pretty amusing explaining to BigTek leetcrowds that iterative testing on missile software wasn't a good idea... they started out pretty officious and condescending towards us gubmint project managers and developers, and when it was pointed out that their 'majik bullits' weren't going to Solve World Peace they were kind of resentful. It's not like you can just push the "Reload" button over and over on the "Declare War!" web page... That being said for the stuff I was doing we'd demonstrated C2C24 (compile to combat in 24 hours) (circa 2019) on the sekret squirel system we were doing exercise demos for. Deployment these days (well, 'those' days) is rarely a technological problem, strictly speaking--it's thoroughness of testing & functional confidence and keeping various accreditation weenies happy. Good Times.
What DARPA really needs to do is to fire the small amount of bad programmers writing bad code. Just because rust is memory safe doesn't mean you can't introduce any bugs at all [It just means the bugs that you do introduce tend to be less critical] Also, I've heard from multiple different sources that You can leak memory in "safe" rust code. The only reason I haven't learned to rust is because C++ is just as memory safe [If with a slightly esoteric syntax] And compiles faster. And produces just as fast [if not faster] Binaries [I also find it really funny that modern c++ has all of the upsides that you praise Russ for having with none of the downsides and yet you seem like you would not call it a good language. (Maybe I'm wrong about that) I think the objective facts that you stated Are just a few reasons why they should be using rust.]
It’s interesting that the video starts with a screenshot of 404 error code and mentioning a government website as an example of bad government software. I thought this video was about moving from C to Rust. C is not used for web development.
@@anon_y_mousse I understand what you’re saying but that’s not what we’re talking about here. Show me 1 Web Development job post that lists C as a required skill.
@@grail9558 There aren't many, but they do exist. Although, most, but not all, jobs that require C and revolve around the web space are generally about maintaining old code, generally stuff that only runs on the server or is itself the server software.
I had a recruiter last year with the DOD ask if I could get a top level security clearance to do something rust related. I wonder now if this is what they were preparing for.
It's inaccurate to say all government dev cycles are waterfall, that is just not true. There are departments of the federal government that operate like agile startups. A notable mention specifically is the IRS.
I worked at a defense contractor from 2014 - 2016, and even back then we were already using agile. We were targeting IE8 also, and no other browser mattered for the DOD. But we were following modern development practices. There are probably some areas that go through what you've described but that was not the case for the software we worked on. Most of government software is contracted, that part was correct. But our teams were static. If the contract changed vendors, we changed employers. We stayed with the software, it did not go to a completely different team at a completely different company. Nor did we even have to change offices, we stayed at the same office even.
I noticed that, at least as far as dynamic memory safety, the government contractors I worked for had C projects that simply didn't include a heap. Even when there was an OS of some sort, this idea carried over to applications written on top of that. So there was no mallocing, and everything as much as possible was well defined so you could reasonably size the arrays.
@@anotherelvis we need to stop this myth that “it’s ok for top 10% developers (whatever that means) to use unsafe tools.” No amount of skill or experience prevents people from writing memory bugs in these languages. Tell me you’re inexperienced without telling me you’re inexperienced.
It's atleast better than nothing tho, a lot of bugs go away just from using rust, but yes they do still exist. But it's better if you have less bugs than more bugs xD Not saying rust is the holy grail, async rust sucks ass. That's a reason why Prime moved on
The reason Carbon is being developed is because C++ has been so successful that many of the people who maintained some projects are about to die + different times. C++ is amazing, it just needs a 'refresh' - which is the facelift Carbon is providing.
Why just "memory" safe? Kinda feel like logic and type safety are important as well. I always thought Go was unsafe because if you forget to do `if err != nil` every other line (hyperbolic but somewhat true), your program can break in unexpected ways. Type safe languages with exhaustive pattern matching force you to handle all scenarios and the compiler can catch more problems at compile time.
I guess null pointer exceptions causing crashes is less of a condidentiality/integrity risk than e.g. buffer overflows causing memory dumps or remote code execution? Obviously just as bad for the "availability" part of the infosec trinity, and the integrity of systems if not necessarily data.
Compile times for Rust always mentioned, but honestly it has gone thru big improvements over the last years, and it's not that bad anymore. I'm not saying it's light speed, but not nearly as inferior as it used to be.. especially if you're on Apple Silicon. Basically just don't use LTO and release level locally for development..
We already do/did this with haskell as the translator. You give Haskell the C code, and then it spits out IR, C, C--, and other languages. I guessing they're just using that in the background, but most programmers forgot.
And we were instructed by the government to move everything to type safe Ada over 30 years ago. Look at how well that went over. We really need to get over this fallacy that one language is good for all software and all software is basically the same. Polluting a language used to write operating systems and device drivers with features desired by web application developers is silly. If Rust is going to be used for operating systems and embedded software, it needs to be lean. No language designed by committee has ever been lean.
Oh, agreed that websites shouldn't be written in Rust. There are plenty of high-level garbage-collected languages that are better suited for that. But there is a lot of low-level code written in C that could probably benefit from being ported to Rust, however it is done. I could be wrong, but personally I think the failure of Ada is that it never achieved much traction outside of government contracting, and related fields. Rust is already quite successful, so I think it makes a lot of sense for the government to use a language that others are already using, rather than inventing their own as they did with Ada.
Rust is nice but has way too many flaws to be seriously considered for MANY companies and branches of the government. The Syntax is stupid, learning curve is high, and most importantly it doesn’t actually guarantee you write better code. You can still write bad code, and now it takes even longer to make it good. Not to mention compile time. It has good ideas but doesn’t execute on them well. It could be so much better, but Mozilla released it… like they did… a shame really
Rust syntax is not stupid, I find it better than C++ syntax - and I compare Rust to C++, not C, cause that's what it's close to, if you gonna replace something. There's things to like and things to dislike about Rust, its syntax is not bad at all. This move though, if true, is stupid. Replacing something that's proven like C with something flashy and brand new?
compilation time are NOT a problem for rust. - they're not as slow as you think - slow only the first compilation - when it compile it works a lot more with rust than other language (less debugging) - most of the viewever of this channel are web dev, and put web server starts up / hot reload with a compiled language, which have nothing to do together. Again, compile are rare for most rust programs and not that slow after the first time. imo, it's a small negative, which not important thanks to over rust positive like safety and types which allow for a far better likelihood of the program working and running like you want on the first try
If you don't know what hot reloading is or why Rust is utterly incapable of the same in terms of iteration speed, then go look it up. Web servers on the other hand can be kept up once they're running and iteration is as simple as :w on the file you're editing then alt+tab to the browser window.
My favorite thing about rust is how it's essentially just a functional programming language not calling itself functional... it just has all of the attributes of an FP. This is excellent, cause RUST is being adopted by people who secretly LOVE FP paradigms but hate the culture or perhaps even just the phrase "functional programming"
"Most devs reality," in a best case scenario, yields RUclips (or something like it). "Government Software," in a best case scenario, yields the Internet (or something like it). It would be awesome if these polarities could meet somewhere in the middle. I like watching RUclips... on the Internet.
so why not set rules for which, how, why and when things should be done? and there you go, rust is already obsolete in the hands of anyone who already has had such rules in place. fads like unsafe languages masquerading as safe ones get tiring -- and safety, mind you, is everything relating to the final product, not just whether you can do something "dangerous" in a language or not. hope the us gov't has fun with the code monkeys that can't even program strcpy() themselves.
Rust unsafe is not that crazy. It just add 5 possibility: - Dereference a raw pointer - Call an unsafe function or method - Access or modify a mutable static variable - Implement an unsafe trait - Access fields of a union When you use unsafe its on very defined part of the code, most of the time it one line. Project that allow unsafe code, require the code to be commented, with proof that its a still safe to do it that way. And that remove 0 mechanism that make Rust great. Also most people will never use unsafe code by themself.
I think it's not so much about Rust being safe, but rather Rust having the potential to work well with ML/LLMs. Nobody would touch those low-priority legacy C codebases otherwise. Too expensive. In this case it also won't matter how unreadable Rust code or generated Rust code is.
Even MS is rewriting some C# code for Office 365 in Rust. Why did they go with Rust? Well it could be that you get that memory safety without the additional memory overhead. This is the one question about adoption of Rust in the games industry I have - I don't know how they will deal with libraries - no 3rd party is going to want to ship a crate with source. So do you end up losing the benefit of cargo here?
In my opinion. A better approach would be to rewrite the legacy code. Rip it apart, analyse it, and then rebuild it. Transcompiling badly written legacy code from one language to another won't fix the core issue of nobody understanding said legacy code or said legacy code being badly written.
I’m a government contractor in software and let me tell you, it’s the opposite. There’s very little planning, mainly an idea or goal and devs start building, give a demo and the government tells us what they like and don’t. It’s highly agile.
Rust compile times being bad is not true these days. Have you tried compiling cpp proejct, it takes at least 5x for equivalent rust project. I literally work on huge application with layered caching system for data access and over at least million lines of rust. It takes like 30 seconds to compile after the first build, which takes like 3 minutes. The only language that has better compile times are Go and Jai.
I believe that the video by LLL is mostly satire. In the C community, it's widely known- as even cited in the man pages-that the proper way to manage strings is by using memory-safe versions of functions like strncpy instead of strcpy. The issue with C’s string handling is that C doesn’t inherently manage strings; they are simply pointers to characters, with the end of a string being indicated by a NULL terminator. Modern languages like Zig address this issue by incorporating bounds checking, but this is abstracted from developers and does add some overhead to the program's runtime, even if the cost is minimal.Ultimately, it comes down to how well you write your program and whether you understand dynamic memory allocation and memory safety, etc. However, I do agree that modern problems require modern solutions, and for these reasons, modern programming languages are often better suited to address these challenges.
The reason planning and building takes far longer for the government is that they feel they have to give account for every dollar wasted on a cancelled project done with taxpayer money, but they don’t have to account for money spent if it just took a lot longer and went way over budget but still got done.
Ada is used for embedded programming as far as I'm aware and the compiler is licensed for the particular use cases in aerospace etc if I'm not mistaken. But also, they do shit without ever communicating so could be
All of the contractors are like "sure you need to upgrade all of your C code to Rust, hire me!" Script2 (C++) compiles in 3 seconds and has an API for working with memory safely. We don't need Rust. We will port Script2 to Rust at some point as we are based on the ASCII Data Spec (AKA neo-ascii). I think the C/C++ code is just fine.
I mean, I don't think C++ compilation speeds are much better then Rust's, would love to see a good comparison. As for the C/C++ being good enough, well, it already exists and seems to be insufficient, and if real world analysis shows that Rust will be better then it's a good move.
@@basilefff No, it's just that people compile hundreds and thousands of translation units and that is really slow. One translation unit loads much faster. I use a 3-file header, on for a header with no code, one for header with code, and another for inline header implementation. I'm not sure how much this helps my compilation speed compared to single translation unit with inline header impl, but at one point in time it was faster..
@@basilefff C++ Has never been known for being nightmarish to maintain. C++ is harder to WRITE, but well defined systems are easier to maintain than loosely defined ones.
@@CaleMcCollough I disagree, I personally find making changes to SFINAE code dreadful. But I wasn't talking about C++ in general, I was talking about your system of 3 headers + (presumably) source files. It sounds like A LOT to maintain
Man I was laughing so hard because your breakdown of "government software" also applies to how projects worked in the military. They would send people from my infantry unit to test things at some other location halfway across the country for weeks. We'd hear nothing of it for years. Then we'd get some of the things, mostly ones that we weren't super excited for or wouldn't make a profound difference, out of nowhere and the original reason it was being made no longer exists or has changed. Now we have things we need to give some use to so the military higher-ups don't get blamed for waste spending.
The only way I see some future in Rust is if we get sufficient code migration tools. That way, a small change in design might result in an automatic conversion of the code into something that actually builds. Rust is just too low level, for people to actually write all code in. Satisfying the borrow checker is something people shouldn't actually do manually.
I just had a dream last night, Theo is a judge in Hackathon with a good teaching skills providing some ideas and stuff. man i watched a lot of your video for this to occur
@@RustIsWinning they have it cause your rust is glued to C. i know what are cve and everyone with a beain can avoid creating vurnerabilities. it is the prigrammer's responsibility to not screw up. now go back scripting, i have some programming to do.
@@RustIsWinning lmaoooo, no arguments, claim your opponent is a clown and slip aside like the worm you are. also i cry with my paycheck as an embedded engineer.
Gotta be honest. Imo you’re wrong about slower Rust iteration. The mental model for rust is at least 6x more expensive to get comfortable in than js, but once you do it’s just as fast. We’re not gonna talk about compile time tho lol
I avoid naked pointers like the plague. I know I am going to mess them up. It is okay for the language to have a Unsafe block, when I absolutely, 100% positively cannot _avoid_ handling naked pointers. But I should not be handling them by default, just making a Array!
Rust is not just a different syntax, it requires a totally different application architecture to play nice with the borrow checker. That is why most C programs can’t simply be translated to Rust, they need to be reworked almost from scratch. C developers LOVE to use globals / singletons and those are simply not applicable in Rust. However Rust is quite friendly to the Go way of writing programs where different parts of the program communicate using channels. Unless the government is doing embedded software I think they would benefit more from using Swift or Go.
I found myself using rust for 3y but dropped it due to all my functions being macros that have its memory safety conpromised due to performance. Rust is ideal as it enables utilization of resources junior programmers are able to privide for our team.
its an exploratoy project; to investigate developing a system that can perform the translation of c to rust; not to actually neccesarily rewriteite and put into production that rust code. They want to understand the feasibility and efficacy of systems such as an llm to convert between languages.
(I know this is my second comment but...) WTF Do You mean no binaries i n cargo, from what I heard of the JS npm does NOT have "pre-compiled" package either( I may be wrong from I haven't used it is a long time) and You just minify and pack everything into a bundle (in most cases) or pull it from an cdn, isn't that exactly the same, exlusing the compilation part becase JS has need for that(as far as I know)....
@@t3dotgg That is true, and that is nice, it abstract away complexity of development, like in most cases. Like you aren't building sdl2 from source when you `cargo add sdl2`, in most cases it's just binding to native library(You can built it from source too if you want). And adding pre-compiling binaries is defently a good way of abstracting away some complexity of having to manuly link/donload libraries. Also gobal libraries are (generally) a bad thing so on that matter it's good too, less version conflicts.
rust can't save you from bad programmers
It makes it so that there are far less ways for a bad programmer to cause problems, and eliminates all the serious problems
The folly of JavaScript some might say is that it stopped gatekeeping coding from from bad programmers
It can save you from 70% of security bugs which are due purely to memory safety issues.
@@Jason9637 Hahahahahahahhhahaha ahahahahaha. Thanks I needed that good laugh
@@tylerknight99As a bad programmer, I concur. But man, JS allows you to get away with such insane amounts of stuff that wouldn't fly in any other language that I kinda have a soft spot for it.
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.
government everywhere is the same i think they just do it to extract the money even my government does the same lol
Works out if you've got people who like to work for free :)
Lol the people do the work for free and they pocket 17 million. Good job!
It sounds like the Czech Republic learned from Google and their Summer of Code program (and hackathons). And, of course, Google is not the only company sponsoring hackathons. That said, imagine if we trained doctors by having them hack for free on people before they were licensed. Ignoring the disturbing connotations of unqualified surgeons, I'll point out that some of the software hackathon participants are among the best programmers I've seen, particularly in the hackathons where professional programmers participate because they are short and over a weekend.
@@ascensionacademy3418 "they" being tax payers... Somehow that's a bad thing?
@7:00 The RUclips 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.
That's interesting, because one of the things that's been keeping me back from really diving into coding at all, is that constant need to create updates. I mean, if the update is truly needed, then so be it, but otherwise that 'finished' aspect sounds nice.
His videos are good, but his rust bias is ridiculous. That statement right there is one the stupidest things he’s ever said
I think some zealots are required to push forward new standards.
@@LoneHawk You are correct, but this particular take is very close to the truth: When your end goal is strictly defined, it is possible for a software package to reach a stage where it is done and needs no maintenance. Rust makes this easier than most other languages because it guarantees you that you haven't made any memory related bugs or exploits. Of course you can still have bugs in the behavior of your solution, or requirements might change, or Rust might eventually reach a point where they need to make a breaking change.
This also applies to other languages, you'll just have a higher barrier to reach "done" and dependencies are often more volatile due to the chicken and egg problem (if it's harder to reach "done" then your dependencies are more likely to go through breaking changes which means your package will also need updates to leverage the improvements in your dependencies)
You will never get javascript developers to accept this.
"This library is dead, it hasn't been updating in years"
"But its a test-passing implementation for a spec that hasnt been updated in a decade"
"No, it needs constant updates!"
The US Government literally just said: "Let's rewrite C in Rust"
And 500billion dollars later, the effort has lead to more bugs than before and/or it is abandoned.
@@niclash Still Better than the military
@@Mempler Yeah, I forgot that the military needs an additional trillion dollars or two to do the same for all mil software.
@@Mempler DARPA is pretty military adjacent.
Army uses LISP I think
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)
*Will Roper - Mark Rober is the popsci RUclipsr. Thanks, will check it out!
@@nibblrrr7124 good catch
Fed contracts at my company are still usually fixed scope but state and local municipalities love having us use continuous delivery to get critical functions rock solid.
I do think for non safety critical code a more iterative approach would be advantageous. One of the major problems with this style of writing software is that it is very hard to adapt it to changing requirements. What happens is that fed up users develop hacks and kludges to half implement new features because it's too expensive to update the code. They may even end up using the software for things it wasn't intended for just because it's too expensive and burdensome to do things properly. This goes on until everything becomes such a tangled mess the government is finally persuaded to fund an upgrade.
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
habits are hard to die, people for a long time used the old methods and most resources are for the old methods therefore people will keep using these same old bad habits.
@@maxrinehart4177 and I’ll steal their job because of their skill issues
The issue is not that there's no way to write memory safe programs, its that you CAN write memory unsafe code. Using Rust makes sure nobody has to manually go through and verify everyone's code to make sure it's ok, because the compiler does that automatically.
@@P-39_AiracobraNobody is "manually going through and verifying" code. Safety has been a solved issue in C/C++ for a long time. All of this is automated. We don't worry about this at all, which is why we didn't adopt Rust over the past decades, you know. Our problems are maintainability and interoperability. Rust is pretty much the last thing C/C++ engineers want. This detached-from-reality online-hype culture is really messing with people.
@@P-39_Airacobra > Using Rust makes sure nobody has to manually go through and verify everyone's code to make sure it's ok, because the compiler does that automatically.
This is a fallacy. Rust prevents some memory safety concerns but it does not prevent unsanitized input, memory leaks or unchecked uninitialized memory.
On top of that, if you need something to be more performant and effcient, chances are that you have to resort to unsafe code in some cases - this does not mean unchecked code, but it does mean that it's allowed to work with the raw pointers and the compiler can only help you in very specific cases.
Write any type of cyclic data structure in Rust, and you'll likely come to the conclusion that it's not that easy without some unsafe code, or end up with less than much less efficient solution due to the compiler adding additional runtime checks.
What Rust does help with is manage unsafe code in blocks, rather than globally. But it does not prevent it.
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.
I wish ElasticSearch was not written in Java
Or goddamn jenkins @@JoseHenrique-xg1lp
@@JoseHenrique-xg1lpOk, why? Its not like it has the same memory security concerns as c or c++ as it is a gc language. Are you worries about null pointers or something? Or is the speed just too slow for you?
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
Fascinating. Is there a word for this kind of thing, or more examples? I.e. guessing/reinterpreting why something was given a certain proper name, and which symbolism or metaphor the author intended to evoke. It's a special case of folk/false etymology, closely related to backronym, and maybe in the same ballpark as retronym and dead metaphor.
@@nibblrrr7124 sort of like Python being named for Monty Python, yet using snakes for the logo.
@@nibblrrr7124there actually is one in linguistics, i cant think of it right now though i will do some googling
And, the creator of Rust is disappointed with the current state of Rust, Rust didn't have to be complex, with every feature imaginable. They ruined Rust by taking it in the direction of C++
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.
Rust cult infiltrated the government, RuSt iS SaFe LaNguaGe.
Stop thinking and drink the cool aid
It's pretty easy to translate C to Rust Code, people like you didn't even tried it once but have strong opinions xD Makes no sense. Because of Rusts abstractions it's even less Code in the end
@@ITSecNEO Yeah no lol. In C we make our own data structures and string types. Even just determining wether to rewrite those to the Rust builtins or keep the bespoke implementation is an incredibly complex decision.
Then you have pointer-heavy code, gotos, longjumps, custom allocators, platform-specific data types, opaque structs, inline assembly...
And then in rust you need to reachitect the entire application to make use of traits, pattern matching, operator overloading, slices, modules etc, all while appeasing the borrow checker. It's not happening.
@@pokefreak2112 You can already transpile C to (unsafe) Rust - all you have to do then is to go through all that generated code and convert it to idiomatic and safe Rust. It's a lot of work, yes but also very doable and many have done so actually. It's one of the standard Rust challenges to convert some legacy C-lib to Rust ;)
Also not all code will be difficult, that really depends.
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
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.
You're just built different. I can go way faster in Go for web services. I can write Rust... just not good Rust.
@@OldKing11100 Its difficulty is always overstated. The trick is having learned patterns and not unnecessarily complicating your solution.
Yeah I don't buy it either. The only thing that is slow is a full build. But the programming workflow in rust is more compiler driven than "compile and then run it" driven. So if you are doing rust "right", you are spending a lot of your time doing incremental compiles and modeling your data in a way that if it compiles it probably works first try. You fix most of your issues by fighting with the compiler on an incremental build until it doesn't give you errors (errors that would have happened at runtime in another language). And that loop is fast. You still run tests, but it isn't the 90% of your time that a traditional test heavy workflow is in another language.
@@OldKing11100a lot of it is just getting used to it and getting your flow down I used to be faster in python but I can now do better rust code in the same time as python. In the end it takes time to get to the speed of a lang you’ve been using for awhile
i feel the same way as well. i think initially it can be slower but once you get comfortable it's fairly fast. i'm faster with go but i prefer writing rust code.
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.
A lot of the US military has been using Ada for a long time
That's literally why Ada was created.
using LLMs is a very shitty idea, you have to re-write it by hand.
Or Good Old-Fashioned AI that actually proves equivalence according to specified criteria, using search and formal logic. LLMs might actually be a great way to provide better heuristics (i.e. possible solutions to try out), but I hope it doesn't mostly rely on it end-to-end. Automated theorem proving & co aren't as sexy, so maybe they wanted to benefit from the ML hype?
It might work if they parse the C to an abstract syntax tree, use LLM to convert to a Rust abstract syntax tree, then render to Rust source. The C preprocessor will give them grief. I wrote a 6000 subroutine C program that converted a domain specific language to another DSL and preserved the conditional compilation from the preprocessor. I was lucky that both had a preprocessor. Rust does not.
I think they put it for the buzz effect
@@JeffBartlett-kj6sq rust does have a preprocessor, its macro system, and it sits somewhere between a traditional c style tokenizer and template expansion build tools found in c++, but it also extends beyond that in its expressiveness. a famous example is a macro from a library that takes in an SQL query, tests it for correctness, and then produces rust code to express that query, all within rust's build tools.
Don’t judge LLM’s based on prior experience if it’s not recent, I find gpt4o to actually write very decent code. Especially if I get it to debug itself. Literally 10x faster than I can actually even type it myself
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.
They will use an LLM… what could go wrong
I find rust iteration time at least for proper code is actually pretty fast. Also the slowness is really only on the first builds after the first are pretty dang fast. As for the making a function that wasn’t async async the big question is why didn’t you just code it async in the first place? Pretty much haven’t touched sync rust since I started learninh
Some projects were started before async
Meh, add enough crates in and create enough or your own macros and structure and it just gets slower and slower.
You should still do fully raw builds for production code
Sync is better in some ways if you're not really going to be I/O bound, and because of the way async code is internally represented it tends to make compile times absolutely explode on large projects if you're not careful to set up some boundaries to prevent the type explosion
@@Vin50000 That is the default behavior in Cargo
You had me at “the software engineering community has reached a consensus”.
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
@@_stix That's not a real solution. If you think like this developers will do the bare minimum to comply with whatever quality standard they're being held to and won't put in any effort beyond that. If you want actually good software you should create an environment where developers feel intrinsically motivated to do a good job, fast compile times are a part of that.
@@pokefreak2112 Keep in mind that unless you have a truly massive codebase, most of the compile time will be spent on your dependencies. Because Rust uses incremental compilation, you only have to compile those dependencies once, so the effect on iteration speed isn't as high as it seems.
You clocking out for compile times or passing that cost onto your customer? If the latter, I bet the customer cares.
@@pokefreak2112I never have been in an environment where I am intrinsically motivated to do a good job. I still exceed expectations even when I have to fight the behemoth so I am allowed to do the right thing. Maybe that’s because I am a professional and take pride in my skills and craft. I don’t know what you are smoking.
@@kiseitai2 Pride is an intrinsic motivator.
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)
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.
Go or (procedural-style) Java/C# would at least be more straightforward to translate, if your main concern is memory safety. Though, given my near-zero experience with production C code, maybe I'm underestimating how often it involves actually clever pointer pro gamer moves, instead of just implementing string processing and trees etc. the hard way. Embedded probably more often, and there the performance hit of these VM languages would be a concern. In either case, there you'd also have trouble translating those into Rust.
Those kinds of tools already exist for C anyway, both static and dynamic analysis. The paper makes the disingenuous argument that such tools aren't enough even though they're already better than what the Rust compiler provides and more feature complete.
No where does it state that they are "better".
@@jakelexington7610 Was that supposed to be directed at me, because I see no one else even using the word better. If it was, then you may need to reread what I wrote to come to actually understand it.
@@nibblrrr7124 I have a lot of experience with production C code, and it tends to do lots of things like casting pointers to integers and back, or using unions (sometimes just to optimize storage, but sometimes for type punning purposes). And all sorts of other stuff. Even well-written code would be difficult to translate, and the majority of "production" C code I've seen (especially if it's been around a while) is quite horrifying.
There's also the fact that Go, Java, and C# use a garbage collector. C uses manual memory management, which is inherently unsafe (e. g. use-after-free bugs). Rust makes manual memory management safe, but to do so it requires coding in a certain way, and adding a lot of annotations to code (i. e. "borrowing" versus ownership).
What ever happened to Ada?
That was the Federal government's previous effort at software security / standardization.
It's actually a pretty nice language.
It's mainly used by the military for on board computers in vehicles, from what I've seen, I have not seen it being used in other government branches, mainly Java and C/C++ for their projects.
I believe it was phased out because it was an incredible pain to code in it. I remember it took 45 minutes to compile a 300 line programs. Granted it was when the student were all compiling simultaneously. It's still longer than C.
Once Borland came up with TurboC, everything else faded into obscurity.
that's what happens when unsupervised childrens get access to an unlimited supply of money: let's rewrite 1 million lines of legacy code that already works using an llm technology that doesn't exist yet and needs to be funded(gpt cant convert 1m+ lines), even if it introduces a thousand new potential points of failure, since the code needs to be rewritten in its entirety by a black box AI transpiller
Define “already works.” They’ve clearly identified the millions of lines of legacy code as a national defense liability. Do you want our power grid, communication systems, weapon systems, etc. running millions of lines of code riddled with exploitable memory bugs? The number of domestic and foreign cyber attacks will only increase going forward, and I would prefer our critical infrastructure to not be so vulnerable, thanks. Read up on DARPA. They have pulled off some of the greatest technological innovations in history. I’m very glad that people much smarter than you and me are trying to tackle these issues, just let them cook.
Yeah, that’s the part that worries me but attempting to refactor as much of the C stack as possible is not a bad idea. I just don’t agree with using llms. They obviously do not understand machine learning.
@@kiseitai2 "attempting to refactor as much of the C stack as possible is not a bad idea"
as I said, if a billion lines of legacy code already works, why would you even think about changing it. there's nothing wrong with c. why waste the taxpayers money funding something useless that doesn't even need to exist when there's so much inflation going on for example
Well, it's DARPA. If it isn't filled to the brim with scientists given all the moneys and told to channel their wildest ideas into something plausibly useful for the Pentagon, then what in the world are they actually doing?
And I will also remind you that they have a bunch of AI powered projects in the works from Wikipedia, let alone stuff that's classified.
Are they going to prove that the translator works?
16:08 What I've noticed is that LLMs can tell you the rules of Rust but it sucks at following them. It will therefore give you code that won't compile.
Sounds like a training issue
I don't know how they're planning to do it, but personally I would use LLMs to recognize idioms in C code, and figure out which Rust idioms to translate it into. But then use a hand-written translator (that you know will produce equivalent code) to actually convert the C to Rust, using the "strategy" laid out by the LLM. That way, if the LLM fails, you'll just get "weird" code that uses very different idioms than a human programmer would, but that still compiles and still produces the same result as the original C code.
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.
It always baffles me how completely oblivious the figure heads at the top can be. Of course, change is hard and costly, and in the beginning it always looks like things are not improving. But long term, the cost of not changing is always higher.
It's like if a heavy smoker started going jogging, and then after like 3 days, decided that his lungs are in poor shape because of the exercise.
LLM can't even generate rust codes that compiles most of the time
I believe there’s a good saying to fit rust development: “Good things take time”
Is it fair to assume Theo never shipped a Rust-based project to production and maintained it? If so, it's interesting to see him speculating on something he has little to none experience.
This is not the solution they think it is. This is the equivalent of having an issue with your neighbor and contacting your congressman to help pass a law that makes it illegal for your neighbor to be annoying.
Unfortunately anything put forth by DARPA will fall on deaf ears by the majority of government. A great deal of development within the US government is done in silos, meaning things vary greatly by organization down to the individual offices. I was a government contractor for many years (3 different agencies, 6+ different departments within said agencies) and always heard the term "modernization" everywhere I went. It was 100% of the time lip service as budgets and office politics ALWAYS determined efforts. A whitepaper will not convince a GS14/15 or low-level SES to focus on modernizing or quality. The work that gets them recognized for a promotion will always win, and that never involves evolving tech, always how they used their budget.
"Spanish and Hindi are the safest languages, we are trying to move away from English because of ideological leakage" - US government
IDK about Spanish, but as to Hindi: Maya OS.
Atleast hindi is phonetic so you don't have different pronunciation for similar spellings
I really hope they do a proper evaluation on LLMs and end up abandoning them as a technique option as suggested in the initial description of TRACTOR. We *NEED* provable correctness for a program that is designed on the premise that auto-converted C to Rust is going to be safer than the existing codebase. LLMs cannot give us mathematical certainty for their outputs.
LLMs is only one suggested option. I don't get why the comments are full of people thinking its just an LLM.
@@thegoldenatlas753 because other methods for cross-compilation and translation are well tested and mathematically provable. That provability is critical when the entire reason for this exercise is security.
There is similar work happening around converting government mainframe assembly and COBOL to Java.
The US government version of Rust is going to be something like being pinned to the 2015 Edition and being limited to a few security-approved packages/crates installed via a private git repository. Given that we're talking about auto-translated blobs of source code, the Rust source code will very likely be large and confusing monoliths with C shared-state and weak types mapped to Rust shared state and weak types.
Getting to that point is really the "starting line" for refactoring, but federal leadership will likely view this as the "finished line."
As you pointed out, the actual problem is that the Federal government does not view software development as a continuous and iterative process. Federal executives generally have very poor understanding of software because that work is outsourced, so it's lawyers and contract managers and policy enthusiasts that run everything.
At least in DoD, few 'important' systems can in fact be iterated, unless one considers deployments every 2-4 years (if you're lucky) 'iteration'. The closer you get to the pointy end of the spear, the longer the software deployment cycles, IME--except in a few restricted cases. It wasn't unusual to miss a deployment cycle because the platform wasn't available because it was redeployed to go blow something up or fill a gap due to some other mechanical failure. Furthermore the more extensive the changes, the more likely it is your accreditors will insist you go through much more extensive testing cycles, taking more time and increasing the risk in the schedule.
Back in the day it was pretty amusing explaining to BigTek leetcrowds that iterative testing on missile software wasn't a good idea... they started out pretty officious and condescending towards us gubmint project managers and developers, and when it was pointed out that their 'majik bullits' weren't going to Solve World Peace they were kind of resentful. It's not like you can just push the "Reload" button over and over on the "Declare War!" web page...
That being said for the stuff I was doing we'd demonstrated C2C24 (compile to combat in 24 hours) (circa 2019) on the sekret squirel system we were doing exercise demos for. Deployment these days (well, 'those' days) is rarely a technological problem, strictly speaking--it's thoroughness of testing & functional confidence and keeping various accreditation weenies happy.
Good Times.
Slow development of governmental programs just took on a new meaning.
Wait, Java, C# & Python are "safe" but Go isn't?
In 2024, LLMs are as about as good at writing rust as they are at telling you how to drive a car.
What DARPA really needs to do is to fire the small amount of bad programmers writing bad code. Just because rust is memory safe doesn't mean you can't introduce any bugs at all [It just means the bugs that you do introduce tend to be less critical]
Also, I've heard from multiple different sources that You can leak memory in "safe" rust code.
The only reason I haven't learned to rust is because C++ is just as memory safe [If with a slightly esoteric syntax] And compiles faster. And produces just as fast [if not faster] Binaries
[I also find it really funny that modern c++ has all of the upsides that you praise Russ for having with none of the downsides and yet you seem like you would not call it a good language. (Maybe I'm wrong about that) I think the objective facts that you stated Are just a few reasons why they should be using rust.]
It’s interesting that the video starts with a screenshot of 404 error code and mentioning a government website as an example of bad government software. I thought this video was about moving from C to Rust. C is not used for web development.
Not predominately, but it is on occasion used for web development. There are transpilers that convert to JS as well as compilers to wasm.
@@anon_y_mousse I understand what you’re saying but that’s not what we’re talking about here. Show me 1 Web Development job post that lists C as a required skill.
@@grail9558 There aren't many, but they do exist. Although, most, but not all, jobs that require C and revolve around the web space are generally about maintaining old code, generally stuff that only runs on the server or is itself the server software.
Dang, so where do I get me one of them lucrative Government Contract writing Rust?
I had a recruiter last year with the DOD ask if I could get a top level security clearance to do something rust related. I wonder now if this is what they were preparing for.
usajobs.gov, sam.gov if you are the contracting company
@@grantgreer6525 which one?
Surely the problem isn't the language but the developers/consultants they contracted to develop the systems?
It's inaccurate to say all government dev cycles are waterfall, that is just not true. There are departments of the federal government that operate like agile startups. A notable mention specifically is the IRS.
I worked at a defense contractor from 2014 - 2016, and even back then we were already using agile. We were targeting IE8 also, and no other browser mattered for the DOD. But we were following modern development practices. There are probably some areas that go through what you've described but that was not the case for the software we worked on. Most of government software is contracted, that part was correct. But our teams were static. If the contract changed vendors, we changed employers. We stayed with the software, it did not go to a completely different team at a completely different company. Nor did we even have to change offices, we stayed at the same office even.
makes me wonder how safe "tractor" is...
I noticed that, at least as far as dynamic memory safety, the government contractors I worked for had C projects that simply didn't include a heap. Even when there was an OS of some sort, this idea carried over to applications written on top of that. So there was no mallocing, and everything as much as possible was well defined so you could reasonably size the arrays.
python and javascript are written with C
Python has parts of it being rewritten in rust actually.
think they'll change the the dollar bill to "in rust we trust"? =D
Code safety starts with the person writing the code. Rust is not going to change that.
🎯
Big companies such as Microsoft don't have enough top 10% programmers, so Rust is a great choice for them.
@@anotherelvis we need to stop this myth that “it’s ok for top 10% developers (whatever that means) to use unsafe tools.”
No amount of skill or experience prevents people from writing memory bugs in these languages. Tell me you’re inexperienced without telling me you’re inexperienced.
It's atleast better than nothing tho, a lot of bugs go away just from using rust, but yes they do still exist. But it's better if you have less bugs than more bugs xD
Not saying rust is the holy grail, async rust sucks ass. That's a reason why Prime moved on
The reason Carbon is being developed is because C++ has been so successful that many of the people who maintained some projects are about to die + different times. C++ is amazing, it just needs a 'refresh' - which is the facelift Carbon is providing.
Wrong
@@jakelexington7610 disagree
Why just "memory" safe? Kinda feel like logic and type safety are important as well. I always thought Go was unsafe because if you forget to do `if err != nil` every other line (hyperbolic but somewhat true), your program can break in unexpected ways. Type safe languages with exhaustive pattern matching force you to handle all scenarios and the compiler can catch more problems at compile time.
I guess null pointer exceptions causing crashes is less of a condidentiality/integrity risk than e.g. buffer overflows causing memory dumps or remote code execution? Obviously just as bad for the "availability" part of the infosec trinity, and the integrity of systems if not necessarily data.
Memory safety accounted for 70% of all major vulnerabilities.
Compile times for Rust always mentioned, but honestly it has gone thru big improvements over the last years, and it's not that bad anymore. I'm not saying it's light speed, but not nearly as inferior as it used to be.. especially if you're on Apple Silicon. Basically just don't use LTO and release level locally for development..
I’m a fed and I write rust.
This is not everywhere just yet.
I think it may be soon.
guy actually just said "hi, i glow"
@@freedomgoddess glow red white and blue
@Fedsmoker
come deal with this man
@@Thegamecheats RIP
ruclips.net/video/bx4TZAm7o-E/видео.htmlsi=xluqjVUCUnOyIwJT
Can you please let us know when the legacy COBOL stuff the nice tax people use will be migrated. Again.
We already do/did this with haskell as the translator. You give Haskell the C code, and then it spits out IR, C, C--, and other languages. I guessing they're just using that in the background, but most programmers forgot.
And we were instructed by the government to move everything to type safe Ada over 30 years ago. Look at how well that went over. We really need to get over this fallacy that one language is good for all software and all software is basically the same. Polluting a language used to write operating systems and device drivers with features desired by web application developers is silly. If Rust is going to be used for operating systems and embedded software, it needs to be lean. No language designed by committee has ever been lean.
Oh, agreed that websites shouldn't be written in Rust. There are plenty of high-level garbage-collected languages that are better suited for that. But there is a lot of low-level code written in C that could probably benefit from being ported to Rust, however it is done.
I could be wrong, but personally I think the failure of Ada is that it never achieved much traction outside of government contracting, and related fields. Rust is already quite successful, so I think it makes a lot of sense for the government to use a language that others are already using, rather than inventing their own as they did with Ada.
Rust is nice but has way too many flaws to be seriously considered for MANY companies and branches of the government. The Syntax is stupid, learning curve is high, and most importantly it doesn’t actually guarantee you write better code. You can still write bad code, and now it takes even longer to make it good. Not to mention compile time.
It has good ideas but doesn’t execute on them well. It could be so much better, but Mozilla released it… like they did… a shame really
@@RustIsWinning skill that you and every other vegan fanatic don't have.
Rust syntax is not stupid, I find it better than C++ syntax - and I compare Rust to C++, not C, cause that's what it's close to, if you gonna replace something. There's things to like and things to dislike about Rust, its syntax is not bad at all. This move though, if true, is stupid. Replacing something that's proven like C with something flashy and brand new?
Unfortunately waterfall is used outside of the government as well :/.
compilation time are NOT a problem for rust.
- they're not as slow as you think
- slow only the first compilation
- when it compile it works a lot more with rust than other language (less debugging)
- most of the viewever of this channel are web dev, and put web server starts up / hot reload with a compiled language, which have nothing to do together. Again, compile are rare for most rust programs and not that slow after the first time.
imo, it's a small negative, which not important thanks to over rust positive like safety and types which allow for a far better likelihood of the program working and running like you want on the first try
If you don't know what hot reloading is or why Rust is utterly incapable of the same in terms of iteration speed, then go look it up. Web servers on the other hand can be kept up once they're running and iteration is as simple as :w on the file you're editing then alt+tab to the browser window.
My favorite thing about rust is how it's essentially just a functional programming language not calling itself functional... it just has all of the attributes of an FP.
This is excellent, cause RUST is being adopted by people who secretly LOVE FP paradigms but hate the culture or perhaps even just the phrase "functional programming"
"Most devs reality," in a best case scenario, yields RUclips (or something like it). "Government Software," in a best case scenario, yields the Internet (or something like it). It would be awesome if these polarities could meet somewhere in the middle. I like watching RUclips... on the Internet.
The automatic translation is probably a small research project that supports a larger goal.
3:46 So why not have an alternative standard library without all those unsafe functions? Just crazy anyone would ever use strcpy today...
so why not set rules for which, how, why and when things should be done? and there you go, rust is already obsolete in the hands of anyone who already has had such rules in place. fads like unsafe languages masquerading as safe ones get tiring -- and safety, mind you, is everything relating to the final product, not just whether you can do something "dangerous" in a language or not.
hope the us gov't has fun with the code monkeys that can't even program strcpy() themselves.
Thumbs up for including sources in the description!
Surely there's no unsafe code in rust codebases
Rust unsafe is not that crazy. It just add 5 possibility:
- Dereference a raw pointer
- Call an unsafe function or method
- Access or modify a mutable static variable
- Implement an unsafe trait
- Access fields of a union
When you use unsafe its on very defined part of the code, most of the time it one line. Project that allow unsafe code, require the code to be commented, with proof that its a still safe to do it that way.
And that remove 0 mechanism that make Rust great.
Also most people will never use unsafe code by themself.
I think it's not so much about Rust being safe, but rather Rust having the potential to work well with ML/LLMs. Nobody would touch those low-priority legacy C codebases otherwise. Too expensive. In this case it also won't matter how unreadable Rust code or generated Rust code is.
@@dryk-sdjberg surely LLMs are safe
@@koteelok2014 Let's give up and stop securing our IT systems. It is too difficult.
People always misunderstand unsafe word in rust bruh
Even MS is rewriting some C# code for Office 365 in Rust. Why did they go with Rust? Well it could be that you get that memory safety without the additional memory overhead.
This is the one question about adoption of Rust in the games industry I have - I don't know how they will deal with libraries - no 3rd party is going to want to ship a crate with source. So do you end up losing the benefit of cargo here?
In my opinion. A better approach would be to rewrite the legacy code. Rip it apart, analyse it, and then rebuild it.
Transcompiling badly written legacy code from one language to another won't fix the core issue of nobody understanding said legacy code or said legacy code being badly written.
I’m a government contractor in software and let me tell you, it’s the opposite. There’s very little planning, mainly an idea or goal and devs start building, give a demo and the government tells us what they like and don’t. It’s highly agile.
And there I was going back to programming in C and really enjoying its simplicity
Try Go. Similar feel, government approved. 😊
Same, have you ever noticed all the fad languages evolved to look like c over time?
Rust compile times being bad is not true these days. Have you tried compiling cpp proejct, it takes at least 5x for equivalent rust project. I literally work on huge application with layered caching system for data access and over at least million lines of rust. It takes like 30 seconds to compile after the first build, which takes like 3 minutes. The only language that has better compile times are Go and Jai.
They were using Ada and then switched off it. And NOW they want safe code and compile time checks??? Please!
I believe that the video by LLL is mostly satire. In the C community, it's widely known- as even cited in the man pages-that the proper way to manage strings is by using memory-safe versions of functions like strncpy instead of strcpy. The issue with C’s string handling is that C doesn’t inherently manage strings; they are simply pointers to characters, with the end of a string being indicated by a NULL terminator. Modern languages like Zig address this issue by incorporating bounds checking, but this is abstracted from developers and does add some overhead to the program's runtime, even if the cost is minimal.Ultimately, it comes down to how well you write your program and whether you understand dynamic memory allocation and memory safety, etc. However, I do agree that modern problems require modern solutions, and for these reasons, modern programming languages are often better suited to address these challenges.
The reason planning and building takes far longer for the government is that they feel they have to give account for every dollar wasted on a cancelled project done with taxpayer money, but they don’t have to account for money spent if it just took a lot longer and went way over budget but still got done.
imagine artificially pushing a language which calls the same processor instructions, just does it the other way round - and naming it a revolution
LLMs can't convert code to rust in many instances. they'll tell you rust is too difference. Opus had the best output for me for rust though
Is this a parallel story to US DoD and Ada?
Ada is used for embedded programming as far as I'm aware and the compiler is licensed for the particular use cases in aerospace etc if I'm not mistaken.
But also, they do shit without ever communicating so could be
All of the contractors are like "sure you need to upgrade all of your C code to Rust, hire me!" Script2 (C++) compiles in 3 seconds and has an API for working with memory safely. We don't need Rust. We will port Script2 to Rust at some point as we are based on the ASCII Data Spec (AKA neo-ascii). I think the C/C++ code is just fine.
I mean, I don't think C++ compilation speeds are much better then Rust's, would love to see a good comparison.
As for the C/C++ being good enough, well, it already exists and seems to be insufficient, and if real world analysis shows that Rust will be better then it's a good move.
@@basilefff No, it's just that people compile hundreds and thousands of translation units and that is really slow. One translation unit loads much faster. I use a 3-file header, on for a header with no code, one for header with code, and another for inline header implementation. I'm not sure how much this helps my compilation speed compared to single translation unit with inline header impl, but at one point in time it was faster..
@@CaleMcCollough I mean, sounds insane and nightmarish to maintain, but if the benefit is there, nice
@@basilefff C++ Has never been known for being nightmarish to maintain. C++ is harder to WRITE, but well defined systems are easier to maintain than loosely defined ones.
@@CaleMcCollough I disagree, I personally find making changes to SFINAE code dreadful. But I wasn't talking about C++ in general, I was talking about your system of 3 headers + (presumably) source files. It sounds like A LOT to maintain
Man I was laughing so hard because your breakdown of "government software" also applies to how projects worked in the military. They would send people from my infantry unit to test things at some other location halfway across the country for weeks. We'd hear nothing of it for years. Then we'd get some of the things, mostly ones that we weren't super excited for or wouldn't make a profound difference, out of nowhere and the original reason it was being made no longer exists or has changed. Now we have things we need to give some use to so the military higher-ups don't get blamed for waste spending.
So guaranteed jobs for Rust developers for the next 10 years?
The only way I see some future in Rust is if we get sufficient code migration tools. That way, a small change in design might result in an automatic conversion of the code into something that actually builds.
Rust is just too low level, for people to actually write all code in. Satisfying the borrow checker is something people shouldn't actually do manually.
No zig ?
Government: Let's be proactive in out cyber security.
Me: Cool
Government: We are going to use AI to do it. *facepalm*
You can write bad code in any programming language, that said I'm interested to see how this works out. Great video 👍
Hopefully this goes better than when they tried to mandate Ada for everything back in the 1990s.
The rust build times really aren’t that bad
they can't even build a web site and you think they'll build this?
Please Google what DARPA is before commenting
@@williamkaiser6075thanks for this comment, I didn’t knew
I've never touched rust, but from your description of the language, it sounds like it could have been purpose built for dod
Surprised you didn't mention cobol as well.
I just had a dream last night, Theo is a judge in Hackathon with a good teaching skills providing some ideas and stuff. man i watched a lot of your video for this to occur
If there are vurnerabilities, you sure did those, not the language.
@@RustIsWinning what a looser, or better, what an impostor!
@@RustIsWinning lol i,m not even 30 and still this rust revolution isn't happenjng. good luck converting linked lists.. internet is built on those 😁
@@RustIsWinning they have it cause your rust is glued to C. i know what are cve and everyone with a beain can avoid creating vurnerabilities. it is the prigrammer's responsibility to not screw up. now go back scripting, i have some programming to do.
@@RustIsWinning lmaoooo, no arguments, claim your opponent is a clown and slip aside like the worm you are. also i cry with my paycheck as an embedded engineer.
Gotta be honest. Imo you’re wrong about slower Rust iteration. The mental model for rust is at least 6x more expensive to get comfortable in than js, but once you do it’s just as fast.
We’re not gonna talk about compile time tho lol
What is "slow iteration speed", are you talking about new features added to language? Or literal slow loops like for/while/whatever else?
Write a piece of code, compile, test, debug, write more, repeat.
@@anon_y_mousse I see, but I would describe that with different word
@@XCanG What word would you use?
It sounds like Ada all over again. Everything I've heard of Rust suggests that it's a good spiritual successor.
Now they just need to replace the president with a memory safe one.
Damn.
I avoid naked pointers like the plague. I know I am going to mess them up.
It is okay for the language to have a Unsafe block, when I absolutely, 100% positively cannot _avoid_ handling naked pointers.
But I should not be handling them by default, just making a Array!
I'm sure that this will be as successful as the adoption of Ada...
measure 3 times, cut 1 time
government: measure 100 times, we might cut it 10 years
but like- what about their VAST NETWORK of COBOL?
Rust is not just a different syntax, it requires a totally different application architecture to play nice with the borrow checker. That is why most C programs can’t simply be translated to Rust, they need to be reworked almost from scratch.
C developers LOVE to use globals / singletons and those are simply not applicable in Rust.
However Rust is quite friendly to the Go way of writing programs where different parts of the program communicate using channels.
Unless the government is doing embedded software I think they would benefit more from using Swift or Go.
Government(s) infact do build many embedded projects, think about controllers in every missile, radar, space probe, sensor, drone etc.
Hopefully this is enough to convince Prime, we're all waiting with baited breath
I found myself using rust for 3y but dropped it due to all my functions being macros that have its memory safety conpromised due to performance.
Rust is ideal as it enables utilization of resources junior programmers are able to privide for our team.
what software were you using to explain government projects? that was awesome.
Excalidraw
its an exploratoy project; to investigate developing a system that can perform the translation of c to rust; not to actually neccesarily rewriteite and put into production that rust code. They want to understand the feasibility and efficacy of systems such as an llm to convert between languages.
(I know this is my second comment but...) WTF Do You mean no binaries i n cargo, from what I heard of the JS npm does NOT have "pre-compiled" package either( I may be wrong from I haven't used it is a long time) and You just minify and pack everything into a bundle (in most cases) or pull it from an cdn, isn't that exactly the same, exlusing the compilation part becase JS has need for that(as far as I know)....
There are a ton of npm packages that embed binaries! Next.js even has a bunch of them written in rust, that’s why node modules folders are so big
@@t3dotgg That is true, and that is nice, it abstract away complexity of development, like in most cases. Like you aren't building sdl2 from source when you `cargo add sdl2`, in most cases it's just binding to native library(You can built it from source too if you want). And adding pre-compiling binaries is defently a good way of abstracting away some complexity of having to manuly link/donload libraries.
Also gobal libraries are (generally) a bad thing so on that matter it's good too, less version conflicts.