I point to articles like this when I hear Rust enthusiasts speculate at how long it will take companies to see the light and move from C, C++, or Java to Rust, or even how long it will take before Rust overtakes these languages as the programming language of choice.
After all, Ada had the DoD mandate (routinely waived, but still) and a substantial amount of academic and industry backing, at least for a while. And now? most Rust enthusiasts don’t even know what I’m talking about.
…and Ada is relatively simple by comparison to Rust.
People only pretend to care about costs and whatnot when they believe it to benefit themselves. They’ll always move the goalposts.
I’ll use the OpenBSD developers as an example: They claim to want security, while using the language least suited to that; when this is pointed out, they in-turn point to the large amount of existing code; and when that fails to sway people, they move on to even more arbitrary requirements, such as compiler support in their base of software. Even if Ada were to surmount each of these requirements, they’d simply add new ones, like language familiarity with their team.
This example shows that people will only pretend to use reason for what they want to do, and will abandon it when inconvenient.
One of my favorite quotes from this: “Bug rates in C++ are running higher even than C”.
And they go on to waste literal decades on projects only a handful of unreasonable people use, staying behind nearly all modern software developments. Just because they don’t want to learn something new, even though those handful of developers have had plenty of time for that, and if they had spent just a fraction of their efforts on it, good bindings would probably already exist to interface with the existing code, assuming it was ever desirable.
What a joke.
There is now a podcast format of the rational cost analysis site content that can be found here. Generated by notebookLM (AI) but useful when driving etc.. An interesting point I didn’t pick up on when reading was that they threw in experienced C devs learning on the job with Ada and they were twice as effective as the same devs in a world class C environment.
Needs updating for c++ and rust.
Has re-training been factored into the development costs? The project needs to factor in the cost of training someone with no previous experience of Ada. In UK, very few companies are willing to train people. It is normally pick it up as you go along, which is the wrong way of doing things since they will still be thinking in a different language but coding in Ada.
The other problem is recruitment. If you put down Ada, the recruitment companies will use that as a filter. That means suitable candidates will be excluded just because they don’t have Ada. It may cost less to do a project in Ada but how easy is it to find the people. I’ve seen the same Ada advert (words are the same) from different recruitment agencies for one company for over a year.
It was. The two factor gain was with C devs learning Ada on the job. I do expect Rational had a certain number of experienced Ada devs that could help with that though. AdaCore provide training and mentors as an alternative. I had to teach myself and I’m sure that would have an impact but likely with other benefits. Nvidia boot strapped their own training with AdaCores services.
You might also want to consider McCormick’s real-time software course. The U used C for all its lower-level courses, so all the students had C experience. None of them had Ada experience. No one ever finished the project using C, even when given 60% of the professor’s solution, so we don’t have a factor, but many students were able to learn Ada and finish the project in Ada, even when given only a small percentage of the professor’s solution, so clearly learning Ada and using Ada needs less effort than knowing C and using C.
Realplayer is a blast from the past
I can’t find the code he gave to his students unfortunately.
This one made me laugh
The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time. (Tom Cargill)
The old 90-90 rule. I like this observation from Kernighan and Plauger (Software Tools):
Most users of a tool are willing to meet you halfway; if you do ninety percent of the job, they will be ecstatic.
Put the two together and you only need 90% of the development time.
This link is better https://www.adacore.com/uploads/papers/Controlling-Costs-with-Software-Language-Choice-AdaCore-VDC-WP.pdf
The data I’ve seen is that Rust is 10-30% more productive than C++. Tho that was from pro-Rust people. And I don’t know how they collected the data: was it novice C++ vs. guru-level Rust programmers?
In any case: verification is 80% of pre-release product development. Property checking is 5 times more productive (500%, not 50%) than writing tests. And Ada/SPARK is the only SW language that has it (VHDL and Verilog also do).
So we’re talking an order-of-magnitude difference in productivity for Ada/SPARK.
For pre-release costs.
Now the cost of finding/fixing a bug post-release for SW is 10X higher than pre-release (rule-of-thumb) in lost sales, reputation damage, and possibly legal liability. If people get injured or killed, it can go as high as prison sentences in the US (criminal, not civil). Since property-checking achieves a dramatically higher level of quality, the risks drop proportionally.
I don’t have a scientific study for you, but judging from a Rust team I work with, of whom only 1 had worked with Rust earlier than 2020, and a C++ team we interface with, which contains at least some programmers that have been working with both C++ and that particular system for 10 years or more, 10-30% is a gross underestimate of how much more productive Rust programmers can be than C++.
That said there are other factors involved: our team has a strong Agile workflow and we frequently work in groups on our code. Their team is highly siloed and their “Agile” is not very. Our “genius”-level developers tend to be pretty loyal, rather than leave for greener pastures in a different part of the country. Their team is using QT, which is apparently incredibly incompatible with itself, to the point where version x.y.z is apparently incompatible with x.y.w.
So it’s not a great comparison, but it’s a comparison.
An MIT study found that the range of productivity of individual SW engineers varied 50:1. The best did in a week what the worst did in a year. For teams, it was 2,000:1. In other words, culture >> technical ability by 40X. And that’ll swamp any differences in tools, languages or design practices. Just FYI. As a self-made many-millionaire once told me: “The key to success is being able to first, get a team of brilliant people working for you, and two making sure they don’t kill each other”.
Really? In fact depending on the task, many software engineers have zero to negative productivity. No study needed… 