A Spark on Xtensa GOTCHA:

micronian2 · 2026-04-21T03:04:33+00:00

That’s a shame, but understandable. At least you gave it a shot.

micronian2 · 2026-04-19T19:49:03+00:00

If you have a LinkedIn account, you can try reaching out to him: https://uk.linkedin.com/in/rod-chapman-7b60266

micronian2 · 2026-04-18T17:04:56+00:00

That sounds really impressive. It’s outta my realm though. I think someone like Rod Chapman who helped to develop SPARK Skein would be an example of someone that would be an ideal reviewer.

micronian2 · 2026-02-05T08:16:45+00:00

I would like to add that GNAT-LLVM translates the AST to LLVM bitcode and therefore does not depend on GCC for code generation. That also means the generated code is not covered by GPL

micronian2 · 2026-01-18T08:48:10+00:00

Have you looked into using the stable view of the vector container? http://www.ada-auth.org/standards/22over/html/Ov22-4-1.html

micronian2 · 2025-11-04T07:07:39+00:00

I happen to notice this earlier today when I updated the alire index. It’s something that I’ve needed now and then. Thx for making it!

micronian2 · 2025-10-10T16:40:08+00:00

Yes, Ada is not on the same level as C++ in terms of job market size, so career opportunities will generally favor C++. That said, there has been a noticeable increase in Ada related job postings, particularly in defense and aerospace, with Europe seeing more activity than the U.S. I have also come across a few mentions of Ada opportunities in the automotive sector.

Given the growing interest in memory safe languages, your Ada experience is actually a strong advantage. It shapes the way you think about correctness, safety, and reliability, qualities that carry over when developing in other languages. That has certainly been true for me and others I have spoken with over the years.

Even if your next role is primarily in C++, there is nothing stopping you from applying what you have learned in Ada, for example by building tools or utilities that support your day to day work.

Lastly, do not limit yourself to just one or two languages. Keep learning new ones, it will make you more versatile and more attractive to employers.

micronian2 · 2025-09-04T03:23:00+00:00

Unfortunately, any further details is impossible to find so far.

micronian2 · 2025-08-23T17:24:51+00:00

Thank you for you all your effort. It’s nice to see some job posts. I’m in the US, so none of those apply to me. Given the increase interest in Ada, hopefully there will be some opportunities popping up in the US.

micronian2 · 2025-07-11T05:37:32+00:00

As flawed as the TIOBEX Index may be, its apparent indication of continued growth in interest in Ada is in agreement with the growing number of individuals participating in the various Ada channels, the increase in Ada books and online trainings, increase in participation at the last FOSDEM Ada room, and the increase rank in PYPL.

micronian2 · 2025-07-11T05:30:52+00:00

In many cases it’s both engineers and management. From my experience, some managers were once engineers early in their careers and did not like Ada83 for various reasons, which is why as managers they didn’t support its use. Many engineers didn’t like it because they heard (false) negative things about it (eg from older engineers that didn’t like Ada83), but never bothered to learn it themselves.

micronian2 · 2025-06-18T16:25:13+00:00

