Not just the toolchain, I want to see a vetted library collection. Make it annual releases, "Rusty MetaLib 2023" which packages a majority of the standard players (regex, clap, num_cpus, SQLite, serde, time, etc).
I have minimal Rust experience, but I really enjoy nearly everything about it. Except for the large dependency trees I am likely to pull in when building something more complicated than Hello World. Impossible to feel safe that all of that code has not been compromised.
For supply chain security, you might be interested in cargo-vet[0], a tool for coordinating and requiring manual reviews of open source dependencies. Both Mozilla and Google[1] have started publishing their audits.toml files, which are machine-readable files describing what source code reviews they have performed.
The crates are very granular. They are almost used like modules in other languages. And procedural macros currently require a separate crate. My point is that you probably have fewer authors than you think in those few hundred dependencies.
Second, the situation isn't appreciably better if you count by authors for c/c++. Running nm or whatever on a decent sized modern c++ thing is enlightening. Much of that is plastered over by the lack of a coherent package manager for those languages, so you end up using thebpackage manager for whatever distro your container is and you think "well thats all just RHEL stuff, I'm sure they vetted it"... but grpc by itself has a dozen or so dependencies not counting the ones it expects from the os. And that is a long list too. So we are in this situation with any language. Rust just makes it easy to see, which is good.
Cargo deny can block your pipeline on cves (or a license you don't want) popping up in your dependency tree. If you pin to a hash, and stick with it until you need a new feature or a cve appears, then that is about as safe as you can be right now. Austral has granular permissions for packages which would be even better, but it isn't here yet.
Lastly, the list of crates that get used to build rust itself is quite long, and I would presume some paths through those libraries got very closely inspected for the certification. Crates like tokio and clap and yesh num-cpus.
This seems like a possible beacon of safety critical rust, especially given that it's SIL 4 and ASIL D (impressive!), the price structure is very reasonable, and its open source!
It's really quite amazing what the team there has done and I'm looking forward to this perhaps bringing some new eyes to where and how Rust might be used.
If you need certification, then this is what you need and hopefully you were already aware of Ferrous Systems before. If you don't need certification (which will be most people) then this doesn't really do anything except reassure you that the software feels like it could be safety qualified because essentially identical software is safety qualified.
I actually hope there's inspiration for the other side of the fence. ISO 26262 ASIL D ought to be a higher bar than it is, it's not at all clear to me that "Oh yeah, off the shelf general purpose languages can do ASIL D" is the right setting of expectations, but that's where we are today. I'd be more comfortable if for these roles (this is software which if it malfunctions might literally just kill a whole bunch of people) we were demanding a bit more, maybe a lot more, than is currently in that ISO document.
Looking at their fork, I don't think it could do ASIL D until they upstreamed some stuff. And it isn't like rust is a generic language, it was designed to make reasoning about correctness easier, at the cost of anything else but performance, and even that if necessary.
Are there specific things you think should be in these standards? For a compiler I mean, there are things you'd require of deployed asil d code you don't really care about for a compiler. Like, if the compuler panics, that is probably fine. If my ABS controller panics, it isn't.
It's a General Purpose language, not a "generic" language that's a particular kind of thing, depending on how much you've been exposed to you may never have seen any programming languages which aren't general purpose because, tragically, we seem as an industry to have decided we all want a single tool - we want to buy a chainsaw and then use that to cut everything, toenails, steak, trees, the tags in new clothes, everything gets the chainsaw treatment because apparently we don't like learning new things.
Special Purpose languages are very narrow, they solve one problem and they solve it really well, but if you have a different problem then too bad. I think we should use these much, much more often, and we should have many more of them, but we don't and for the foreseeable future we won't.
Because a Special Purpose language only solves a narrow problem it often gets to sidestep lots of horrible Computer Science problems which arise for general purpose languages. To revisit our chainsaw analogy, while using a chainsaw to cut the tags out of your new shirt has lots of opportunities for truly life altering (or ending) accidents, if we use instead a tool that's purpose made the potential accidents are trivial. Oh no, I slipped while using the tag removal tool and... didn't remove the tag. Better try again.
> Ferrocene will be available for purchase by individuals and companies later this year at €25 per month per seat (or €240 per seat if paying annually). Purchasing Ferrocene will grant you access to the pre-built binaries and packages of our qualified compilers, and the rendered qualification documents for all versions of Ferrocene.
That's very low pricing. They won't be able to afford to support development if they price that low. It actually decreases confidence that their company is legit to see prices that are that low.
Well, customers need support. Having a lot of small customers is harder and more expensive than having 1 big customer. They should sell to e.g. a large automotive or industrial automation company, and then not worry about the small customers till later.
I work for an automotive company you've probably heard of. The per-seat pricing being within budgets is exactly why we're considering it as soon as the certification stuff is available.
Yes, there is nominally an enterprise sales pathway, but ferrocene wouldn't succeed there. That has a lot of difficult prerequisites and specific timelines that involve convincing manager's manager's (managers) that X is worth the cost and isn't going to have weird licensing terms e.g. preventing us from compiling open source code (a real limitation I've seen). The quickest way through that pipeline is if we already have a bunch of internal usage on prior projects to point to, or well-known public usage.
e.g. lets say that the big initial cost of certifying the first version of the toolchain is $2 million. It will be more than that, but (probably?) less than $10 million. And this doesn't include any salaries or costs beyond the time to get the big up-front work done.
Let's say they were to sell just that one compiler version for 5-10 years. Then they need 800 licenses (which for developers of certified products, is actually quite a few) to make back the 2 million over 10 years.
Suggestion: maybe a better possibility would be: find one customer who will pay at least a few million dollars. Then list the pricing as 'contact us' while they find a couple other large customers. Don't publish the low price/seat or the bigger customers may ask for lower prices.
Software developer Graydon Hoare created Rust as a personal project while working at Mozilla Research in 2006. Mozilla officially sponsored the project in 2009.
I have minimal Rust experience, but I really enjoy nearly everything about it. Except for the large dependency trees I am likely to pull in when building something more complicated than Hello World. Impossible to feel safe that all of that code has not been compromised.