So I guess I'm not clear about this -- have they implemented a fresh new compiler that runs on the GNAT toolchain? Or is this a stable/certified fork of the existing Rust LLVM-based toolchain with a GNAT branding overtop of it? Or something inbetween? What about associated tools like Cargo? Rustanalyzer, Rustfmt, etc.? What version of Rust do they currently target? What about 3rd party crates support etc?
FWIW I work professionally in a space which is likely one of their target markets (autonomous/precision agriculture) on a system in Rust (and C++). I skimmed through the pages but didn't find a technical explanation of what they're offering.
> GNAT Pro for Rust is currently in early-access for select customers and provides a compiler (rustc), a build and package manager (cargo), and a debugger (gdb) for x86_64 Linux and Linux cross targets.
Sounds awesome! Too bad that it probably costs 10s of thousands of dollars for a license or more. Judging from the fact that you have to contact sales before they will even tell you :/
It’s not a technical product so much as a legal one. Just keep on using Rustc+Cargo. If Volkswagen or Framatome wants you to write software for them, then you can transition to these blessed versions of the official tooling. And you’ll have the money to do so.
One other caveat is that it's designed for environments with high certification requirements like aerospace. When you're in that space, you're glad to pay those license costs for that assurance!
Is 12 junior dev-days a lot of money for a software development tool? A single junior dev costs 20x as much per year. Is having 5% more junior devs on your team better than better tooling for the other 95% of the team?
I can see how it might be a impediment for tinkering and hobbyists, but it is a pittance for any commercial usage.
You won’t get around fees paid in the certified compiler world. If you want someone to sign, stamp and deliver paperwork proving that a compiler upholds a standard and likely also take liability for it, you’ll need to pay. Few organizations will take on liability for free.
But you can get pretty close, at least in some spaces. Self-certification is always an option. Aerospace will be harder, automotive is annoying but feasible.
Ferrocene for one is entirely 100% compatible with the equivalent rust compiler, in fact it is the rust compiler built, qualify-tested, packages and delivered without any significant (1) patches. As such, it’s entirely feasible to use “I’ll just use open source rustc” as an escape hatch. Not a pretty one, self certification is quite a bit of effort, but a bounded one. There’s no magic in what we did, most of it is legwork.
We even open sourced the spec that the certification is based on, so you’ll have to do less legwork than we did.
This has in fact been a design goal and a requirement of our early customers.
I can’t speak to Adacores plans regarding upstream compatibility, I have no insight other than their public statements and they’ve been silent on that matter.
(1) a few lines, mostly target support for stuff rustc doesn’t offer in tree
I’m not sure about this specific contract, but historically speaking, Adacore has sold support contracts, and even if you stop paying, you’re still allowed to use the compiler versions you’ve paid for. Furthermore, since these compilers are all based on upstream, and all Adacore work eventually ends up upstream, there’s essentially no risk you’re going to be left stranded.
Junior devs make 100-200 K$/yr in salary. The fully burdened cost including overhead and benefits is usually around double that at around 200-300 K$ (higher base compensation usually results in lower proportional overhead). In the US there are ~2000 working hours a year, so that amounts to 100-150 $/hr.
There are 8 hours per dev-day, so 96 dev-hours. At 100-150 $/hr that is 9600–14400 $.
If you are really obstinate about 20 K$, then just double it and call it 25 junior-dev days. Whoopie, still only 10% of the yearly cost of a junior-dev. Yeah, developers are really expensive. So back to the original question, just minimally changed to account for irrelevant factors of two.
Do you think having 10% more junior devs on your team is better than having better tooling for the other 90% of the team?
Well then you are still looking at silicon valley level of salaries. The top of the top of the world.
Let's take The Netherlands, where I live. A junior dev is expected to make €34,422/year. This is still a western country so let's go somewhere else. In China a junior dev makes about ¥269,904 a year, or $1.806,89. Is this tool worth 5+ man years of a junior dev? If your back of the envelope calculations only barely make sense for a tiny part of the world maybe the pricing is actually insane.
edit: ¥269,904 is $37.002. Point still stands.
> Do you think having 10% more junior devs on your team is better than having better tooling for the other 90% of the team?
The tool would have to be pretty damn good. And also not introduce business risk or at the very least a minimal business risk.
You called my number absurd even for SV. As you now see, it is reasonably accurate. That you thought it was absurd instead of reasonable shows you are missing key information in the cost-benefit calculation. It might be prudent to re-evaluate your preconceptions in light of that.
As for your other numbers you again point at salary. What matters to a company is fully burdened cost per developer-time. European countries have higher benefits and lower hour/day expectations per year which skew the ratio relative to the US. I am not super familiar with the standard rule-of-thumb multiplier in western Europe, but the difference in fully burdened cost is less skewed than it seems based on salary, probably only 2-3x cheaper at most.
As for China, you used the yen conversion rate, not the RMB/yuan conversion rate. 269,904 RMB is ~37 K$, not 1800 $.
Paying fractions of employee cost in tooling is only viewed as absurd in software. In literally every other industry spending tens to hundreds of thousands of dollars per engineer to make them productive is just viewed as good business sense.
Even outside of engineering almost every industry spends more as a percentage on employee tooling. Do you see how many tools your average carpenter, plumber, or electrician has? Landscapers, architects? Even secretaries get those neat expensive printers and management software.
The point I am making is that tens of thousands of dollars for tooling is not “insane”. It deserves a calm cost-benefit analysis which can quite easily come on the side of worth it. Obviously, it can also come on the side of, this is a piece of trash, but that should be out of analysis, not a knee-jerk “too expensive”.
I don't think your number is reasonably accurate. 12 days wasn't close to accurate except in the insane world of SV.
Just because something is "normal" in other parts of the industry doesn't make it correct. The only reason these industries pay that sum is because they have literally no choice. They are essentially held hostage by the companies that build the tooling.
Precisely because many software engineers have seen the insanity of those fields they view paying for tools as a huge risk. No one wants to go back to the time when you had to pay monthly to get a shitty compiler with barely existing support.
You seem to be extremely fixated on the exact number of 12. Any number short of 100 junior dev-days does not even warrant considering the word “crazy”. Multiply all the numbers by 8 for all I care, it does not affect the conclusion that you should be doing a cost-benefit analysis, not dismissing it out of hand. Tens of thousands of dollars is a worthwhile price to pay for quality tooling that offers modest improvements; not big, modest.
You need to get to around 500 dev-days per developer in tooling before you get into “the probability this makes sense is almost certainly zero, so just dismiss it out of hand as too expensive”. That is hundreds of thousands of dollars per developer before we actually get into economically unjustifiable land.
And again, you are not distinguishing between what is economically sound versus the cost-benefit analysis of specific products. It is economically sound to spend a additional 10 K$ per developer you have in the Netherlands for tooling that offers a 30% productivity improvement (actually, it is economically sound to pay a great deal more, but that requires a more exhaustive analysis).
In other words, if you find a tool that you believe (including all factors like legal, licensing, whatever) actually provides a 30% overall productivity improvement then you would be economically foolish not to purchase that product for 10 K$/yr per developer. Note that I already incorporated all objections into your belief of a overall 30% improvement, we are starting from the assumption that including all caveats you are nearly certain you will get a 30% improvement.
But again, this depends on actual products meeting those parameters. Maybe all of the paid products suck. Fine, then they all fail the cost-benefit analysis. But that is because the benefit was not there for the cost, not because the cost is outrageous. Those are different fundamentally different concepts and should be treated differently.
> Paying fractions of employee cost in tooling is only viewed as absurd in software. In literally every other industry spending tens to hundreds of thousands of dollars per engineer to make them productive is just viewed as good business sense.
I suspect that part of the problem is that it's difficult to measure developer productivity, while it's a lot easier to measure headcount.
> The tool would have to be pretty damn good. And also not introduce business risk or at the very least a minimal business risk.
That is actually quite possible.
Ada is in a really good place as far as that goes: imagine the cost of writing an IDE (to include compiler) for, say, Ada, PL/SQL, and VHDL -- given the common lineage, you could make a custom internal representations (IR), where each language has a 'Subtype' constraint for its particularity (e.g. `Subtype Ada_IR is General_IR with Dynamic_Predicate => Is_Common(Ada_IR) or Is_Ada(Ada_IR);`, and so on for PL/SQL and VHDL), make these IRs with SPARK proving, as you implement PL/SQL and its query-engine also implement SPARK's proof-tools and SMT-interfaces, proving it as you go, next implement and prove code-gen/HW-synth.
Now, put the IDE source through the IDE, and BAM! Now you have a proved IDE+compiler for Ada, PL/SQL, and VHDL giving you a very solid platform. (Also, as you would have a DB-engine onboard, you could populate the IDE with templates and run a query like: SELECT Name, Code FROM Entities WHERE Purpose LIKE “%SCSI%”;... or SELECT Name, Purpose FROM Algorithms WHERE Purpose LIKE “%SORT%” AND Ω <= log_2;.)
I work in aerospace, and it will be interesting to see when Rust will turn into the defacto standard for DAL-B or safer systems. However, if there is a language that can beat Ada, I think Rust is it, and this is one huge step to make this a reality.
Rust tries to ensure memory safety and, to some extent, makes efforts to solve some common concurrency issues through the same borrowing/ownership concepts. But while I'm not fluent in Ada I always got the impression it made attempts to provide some safety and explicitness in other areas, too? Putting it another way, I feel like Rust maybe doesn't have a complete answer to a lot of the problems that Ada has tried to answer.
> I suspect, though, that memory safety is one of the most important kinds of safety.
I don't.
It seems to me like "memory-safety" is a response to the legacy of C and "C-compatibility) WRT poor behavior/respect of types; example: int/address punning, int/boolean punning, array/pointer punning, etc. (NUL-terminated stings could fit here, too as they're a consequence of C's address/array confusion.)
Contrary to this, would be correct typing.
Consider SQL-injection and how the "best practice" is to never take data from the user... well we can take data from the user AND ensure there's no possibility of injection:
Subtype Numeric is String
with Dynamic_Predicate => (for all C of Numeric => C in '0'..'9'),
Predicate_Falure => raise Constraint_Error with "'" & Numeric &"' is not numeric.";
--...
Count : Numeric renames Get_User_Value;
--...
return Query("SELECT \* FROM Some_Table WHERE Count=" & Count & ";");
The above is perfectly safe because the constraint imposed prohibits the SQL-injection... and you can even enforce something like SQL_Escaping:
PACKAGE Example IS
-- The only way to get a value of ESCAPED_STRING is via calling Create.
Type Escaped_String is private;
Function Create( X:String ) return Escaped_String;
PRIVATE
Type Escaped_String is new String;
Function Create( X:String ) return Escaped_String is
( SQL_Escape(X) );
END Example;
Although Rust doesn't have range types they do have non-zero integer types (so a start anyways) and I'm pretty sure there's an open RFC on proper range types.
> I suspect, though, that memory safety is one of the most important kinds of safety.
I don't agree, at least in the context of safety that Ada is typically mentioned in. Safety in this context is generally about human lives.
Memory safety is by far the most important kind of safety against exploits. Because memory safety bugs lead to arbitrary code execution and a total security breakdown.
However, where Ada is used most often - safety-critical and realtime systems in airplanes or medical equipment and such - most of the code is written for embedded systems. The attack surface is generally miniscule if any. The vast majority of issues that these contexts face I reckon are unit conversion errors, off-by-one errors, type overflows and logic errors.
The Rust static type system is actually not that rich for enforcing compile time constraints on values and states. It appears rich compared to C or Java or Go or something, but it's not that expressive even compared to languages in similar spaces like Scala or F# or even C++'s (rather terrifying) template system.
This has advantages and disadvantages. But for the kind of thing we're talking about, there's some disadvantages. There are things a richer type constraints system could offer beyond even the 'range' constraints other people in this thread are referring to.
e.g. I work on a (embedded-space) application that has a bunch of state machines in it. We naturally use Rust enums to describe these states. How nice it would be if Rust's enum system was rich enough to be able to describe and enforce the valid state transitions rather than just the set of possible states. There are various ways to try and approximate this (I've seen a few articles), but on the whole they're rather awkward and full of holes.
Also the verbosity of Ada's syntax looks painful to write but actually pretty nice to read. This has got to have lots of value for paranoid organizations.
I've seen plenty of terse and impenetrable Rust code, especially stuff that makes heavy use of rich static type action or funky things like GATs, etc.
> We naturally use Rust enums to describe these states. How nice it would be if Rust's enum system was rich enough to be able to describe and enforce the valid state transitions rather than just the set of possible states. There are various ways to try and approximate this (I've seen a few articles), but on the whole they're rather awkward and full of holes.
I'm assuming you're referring to type state machines, where you have one struct per state and the only way to translate from one state to the next is through method calls. Defining these is quite verbose (unless you rely on macros) but how is it full of holes?
In that case: Potential holes because the permitted state transitions are scattered through function signatures and not described in a centralized place.
You're right macros could make this more pleasant. I still think it's quite unergonomic.
But yes, I probably should have said "awkward and/or full of holes" instead of and
It's been a long time since I have touched Ada and I don't really know Rust. But I do know that Ada allows you to specify the range of custom numeric types[1]:
type Page_Num is range 1 .. 2_000;
type Line_Size is range 1 .. Max_Line_Size;
subtype Buffer_Size is Integer range 0 .. Max;
type Byte is mod 256; -- an unsigned byte
type Hash_Index is mod 97; -- modulus is prime
Looking around, I see that the Rustaceans are working on ranged types, as discussed here[2]. They even mention Ada. And there is a PR for a ranged types MVP here[3], which was ultimately closed to do some more thinking.
This looks like another set of Rust proposals that are going to go exactly nowhere. Skimming, looks like the PR was closed, and the RFC has been open since 2015.
Again, Rust is a great language. I work in it fulltime. But this is not a focus it currently has. Hell, they can't seem to get allocator-api and simd stable, after years.
Embedded has taken a very... backseat to webby, async stuff, unfortunately.
As much effort as the team outs on having a coherent progression and cater to as many customers as possible, Rust is still a show-up-ocracy. If there aren't people with enough desire to implement a proposal, it doesn't happen. Features have stalled because of fundamental issues that require going back to the drawing board (allocator api), sometimes for CS research level (specialization) or usability (TAIT) questions, or the person working on the feature burned out right before the final push, and there was no one else to pick up the work afterwards.
Being strongly typed also helps! One other interesting thing is including the tests directly in the file you're writing in. To me, that will be incredibly helpful when doing certification and verification.
The Ada type system is very very interesting to me. For instance, type ranges[0] make it impossible to represent an invalid value. There's a lot of power there and the associated static analysis can catch things that otherwise would be tricky to catch at compile-time.
Looks like it's not available yet (https://www.adacore.com/gnatpro-rust), which makes this a pre-announcement type thing. On HN, it's better to wait until the thing is available.