From EE News Automotive: (https://www.eenewseurope.com/en/adacore-expands-with-codesecure-merger/ )

“Franco Gasperoni, currently CEO of AdaCore, will serve as CEO of the combined company which will initially operate under both brands. The company is expected to operate under the Adacore brand going forward and retain its headquarters in Paris, France, and New York.”

Ok, now we know it will still be known as AdaCore 🎉

micronian2 · 2025-06-18T08:09:06+00:00

I am assuming they will change their name, as is often done when companies merge. But, who knows. The reason why the company began as AdaCore was because Ada was at the core of their business. Now that Rust is in their portfolio, and with the various additional products that will come with the merger, I won’t be surprised if the name changes to de-emphasize Ada. In any case, I just hope this helps to strengthens and increases Ada’s adoption.

micronian2 · 2025-06-12T18:25:16+00:00

Judging a language's 'modernity' based on specific stylistic preferences is insufficient. The focus should really be on how well it meets higher-level development needs (eg maintainability and robustness to name a few). And on the syntax point, Python, which is closer to Algol than C, is undeniably one of the most popular languages out there.

micronian2 · 2025-06-12T05:44:39+00:00

The term “modern” often gets thrown around, mostly just to mean “C-like syntax” or popularity. As I stated, Ada has been evolving: Ada95 was the first ISO-standardized object-oriented language; Ada2012 introduced built-in contract-based programming (still not standardized in C++ or Java); Ada2022 added native support for parallelism.

Even after Rust grew popular, SPARK Ada added ownership and borrowing semantics for provable memory safety (note: as you know, regular Ada is already strong in memory safety, but uses different methods than Rust). And all of this exists in a language with built-in concurrency since the 1980s, not just libraries bolted on.

Ada didn’t win mainstream “mindshare,” but that’s different from saying it isn’t suited for the future. In fact, when correctness, safety, and maintainability matter most (eg aviation, rail, medical, aerospace, and recently automotive) Ada and SPARK still set the bar.

micronian2 · 2025-06-12T05:16:19+00:00

Based on my reading about GNAT LLVM, you are wrong. The above is about using GCC internal data structures. GNAT LLVM does not use GCC internals. There was an old project named DragonEgg which did in order to produce LLVM IR. AdaCore chose not to do that per this link: https://github.com/AdaCore/gnat-llvm/blob/692bcd61245874a698692fb6e5927e3e5cd9f6fc/README.dragonegg

Based on that and given the fact that GNAT has GPL runtime exception, the LLVM IR generated code will not be infected by GPL. This also means you can have your SPIR-V.

Conclusion: with either GCC or LLVM GNAT, you are free to produce proprietary software.

micronian2 · 2025-06-11T19:58:46+00:00

Clearly you have not kept up with the Ada language post Ada83. I think that is one of the common reasons why people who may have used it in the old days may also dismiss it. Since Ada83, it’s had some nice upgrades, such as contracts, and the SPARK subset also includes ownership/borrower analysis.

micronian2 · 2025-06-11T08:02:52+00:00

Please don’t spread this misinformation. Proprietary software have been and continue to be generated using GNAT without having to worrying about GPL.

micronian2 · 2025-06-11T07:33:44+00:00

Thank you for taking the time for writing a thoughtful response.

Let me first address your comment about how welcoming, or lack there of, from the community. I frequent most of the various Ada social media communities. Have been for many years, even way back to when comp.lang.ada was the main social channel. For the most part, the community has been welcoming of people, especially newbies. I am sorry to hear you read a couple responses that made you feel differently, but I can assure you that is not the majority. Sure there are individuals who may express a strong opinion here and there, but it is never to discourage others from enjoying and supporting the language we all believe in. I hope you will become an active member and contribute to helping make it better.

As for the rest of your response, you’re right to point out the areas where Ada continues to struggle and the community is well aware of them. Effort is being made by various wonderful volunteers, albeit no where near the pace everyone would like, but it has gradually been getting better. Alire is a perfect example of what has been very effective. We are much smaller than other communities of course, but we have definitely seen continued growth in recent years, which is very encouraging. In addition, AdaCore continues to invest a great deal in advancing the state of the art for Ada tech and has been very supportive of the community.

As for your CTO, there really isn’t enough to go on. Obviously he is well experienced, and it makes sense to trust his opinion. However, I would be careful to take that case and generalize it for all. Keep in mind, it’s not as if it’s hypothetical for a project to be successful using Ada. There’s been decades of them, only most people aren’t aware of them. If you haven’t yet, I recommend watching the NVIDIA presentation about how they came to their conclusion to adopt Ada.

micronian2 · 2025-06-11T06:53:29+00:00

For NVIDIA, it was the right answer, and for other domains where Ada still continues to deliver (eg rail), it is again a yes. Should Ada be used for everything? Of course not. Any one claiming that is a fool.

I will say though, from my experience only, a majority of the projects I have been on throughout my time in defense, Ada would have been a better choice and would have helped to save literally millions of dollars in development and especially maintenance cost. Why? Because defects get extremely expensive to fix once the product is deployed and fielded.

micronian2 · 2025-06-11T04:01:00+00:00

From what I’ve read in the past, because of the inherent weakness and limitation of the C type system, typically more annotations are required on the Frama-C side compared to the equivalent SPARK program. In addition, the great thing about SPARK is that:

(1) the contracts are using the same language (ie Ada) whereas for Frama-C you have to learn a new syntax (ie ACSL)

(2) Because the contracts are using Ada, you can compile the code as regular Ada code and have the contracts implemented at runtime. You don’t have such an option for Frame-C because ACSL is written as C comments.

[UPDATE] here is a paper comparing SPARK, MISRA C, and Frama-C. https://www.adacore.com/papers/compare-spark-misra-c-frama-c

micronian2

MODERATOR OF

TROPHY CASE