While one can choose to dismiss the TIOBE index (I don’t have any strong opinion about it), there was also a screen shot of PYPL showing a steady increase in Ada over recent months. Something positive is happening!
A few days ago, I had ChatGPT compare Rust and Ada. It tended to penalize Ada for its runtime checks and access values (aka pointers). However, ChatGPT didn't account for the fact that many of Ada's runtime checks would need to be manually implemented by developers in other languages. An Ada compiler, can often optimizes these checks away, knowing where they're genuinely needed and where they can be removed. This often explains why speed comparisons between C and Ada code can be misleading, as they rarely factor in the extra manual effort required to make C code equivalently robust with necessary safety checks.
Regarding access values, I listed out some of Ada's various restrictions. Its scope rules prevent referencing objects at deeper levels, objects must be explicitly marked aliased to create an access value to them, and there's far less need for access values (for instance, no pointers are needed to pass parameters by reference). Additionally, Ada offers the ability to dynamically size some objects and reclaim their memory without explicit memory allocation.
After I highlighted these details, ChatGPT admitted it had unfairly evaluated Ada, concluding it's a very safe and robust language, albeit using different techniques than Rust.
I recall watching a presentation about C++20. During the presentation, the presenter said there were about 163 undefined behaviors in the C language (note: I think it was C99) which implied there were many more in C++ since it’s a much more complex language. Unfortunately, I don’t have a link to that presentation.
You might have heard about the SPARK variant of Ada. I recall reading in an article many years ago that the original version of SPARK was based on Ada83 because it is a very safe language with a lot less undefined behaviors, which is key to trying to statically prove the correctness of a program.
I haven't used Rust, but many of the comments and articles I have read about the benefits of the language and the strong desire for develop robust and/or safe software are virtually the same as what Ada supporters have been claiming for decades.
It's a good thing more people are realizing we really need to stop settling for C and C++, stop investing more money into tools that simply compensate for the weak foundation of those languages, and finally adopt safer alternatives.
This! I have mainly programmed in C in my career (note: I also have experience with C++ on multiple projects and to a lesser extent with C# and Java). In almost all the embedded projects I have been on, Ada would have been a far better choice because it would have helped avoid whole classes of common software bugs and thus less costly to maintain. This is especially true with bugs reports and vulnerabilities that would be discovered on systems that were already deployed.
People normally think that C is the best for low level embedded programing, but from my experience, it pales in comparison to the amount of low level control and type safety that Ada provides, even when you restrict yourself to a small subset of the language (note: Ada is often used on barebone systems and without an Ada runtime). Given the interoperability Ada has with C, it means you don't have to rewrite everything in order to incorporate it into existing code bases.
Regarding the collaboration between AdaCore and Ferrocene, the effort is to produce a Rust toolset that is qualified for safety critical usage (e.g. verification of object code that is produced, etc). That is _not_ the same as bringing SPARK-like language capabilities to Rust. I think too many people get that confused.
The fact that you originally didn’t know that Ada is heavily used in embedded clearly shows you don’t know it. Even though you edited your reply, any reader should seriously doubt your claim that “certain things are quite difficult” in Ada. Do you know that in Ada, you don’t have to use pointers or heap memory nearly as much as other languages such as C and C++? You can even write programs that don’t even use any. That avoids a whole class of issues.
One of the extra advantages with Ada is that you can decide to utilize the SPARK variant and do formal proofs on software components that are more critical. I invite you and and others to watch the presentation by Altrans where they talk about 30+ years of SPARK usage to help develop ultra low defect software: https://youtu.be/VKPmBWTxW6M
I don't know Python, Go, or nodejs, but with regard to general purpose programming, you can look at some of the free tools and libraries on AdaIC (https://www.adaic.org/ada-resources/tools-libraries/). There is a man named Gautier, who actively develops a variety of tools (e.g. 3D gfx, Excel file producer, games, code editors, etc). Check out his blog page: https://gautiersblog.blogspot.com/search/label/Ada
yes, that is a big step backward. One of the details that people don't realize is that the Ada code probably had runtime checks inserted by the compiler to help catch issues. In addition, the Ada code most likely restricted the set of input values or prevented accidental mixing of different numerical values using its strong type system. When you convert to C, you lose all of that. If there is a code change down the road, you could have an error occur that might have been caught by the Ada compiler at compile time, or if not then by an Ada runtime check. Yes, testing has to be really good to minimize these cases, but we all know it's difficult and very time consuming to develop test for every possible combination. In addition, when you have to do code reviews, you have to worry about a much wider range of possible bad values that can be passed around which can screw up the results.
Ada is a really good system programming language, especially if you have to get very low level, where the language allows for very fine control over memory layout and for interfacing with hardware. All that _without_ sacrificing type safety. In addition, if you want to make your software even more bullet proof, you should consider the SPARK subset of Ada and statically prove the Absence of Runtime Errors, which includes memory safety. Furthermore, with SPARK you can prove various higher level properties of your software, thus reducing the number of unit tests needed.
AdaCore was formed by various individuals at New York University who were involved in the creation of GNAT, which was a DoD funded project. The company is still based in New York. Over the years they have expanded into various parts of Europe.
The link you provided to the SPARK user manual is a great reference. It explains how using the Ravenscar tasking profile in SPARK helps to avoid data-races and race-conditions. That, along with the ability to formally prove the absence of runtime errors and that your program satisfies various program properties and requirements are good reasons for people to seriously consider looking into using SPARK for critical parts of their software.
Actually, it is the pointer support in the SPARK variant of Ada that was inspired by Rust's ownership/borrower semantic. Originally, SPARK didn't allow any pointer usage, but with the new ownership/borrower semantics, SPARK allows limited usage of Ada pointers.
As for more literature about using Ada's tasking features, I recommend the wonderful books and papers by Alan Burns and/or Andy Wellings, such as "Concurrent and Real-Time Programming In Ada (3rd Edition)." AdaCore has an old presentation on using Ravenscar with multi-core processors (https://people.cs.kuleuven.be/~dirk.craeynest/ada-belgium/ev...). There are more articles on the internet on Ada Ravenscar tasking profile and full Ada tasking.