I want Pattern Types for an entirely selfish reason, I want to write BalancedI8 and similar types -- as user defined types, but in stable Rust and have them Just Work™.
BalancedI8 is similar to i8 (an 8-bit signed integer) and to NonZeroI8 (the same type but, with a niche where zero should be), instead of removing zero, which we often have a use for, lets remove the annoying most negative value i8::MIN
Why "BalancedI8"? Because now that we've removed this most negative number (to provide a niche) the remaining value is symmetrical, it goes from -127 to +127
Now, I profess that I want these types but I clearly don't want them enough to do very much about it, so that's not great.
My first job was mostly SPARK Ada, subtypes were so useful, both in terms of making contracts clearer for the human and for the various analysis tools.
Rust is high on my list of languages to learn when I can make some time, having something like this available will be great.
So, you want an integer, but one value sacrificed to denote not-a-number? Is this what "niche" means?
So that with these, you can have Option[integer8, None], an option type that either contains a -127 to +127 8bit integer or contains the empty value, and still consumes only 8 bits of memory? Or are there other uses for this?
And Rust already has this, and with the memory optimization, but for some reason only the version where they sacrificed the value 0.
You're correct that Rust provides NonZeroI8, which in fact I called out in my text. If you look at the source, you'll see that the Rust standard library is allowed to make this type but you can't in stable Rust,
[rustc_layout_scalar_valid_range_start(1)] means, "Hey, Rust compiler, I promise it's fine to just assume I never have this value: 0". You absolutely could write BalancedI8.... if you're the Rust standard library. Unfortunately you aren't allowed to do that in your own stable Rust software because it needs these compiler internals.
There were discussions about stabilising this idea, and they were knocked back because if you do that you're basically stuck with it forever.
One day in the future NonZeroI8 could "just" be a Pattern Type, like the ones you can make at home, but today there are no Pattern Types and NonZeroI8 needs compiler magic.
There are other Rust core types which you could make yourself, IPv4Addr for example is just a 32-bit value, you could make your own, but yours wouldn't be on everybody's Rust system. Option<&T> is just a sum type over &T and None, you genuinely could make your own, call it Maybe<&T> and it would work exactly the same - same optimisations even, although not all the compiler diagnostic messages would be as good if you use it wrong I think. But today NonZeroI8 isn't like them, it actually needs a sprinkle of compiler magic.
The main use is not having to deal with INT_MIN, the two chief problems of which is that you a) you can't sensibly abs() it, b) most people tend to forget about point a). This problem in my experiences most commonly arises in naive implementations of itoa/etc. which tend to assume that they can just call abs() and concentrate on the positive half-range signed integers. Nope, you can't do this, not all negative integers have a positive counterpart.
They're sort of used in graphics APIs. When a value in [-1.0, 1.0] is quantized to an i8, the result is a BalancedI8: -1.0 maps to -127, 1.0 to 127, and -128 is unused; if -128 is used in the dequantizer, it is treated the same as -127. This replaced the old scheme where -1.0 mapped to -128 in which 0.0 was unrepresentable.
The value of encoding this case in the type system seems minimal to me though.
If you're really attached to it being min you'd have to copy that library.
Edit to add: we actually use these in one of my main Rust codes; they're useful, but I'm not sure they're so useful I'd want them built into the language.
Yeah, the XOR trick†. It's very affordable on modern hardware (your CPU can cheerfully XOR two registers while doing other things, barely measurable) but it's more the principle of the thing. Maybe I should just put up with the XOR trick and stop thinking about Pattern Types but I don't think I'll be able to.
† Just in case you've never looked inside those types, they have a constant value and when you want a NonFoo you just take a NonZero and you XOR it with that constant, in other respects they work the same way as any other wrapper type. This is one reason the NonZero types exist, they make the XOR trick very easy to do.
What are pattern types? Cannot watch the video, too slow.
Edit: Thanks for the explanations. From what I see, pattern types are subtypes of a given type, such that the subtype predicate can be specified as a pattern match. This way, pattern types are subtypes that can be checked at compile time (at least, if the used pattern can be checked at compile time, I don't know if all Rust patterns are compile-time checked).
> Why "BalancedI8"? Because now that we've removed this most negative number (to provide a niche) the remaining value is symmetrical, it goes from -127 to +127
Actually instead of just removing the most negative number i8::MIN you can appropriate its bit patter to denote "missing value" (or "null" if you wish) so that your new data type is symmetric and nicely "nullable".
I didn't watch the video but I read the pdf transcript. I noticed that the contract example (if x > 50 then x+50 > 100) can fail because of integer overflow. This is an area that Ada seems to take much more seriously than Rust does.
Anyone know what happened with Adacore and Ferrocene? Are they no longer working together? It sounded like a good collaboration earlier on, given the Rust juggernaut.
Also I notice no mention of anything like SPARK for Rust.
I still feel like Rust and Ada are designed for differing domains. The archetypal Ada app in particular might malloc some memory (and possibly fail) during an initialization phase, but post-initialization, must never fail, which for among other things basically says never use malloc. The post initialization part is basically a control loop using those fixed buffers to keep a jet engine spinning or whatever.
Rust's archetype application on the other hand is a web browser: tons of dynamic allocation, possible memory exhaustion depending on what the user tries to do, and the requirement is to never fail ungracefully, as opposed to never failing at all. "Never fail at all" is not exactly more stringent or complicated: it just means you're not allowed to even attempt certain things, because they might fail.
Ada definitely targets the same domain as Rust, it just _also_ targets additional domains like low level control systems. It has a lot of flexibility and is quite a good language design that people seem irrationally prejudiced against because it has Algol/Pascal-flavored syntax instead of C-flavored syntax.
From what I can tell, trying to write a browser in Ada would be madness. Ada's memory management stuff is very primitive compared to Rust's. That may change as Ada keeps evolving, of course.
From what I can tell, you have to do special crap in Rust to deal with overflow. Saturating is almost never what you want with integers. "Integers" itself, the math term, denotes the infinite set 1,2,3... and while computer arithmetic is necessary limited to a finite fragment, computer integer calculations should always give the same result that you would get using the unbounded mathematical integers. When that doesn't work, you should get an overflow exception, similar to running out of memory.
In Ada, I think the relevant exception is Constraint_Error, but I don't think Rust has a way to do that. By "that" I mean ordinary addition like "a+b" where and b are i32 variables, gets overflow checked without having to call checked_add(a,b) instead of a+b. Is that mistaken?
I'm seeing a lot more Ada posts on the front page recently. Was there a big investment in Ada recently or an acquisition where its marketing machinery is starting to chug along? Or was there a meaningful release or something?
Even with administration change in the US there is a long-term initiative across multiple agencies to eventually move to more robust software, and a part of it is the push towards more safe programming languages (where safe means fewer memory issues, fewer vulnerabilities, less bugs in general, etc.). Similar government initiatives now start in Europe and elsewhere in the world, too.
This regulatory change is not new, it has been going on for years and will take more years to finish. And even without a regulatory pressure, the migration would happen eventually. Look at the cars. As they get more features like adaptive cruise control and various driver assistance features, the need for software that runs with no lag and is reacting to surroundings correctly and quickly becomes absolutely critical. Car companies now can go out of business simply because their software is buggy. The car vendors now produce more software than ever, and they are in dire need for better programming tools than ever.
Languages like Java, Scala, C#, Go, etc. cover many scenarios like cloud services and, for example, car entertainment system. But for devices, microcontrollers, real-time low latency systems etc. C and C++ have been the go-to languages for decades, and now it is starting to change, because turns out it is very, very hard to write correct, bug-free, safe, and secure software in these languages.
Rust is one language that is getting into this market: Rust Foundation established a Safety-Critical Rust Consortium last year, for example, and Ferrocene compiler has a bunch of certifications done already. Ada is another option that would work for many such use-cases, too. The selling point of Ada is that it's been around for a long time and many vendors already have established compilers and tools with all appropriate certifications and qualifications done for all sorts of industries.
So, it's not really "Ada is interesting" and more "Languages that can replace C and C++ are interesting".
Am I a bad programmer if rust is really difficult for me. I desperately want to learn a low-level language, since I think I'm missing something hanging out with my buddies C#, Python and NodeJS.
C and C++ are too difficult, Rust is also hard. I think my best bet is Zig at this point.
> The selling point of Ada is that it's been around for a long time and many vendors already have established compilers and tools with all appropriate certifications and qualifications done for all sorts of industries.
This makes it sound like the field is dominated by proprietary/closed-source tooling. That is a huge red flag for the health of the language if true.
The popularity of Rust has caused a lot of people to start taking safety more seriously. Ada is the safety language for everything except memory and thread safety (they're pretty safe still, but not completely like in Rust).
I think some of it also comes from the number of new programming languages that have come out over the last few years. It's common for people to point at Ada as a reference for how to address problems that come up in C-like languages since Ada already solved so many problems in the 80's.
My assumption has been that Rust's rise to prominence here has led people to investigate & reflect more on prior art in the realm of "safety" in the PL world. This leads them to Ada. And as there's a general trend in HN to look at less traveled roads it starts popping up here. the Baader-Meinhof phenomenon starts to kick in and creates a feedback loop
No, if it was for the bandwagon in social media, everybody would be forced to use Rust. However companies that work on government contracts have for a long time used Ada, and they have a lot of software and investment there. So, with the recent government advisories, the Ada tech is coming back to fill that opportunity.
I'm more fed up with smug rustaceans acting like everything Rust does is somehow novel. Just because *you're* not aware that a language feature already existed earlier doesn't mean Rust invented it.
I think Rust opened up a ton of interest in languages that are as fast as C++ but safer... The fact that Ada was doing a lot of stuff that Rust is trying to do now but decades earlier is particularly interesting.
There was an interesting conference where Ada was presented. Ada marketing has gotten better over the years as well. Still not enough that I'm trying it, but it remain intrigued.
I would say Ada got a lot nicer when Ada 2012 was released, and interest picked up since then. Around the same time, C++ got a lot nicer with the release of C++11.
Hardware products like sensor and control devices. I also use it for desktop tooling whenever a script wants a for loop. Unfortunately I use Flutter for GUI stuff because I hate js and because it has Android/IOS plugins that I would have to write if using Gnoga.
Ada was my first (non hobby use) language. Mostly on VAX/VMS with LSE as the "IDE", and I use the term IDE loosely :-). Although I encounter it rarely I'd encourage anyone to take a look.
The vendor list is really telling of the issues with Ada's adoption:
- Of my quick scan, only AdaCore supports Ada 2012 (where a lot of the really good stuff is implemented) the rest are stuck on Ada 95.
- None of the vendors seem to list transparent pricing.
If you are only selling based on volume and through a sales rep then you are off the bat excluding most startups, SMEs, and just general bootstrap curious folks.
I don't know shit about law, but I'm assuming it's not allowed for someone to build their own compiler and make their own business out of the Ada programming language?
I think Ada is seen as some esteemed language that only the military and space would have the expertise to use. I had that opinion for maybe a decade but it was very wrong. The other issue was that it is so powerful that compilers had bugs and by the time an affordable open source compiler came along I guess C++ was gaining libraries and the militaries don't release libraries.
The ironic thing is that Ada was designed to be cost effective over a projects lifetime. C costs you a lot further down the line.
> I think Ada is seen as some esteemed language that only the military and space would have the expertise to use.
I know Boeing is technically a space company these days, but they weren't when they created the 777. Several of its systems are written in Ada, including the cockpit interfaces, electrical generator systems, and primary flight computers.
One of the reasons of the whole safety hype going on, is that companies have finally start mapping developer salaries, devops and infra costs, to fixing all those CVEs.
With respect, Rust isn't a great choice for web either. At least, not for web _sites_. I would still argue it's not very good for 90% backend API development either, but that depends on what's being done in the backend.
Rust is a bad choice for web and a meh/bad one for game development. It's certainly not good enough at either to have much of a technical edge over Ada.
I think with the recent flurry of languages focusing on safety, Ada has been making a comeback (see: ada-lang.io, getada.dev, alire, etc).
This presentation in particular was in the Ada dev room at FOSDEM (I gave a presentation in that room as well), and there were over 100 people there; we actually ran out of seats in the auditorium.
FOSDEM was packed overall. I can't think of a subject track I went to that had spare seats. I noped out of more than one because I just couldn't get in.
There are many other factors that influence language popularity besides technical quality, like:
- marketing;
- big companies using it;
- familiarity;
- history of the creators;
- history of the influencing languages;
- timing;
- luck;
- regional usage;
- etc.
Despite some programmers seeing themselves as fully rational making cold decisions, we're like everyone else.
> It was literally first programming language taught at university.
Do you mean "It was literally first programming language I was taught at university."? because the first language ever taught was more likely to be one of the autocoder/assembly variants, or FORTRAN.
"First language" is generally taken as a term of art in this sector. It is the first language we're teaching students who we expect to learn other languages as well, so emphasis on "first" here unlike for say a "taster" course in another discipline where you're learning only say, Python, with no expectation you will ever learn other languages.
Edited to expand: For a First Language you can choose to pick a language that you don't expect your students will actually end up using, for pedagogic reasons, just as we might spend time proving fundamental things in Mathematics even though those are already proved and you'll never do that "in real life" after studying, a language which has good properties for learning about programming is not necessarily also the right language to actually write yet another web site, database front end, AI chat bot and video streaming service.
I've spent considerable time thinking about this and I believe Oxford and Cambridge were right to choose an ML as First Language. The MLs have desirable properties for teaching, even if you expect your students to end up writing Python or C++ after they graduate. I am entirely certain that my exposure to an ML at University made it much easier to pick up Rust than it was for people whose nearest previous languages were C and C++
It's indeed hard to imagine that the first programming language taught at any university would be Ada. That would at least mean that the university started teaching programming and computer science very late.
There's been a number of main programming languages taught over the years. Back in the late seventies/early eighties, some universities in my region used Simula in their programming courses, for example.
Agreed. My mum learned basic Fortran at university in the early 1970s, before Ada existed. (It was done on punch cards, and they had to wait a day or so to find out if their programs worked!)
My university had a model train set, hooked up to some ancient 386 machines (and we're talking late 2010s here) and it was used for a real time programming course which was taught in Ada.
Unfortunately the lecturer that ran the unit retired the year I started my degree and by the time I had the prereqs required to do the course the faculty had run the course once without the original lecturer and it was apparently a disaster so they canned the unit until it could be rewritten from scratch, sans train set ... and in Java.
I still think about missing out on programming a train set. Years later
- if most users are "specialists" then you don't need compiler/tooling/doc with very good UX for non specialists, but until you have very neat UX even for non specialists you will not get a lot of traction with non specialists and in turn it might seem pointless to fix the UX
I say half problem because in my experience fixing it is also beneficial for "specialists".
This problem also overlaps with perceived (and sometimes actual) gate keeping and/or elitism.
Basically the same reasons why e.g. Haskell is much less widely used then it could be (and why most usage is in companies mostly filled up with people from Universities which have it as a required (or strongly recommended) course.
Just with more issues (listed in some of the other responses) added on top of it.
> I say half problem because in my experience fixing it is also beneficial for "specialists".
This is critical. Once I realized that even experts didn't necessarily have homogeneous advanced knowledge of the entire language, it became easier to justify to myself spending time on improving the diagnostics of uncommon errors for clarity and learnability. An expert requires less explanation, but they still require one.
And I also suspect that spending time on better DX at the right time of the adoption curve has an outsized impact on it.
The bad part is that it is a hard, slow, endless and somewhat thankless job (you're going against the grain of the compiler design half the time, adding logic that needs to be maintained, and for every case you handle ten more pop up elsewhere that need to be handled in a different way).
This is a good thing to have a test suite for a language but from a business perspective it increases barrier to entry, why? 1/ you start your new compiler with 10000 bugs (the failing tests in the public test suite) 2/ you get no client since clients want a compiler passing the public test suite 3/ no client means no money and this until you fix the 10000 bugs.
With programming languages that do not have a credible public test suite you can get away with shipping the compiler ASAP and get money from customers, then concentrate on fixing customer impacting bugs.
All in all a blessing and a curse, life is full of compromises :)
It hurts my eyes (more seriously, the Pascal family look lost vs the C one, it's a popularity thing) and from my understanding, it took too long to become truly usable in the FOSS world (a bit like CL).
This is a common complaint I read, and I have never understood it.
My eyes are not strong: I wear spectacles of about -6.5 dioptres.
If text size is fairly small, it is REALLY difficult to distinguish
(...)
from
{...}
... on large screensful of text. And
[...]
... is not much more visible. Making that significant is terse, yes, but Sendmail is terse. Terseness is not an unambiguous virtue.
Secondly, indentation: I learned 2 or 3 languages in the 1980s before I learned C, and it's a given that you indent opening and closing control structures to match. That's how it works: you structure blocks of code to show the hierarchies.
But most curly-bracket language coders have their own weird schemes where the opening { is in a totally different column from the closing }. And they fight like alley cats about it.
My broad feelings on many of the issues in Rust, including what's presented here, is that they come from starting with a C-like language as a base. The memory safety and thread safety features in Rust are very impressive, but many other things feel like they're lacking and non-safety features that were added later feel tacked on rather than being a core part of the language.
I feel that if Rust had started with a language like Ada and applied their innovations there then we would have ended up with a much nicer result.
Probably true, although I wonder how much comes from acting like C semantically and how much comes from looking like C. If Rust had taken Ada and made it look like C then would it still be so popular?
My guess is that it would be since there's already a steep learning curve for a C developer to pick up Rust. For a developer who's willing to go through all that I don't think a few more new concepts would be a major issue.
Rust started with ocaml as a base, then evolved in a more C-like direction later on, mainly as a familiarity with the target programmers thing. It wasn't originally envisioned as the systems language that it became, it was much more high level, with a planned GC and everything, then the lifetimes stuff got developed and the contributers at the time pushed it into more and more control in the hands of the programmer.
Which C-like language do you believe was the base of Rust?
If you're judging because the syntax looks like a semi-colon language that's just a thin disguise, to make it easier to onboard people from those languages.
Not a specific C-like language, but that family of languages in general and the design decisions from them:
A number is just a number even if two numbers represent completely incompatible things. If one integer represents a chmod value and one represents a number of files then you can add them together and the compiler will do nothing to stop you even though adding the two is always nonsensical. There's ways around this by creating your own types, but it's not a trivial process. In Ada I can just declare two different numeric types with identical ranges (type A is range 1..200) and the two will be incompatible.
Somewhat related to the above, all array indexes are just numbers. In Ada we can define a type and then use that type as an index of an array type, so if a value is the index type then it must be a valid array index. In Rust if I declare an array as having 5 elements then pass it to a function where I try to access element 6 then nothing will try raise an error at compile time.
Continuing on from the last point, arrays are only indexed by numbers rather than any discrete type. In Ada and enumeration is a valid type to use as an array index, or a range from 5 to 15, or -123 to 7. I'm sure this is something you can do with a generic in Rust, but it's going to be more clunky than having native language support.
Structs are just basic collections of fields. In Ada we have discriminated records that allow for some struct fields which can only be set at instantiation to control things like the number of elements in an another field which is an array. An example of where this could be used is in a ring buffer which is fully contained within a simple struct without the need for extra memory allocation. (I'm aware this conflicts with the other examples about arrays, in short there's a second type of array declaration with a variable subrange as an index). Maybe you can do this with generics in Rust, but it's not as clean, especially if you want to, for example, add a procedure to the ring buffer that takes another ring buffer as a parameter.
These are just off the top of my head as someone who's only briefly looked at Rust, I'm sure there's many more examples. The exact syntax might not match C, but many of the concepts come directly for C and derivatives.
The Ada examples I've given exist in other languages too in various forms, I just happen to be an Ada dev so I know exactly how they work there.
Readit News
I want Pattern Types for an entirely selfish reason, I want to write BalancedI8 and similar types -- as user defined types, but in stable Rust and have them Just Work™.
BalancedI8 is similar to i8 (an 8-bit signed integer) and to NonZeroI8 (the same type but, with a niche where zero should be), instead of removing zero, which we often have a use for, lets remove the annoying most negative value i8::MIN
Why "BalancedI8"? Because now that we've removed this most negative number (to provide a niche) the remaining value is symmetrical, it goes from -127 to +127
Now, I profess that I want these types but I clearly don't want them enough to do very much about it, so that's not great.
My first job was mostly SPARK Ada, subtypes were so useful, both in terms of making contracts clearer for the human and for the various analysis tools.
Rust is high on my list of languages to learn when I can make some time, having something like this available will be great.
So, you want an integer, but one value sacrificed to denote not-a-number? Is this what "niche" means?
So that with these, you can have Option[integer8, None], an option type that either contains a -127 to +127 8bit integer or contains the empty value, and still consumes only 8 bits of memory? Or are there other uses for this?
And Rust already has this, and with the memory optimization, but for some reason only the version where they sacrificed the value 0.
https://doc.rust-lang.org/std/num/type.NonZeroI8.html
You're correct that Rust provides NonZeroI8, which in fact I called out in my text. If you look at the source, you'll see that the Rust standard library is allowed to make this type but you can't in stable Rust,
[rustc_layout_scalar_valid_range_start(1)] means, "Hey, Rust compiler, I promise it's fine to just assume I never have this value: 0". You absolutely could write BalancedI8.... if you're the Rust standard library. Unfortunately you aren't allowed to do that in your own stable Rust software because it needs these compiler internals.
There were discussions about stabilising this idea, and they were knocked back because if you do that you're basically stuck with it forever.
One day in the future NonZeroI8 could "just" be a Pattern Type, like the ones you can make at home, but today there are no Pattern Types and NonZeroI8 needs compiler magic.
There are other Rust core types which you could make yourself, IPv4Addr for example is just a 32-bit value, you could make your own, but yours wouldn't be on everybody's Rust system. Option<&T> is just a sum type over &T and None, you genuinely could make your own, call it Maybe<&T> and it would work exactly the same - same optimisations even, although not all the compiler diagnostic messages would be as good if you use it wrong I think. But today NonZeroI8 isn't like them, it actually needs a sprinkle of compiler magic.
The value of encoding this case in the type system seems minimal to me though.
Deleted Comment
https://docs.rs/nonmax/latest/nonmax/
If you're really attached to it being min you'd have to copy that library.
Edit to add: we actually use these in one of my main Rust codes; they're useful, but I'm not sure they're so useful I'd want them built into the language.
† Just in case you've never looked inside those types, they have a constant value and when you want a NonFoo you just take a NonZero and you XOR it with that constant, in other respects they work the same way as any other wrapper type. This is one reason the NonZero types exist, they make the XOR trick very easy to do.
Edit: Thanks for the explanations. From what I see, pattern types are subtypes of a given type, such that the subtype predicate can be specified as a pattern match. This way, pattern types are subtypes that can be checked at compile time (at least, if the used pattern can be checked at compile time, I don't know if all Rust patterns are compile-time checked).
https://news.ycombinator.com/item?id=39570633
Pattern types or liquid types or dependent types are a way to express a subset of a type. E.g.
Actually instead of just removing the most negative number i8::MIN you can appropriate its bit patter to denote "missing value" (or "null" if you wish) so that your new data type is symmetric and nicely "nullable".
In case you didn't know yes, that's how Rust's niches work and so that's what we're talking about in this sub-thread.
Anyone know what happened with Adacore and Ferrocene? Are they no longer working together? It sounded like a good collaboration earlier on, given the Rust juggernaut.
Also I notice no mention of anything like SPARK for Rust.
I still feel like Rust and Ada are designed for differing domains. The archetypal Ada app in particular might malloc some memory (and possibly fail) during an initialization phase, but post-initialization, must never fail, which for among other things basically says never use malloc. The post initialization part is basically a control loop using those fixed buffers to keep a jet engine spinning or whatever.
Rust's archetype application on the other hand is a web browser: tons of dynamic allocation, possible memory exhaustion depending on what the user tries to do, and the requirement is to never fail ungracefully, as opposed to never failing at all. "Never fail at all" is not exactly more stringent or complicated: it just means you're not allowed to even attempt certain things, because they might fail.
In Ada, I think the relevant exception is Constraint_Error, but I don't think Rust has a way to do that. By "that" I mean ordinary addition like "a+b" where and b are i32 variables, gets overflow checked without having to call checked_add(a,b) instead of a+b. Is that mistaken?
This regulatory change is not new, it has been going on for years and will take more years to finish. And even without a regulatory pressure, the migration would happen eventually. Look at the cars. As they get more features like adaptive cruise control and various driver assistance features, the need for software that runs with no lag and is reacting to surroundings correctly and quickly becomes absolutely critical. Car companies now can go out of business simply because their software is buggy. The car vendors now produce more software than ever, and they are in dire need for better programming tools than ever.
Languages like Java, Scala, C#, Go, etc. cover many scenarios like cloud services and, for example, car entertainment system. But for devices, microcontrollers, real-time low latency systems etc. C and C++ have been the go-to languages for decades, and now it is starting to change, because turns out it is very, very hard to write correct, bug-free, safe, and secure software in these languages.
Rust is one language that is getting into this market: Rust Foundation established a Safety-Critical Rust Consortium last year, for example, and Ferrocene compiler has a bunch of certifications done already. Ada is another option that would work for many such use-cases, too. The selling point of Ada is that it's been around for a long time and many vendors already have established compilers and tools with all appropriate certifications and qualifications done for all sorts of industries.
So, it's not really "Ada is interesting" and more "Languages that can replace C and C++ are interesting".
https://web.archive.org/web/20250118013136/https://www.white...
C and C++ are too difficult, Rust is also hard. I think my best bet is Zig at this point.
This makes it sound like the field is dominated by proprietary/closed-source tooling. That is a huge red flag for the health of the language if true.
I think some of it also comes from the number of new programming languages that have come out over the last few years. It's common for people to point at Ada as a reference for how to address problems that come up in C-like languages since Ada already solved so many problems in the 80's.
- Compiler prices
- The few UNIX vendors that supported it like Sun, it was extra on top of C and C++ compilers, why pay more when C and C++ were already in the box
- Hardware requirements
Still, there are around 7 Ada vendors around.
https://www.adacore.com/
https://www.ghs.com/products/ada_optimizing_compilers.html
https://www.ptc.com/en/products/developer-tools/apexada
https://www.ddci.com/products_score/
http://www.irvine.com/tech.html
http://www.ocsystems.com/w/index.php/OCS:PowerAda
http://www.rrsoftware.com/html/prodinf/janus95/j-ada95.htm
- Of my quick scan, only AdaCore supports Ada 2012 (where a lot of the really good stuff is implemented) the rest are stuck on Ada 95.
- None of the vendors seem to list transparent pricing.
If you are only selling based on volume and through a sales rep then you are off the bat excluding most startups, SMEs, and just general bootstrap curious folks.
The ironic thing is that Ada was designed to be cost effective over a projects lifetime. C costs you a lot further down the line.
I know Boeing is technically a space company these days, but they weren't when they created the 777. Several of its systems are written in Ada, including the cockpit interfaces, electrical generator systems, and primary flight computers.
Problem is, web is the new BASIC and many devs will start there and they will see rust first. And where's that ADA game engine ?
ADA can definitely claim tons of successes and very powerful constructs, but mindhsare is clearly not one of its selling points.
This presentation in particular was in the Ada dev room at FOSDEM (I gave a presentation in that room as well), and there were over 100 people there; we actually ran out of seats in the auditorium.
These are the deciding factors.
If you look at which newish languages have gotten popular over the last few years, it was Rust, Kotlin, Swift, Go and Typescript.
Building a language and ecosystem around it takes a huge amount of resources, and often tedious work that doesn't happen if people aren't paid for it.
The street cred of "hey, large company X is using it, it must be good" is also very important.
(of course Swift and Kotlin are somewhat distinct as the platform languages for Android and iOS)
ADA was way ahead of its time, thus compilers were slow and ressource (RAM) hungry, and worse: they were inaccessible for hobbyists or learners.
In contrast, pascal/turbo pascal was ubiquitous, and then turbo c++. You easily knew someone who could organize a copy and "keys" for it.
Do you mean "It was literally first programming language I was taught at university."? because the first language ever taught was more likely to be one of the autocoder/assembly variants, or FORTRAN.
Edited to expand: For a First Language you can choose to pick a language that you don't expect your students will actually end up using, for pedagogic reasons, just as we might spend time proving fundamental things in Mathematics even though those are already proved and you'll never do that "in real life" after studying, a language which has good properties for learning about programming is not necessarily also the right language to actually write yet another web site, database front end, AI chat bot and video streaming service.
I've spent considerable time thinking about this and I believe Oxford and Cambridge were right to choose an ML as First Language. The MLs have desirable properties for teaching, even if you expect your students to end up writing Python or C++ after they graduate. I am entirely certain that my exposure to an ML at University made it much easier to pick up Rust than it was for people whose nearest previous languages were C and C++
Unfortunately the lecturer that ran the unit retired the year I started my degree and by the time I had the prereqs required to do the course the faculty had run the course once without the original lecturer and it was apparently a disaster so they canned the unit until it could be rewritten from scratch, sans train set ... and in Java.
I still think about missing out on programming a train set. Years later
- "the common dev" isn't familiar with it
as well the hen/egg (half) problem of
- if most users are "specialists" then you don't need compiler/tooling/doc with very good UX for non specialists, but until you have very neat UX even for non specialists you will not get a lot of traction with non specialists and in turn it might seem pointless to fix the UX
I say half problem because in my experience fixing it is also beneficial for "specialists".
This problem also overlaps with perceived (and sometimes actual) gate keeping and/or elitism.
Basically the same reasons why e.g. Haskell is much less widely used then it could be (and why most usage is in companies mostly filled up with people from Universities which have it as a required (or strongly recommended) course.
Just with more issues (listed in some of the other responses) added on top of it.
This is critical. Once I realized that even experts didn't necessarily have homogeneous advanced knowledge of the entire language, it became easier to justify to myself spending time on improving the diagnostics of uncommon errors for clarity and learnability. An expert requires less explanation, but they still require one.
And I also suspect that spending time on better DX at the right time of the adoption curve has an outsized impact on it.
The bad part is that it is a hard, slow, endless and somewhat thankless job (you're going against the grain of the compiler design half the time, adding logic that needs to be maintained, and for every case you handle ten more pop up elsewhere that need to be handled in a different way).
This is a good thing to have a test suite for a language but from a business perspective it increases barrier to entry, why? 1/ you start your new compiler with 10000 bugs (the failing tests in the public test suite) 2/ you get no client since clients want a compiler passing the public test suite 3/ no client means no money and this until you fix the 10000 bugs.
With programming languages that do not have a credible public test suite you can get away with shipping the compiler ASAP and get money from customers, then concentrate on fixing customer impacting bugs.
All in all a blessing and a curse, life is full of compromises :)
This is a common complaint I read, and I have never understood it.
My eyes are not strong: I wear spectacles of about -6.5 dioptres.
If text size is fairly small, it is REALLY difficult to distinguish
(...)
from
{...}
... on large screensful of text. And
[...]
... is not much more visible. Making that significant is terse, yes, but Sendmail is terse. Terseness is not an unambiguous virtue.
Secondly, indentation: I learned 2 or 3 languages in the 1980s before I learned C, and it's a given that you indent opening and closing control structures to match. That's how it works: you structure blocks of code to show the hierarchies.
But most curly-bracket language coders have their own weird schemes where the opening { is in a totally different column from the closing }. And they fight like alley cats about it.
https://en.wikipedia.org/wiki/Indentation_style
ONLY the GNU style listed there is sane.
I mean at least Allman and Horstmann styles are consistent.
It is much MUCH easier to pick out
BEGIN
END... than it is to try to pick out { and } in some random blasted column.
And yet, all the fans squee at curly brackets. As smdiehl wisely said:
« C syntax is magical programmer catnip. You sprinkle it on anything and it suddenly becomes "practical" and "readable". »
https://x.com/smdiehl/status/855827759872045056
I never got it. It's obfuscatory. It is famed for being write-only. There's a competition to write the least-readable C!
C style hurts my eyes.
Pascal and Ada are vastly more readable.
I feel that if Rust had started with a language like Ada and applied their innovations there then we would have ended up with a much nicer result.
Doing it differently might end up with a better result from a purist viewpoint, but I’d wager that adoption would have been far worse.
My guess is that it would be since there's already a steep learning curve for a C developer to pick up Rust. For a developer who's willing to go through all that I don't think a few more new concepts would be a major issue.
Which C-like language do you believe was the base of Rust?
If you're judging because the syntax looks like a semi-colon language that's just a thin disguise, to make it easier to onboard people from those languages.
A number is just a number even if two numbers represent completely incompatible things. If one integer represents a chmod value and one represents a number of files then you can add them together and the compiler will do nothing to stop you even though adding the two is always nonsensical. There's ways around this by creating your own types, but it's not a trivial process. In Ada I can just declare two different numeric types with identical ranges (type A is range 1..200) and the two will be incompatible.
Somewhat related to the above, all array indexes are just numbers. In Ada we can define a type and then use that type as an index of an array type, so if a value is the index type then it must be a valid array index. In Rust if I declare an array as having 5 elements then pass it to a function where I try to access element 6 then nothing will try raise an error at compile time.
Continuing on from the last point, arrays are only indexed by numbers rather than any discrete type. In Ada and enumeration is a valid type to use as an array index, or a range from 5 to 15, or -123 to 7. I'm sure this is something you can do with a generic in Rust, but it's going to be more clunky than having native language support.
Structs are just basic collections of fields. In Ada we have discriminated records that allow for some struct fields which can only be set at instantiation to control things like the number of elements in an another field which is an array. An example of where this could be used is in a ring buffer which is fully contained within a simple struct without the need for extra memory allocation. (I'm aware this conflicts with the other examples about arrays, in short there's a second type of array declaration with a variable subrange as an index). Maybe you can do this with generics in Rust, but it's not as clean, especially if you want to, for example, add a procedure to the ring buffer that takes another ring buffer as a parameter.
These are just off the top of my head as someone who's only briefly looked at Rust, I'm sure there's many more examples. The exact syntax might not match C, but many of the concepts come directly for C and derivatives.
The Ada examples I've given exist in other languages too in various forms, I just happen to be an Ada dev so I know exactly how they work there.
Deleted Comment