Dropping this here since I have been thinking about it for a while.
Ever since I started working on Ada related projects I feel that Ada as a language is rather under-represented and underrated. There are are various discussions on why this is so, though I feel the biggest gap (besides marketing and social media coverage) between Ada and the more well loved languages (whether modern or not) are the ecosystem options and overall development experience.
Personally, imo the misplaced idea of Ada itself being a dated/“legacy” language is not helpful. The language is arguably more stable, mature and robust than most others out there.
Tying into Alire, I feel that the team has already done an amazing effort on it thus far. Though some options for expanding the spec for including test and dev deps more easily would be nice to have.
“Development experience” is a fair bit vague, though I feel that these are good starting points we can look into:
Installation process and publishing process (some quirks here and there are observed, though generally a good start).
Documentation that is understandable to the not-so technical user (some level of knowledge expected, though not to the extent as those maintaining the software itself). It is difficult finding the balance between eli5 and whatever LLVM’s docs are right now (heavy CS and compiler related background expected). This is a quite a tedious undertaking, and if done properly is most definitely worth of Ada User Awards or similar. (Do not get me started on i18n for docs, it’s a whole other can of worms)
Tooling improvements, though these are generally quite subjective. For instance, you will find people praising Rust compiler diagnostics when gnatprove’s are also pretty good. gnatdocs is nice but not being able to output to md makes publishing docs more of a hassle with newer static site generator options. The foundations are already there, but the devil is in the details because some users would expect a smoother experience using the tools.
On my part I have been working on a project related to wrapping around gnatprove and providing other niceties as a formal verification and compliance toolchain. There’s SBOM, DO-178C, docstring and test checking as well as outputting status badges that fit nicely in a README that is common to other languages like Python. Rust and Go. I will not be talking about that project too much here, if you are interested you can look it up on the forum.
P.S. Maybe I will bring it up in Office Hours when it is ready enough for me to present on, though that is quite some time into the future.
P.P.S. I realise this is a bit last minute, so I would not mind if this were discussed at the next or following Office Hours instead.
Verifying Bit Twiddling and Bit Blasting in Spark: Participant K brings up difficulties with autoactive verification and hitting walls while porting succinct data structures involving bit twiddling, rank, and select on 64-bit integers to Spark. Participant C notes that proving functional correctness for optimized cryptographic code like SHA-3 is challenging, while Participant H recommends consulting Participant L’s blog posts on Spark NACL for full correctness examples. Participant C suggests mapping bit vectors onto arrays of booleans or utilizing Spark lift functional containers for high-level modeling, and Participant K thanks them for the advice.
GNAT Foundry Traffic Light Intersection Demo: Participant B presents the release of the GNAT Foundry Intersection project on GitHub, which features a high-integrity traffic light intersection written in Ada and Spark with functionally correct safety arguments and artificial intelligence instructions encoded in agent and cloud directories with deterministic tooling. Participant B notes positive feedback from aerospace, defense, and automotive customers, including a software architect, and mentions porting the native project to a physical hardware representation using a traffic light with light-emitting diodes and an ST Microelectronics or NXP board. Additionally, Participant H highlights a former employee, Participant M, who implemented a full Ada 83 compiler using artificial intelligence named Turbo Ada available at AdaDoom3 · GitHub as a single 100,000-line C file.
Alire Crate Backlog and Community Management: Participant B addresses the Alire crate submission backlog caused by personnel vacations and unavailability, noting plans to involve Participant F more closely. Participant H expresses concern that multi-week or multi-month delays are problematic and suggests establishing a larger team with an advanced calendar and systematic on-call schedule to handle submissions more rapidly. Participant B agrees to broaden the review list to ensure faster processing.
Ada Rapporteur Group and Object-Based Ownership: Participant H discusses the progress made by the Ada Rapporteur Group on the next version of Ada, directing participants to arg.ada.org to review open GitHub issues and Ada Issues. Participant H highlights recent progress on object-based ownership, which incorporates Rust-like concepts into Ada in a more elegant and accessible manner with a lower entry barrier.
Artificial Intelligence Assisted Code Refactoring and the Rise of Rust: Participant I expresses astonishment after Participant B uses an artificial intelligence Spark converter to refactor an application for an STM32 board while keeping the application programming interface intact. Participant B explains that they used Codeium with the public gnatprove skill to lift Ada code to Spark. Furthermore, Participant B and Participant A share their experiences attending a Rust conference in Montreal, which cost 500 to 600 United States dollars per ticket and drew 500 to 600 attendees, noting frustration with claims regarding unprecedented memory safety. Participant A and Participant B describe Rust as a hacker language with fragmented runtimes and difficult read-through syntax compared to Ada, although acknowledging heavy backing from major companies like Google, Amazon, and Microsoft, while Participant N and Participant H mention potential lessons to learn from features like the borrow checker.
Developing an ST Microelectronics Artificial Intelligence Vision Demo for Ada and Spark: Participant B discusses attending the Embedded World North America trade show in Anaheim and acquiring an N6 development board equipped with a camera, touchscreen, and neural processing unit for local object detection and facial recognition. Participant B explains the data processing pipeline where camera streams split into the neural processing unit for bounding boxes and the CPU for screen rendering, noting that converting the screen-handling C code to Ada revealed a lack of bounds checking that caused application crashes upon receiving invalid data. Participant B describes implementing fault handling in Ada along with a physical user button to inject bad data into the stream, while Participant C discusses aiming for functional correctness alongside Silver-level absence of runtime errors, and Participant I suggests developing an oscilloscope and logic analyzer demo featuring signal processing and fast Fourier transforms.
Local Ada and Spark Meetups and Academic Adoption: Participant B outlines plans to launch a local Ada and Spark meetup in Ottawa around November, inviting local companies such as Participant E’s team and reaching out to the University of Ottawa for a venue. Participant I and Participant A discuss university adoption challenges, noting that institutions often prefer teaching C++ or Java and rely on Linux on Raspberry Pi or Arduino for embedded classes due to instructor retirements and industry trends. Participant A criticizes Arduino coding practices like using for-loops as timers, whereas Participant I views Arduino as a helpful reference resource for device ecosystems, and Participant B concludes that Ada’s strongest value proposition remains within high-integrity systems rather than general non-embedded markets.
FOSDEM and Alire Ada Graphical User Interface Presentation: Participant G reports on finalizing submission text for FOSDEM over the weekend, requesting a half-day slot to optimize presentation scheduling, and invites community members to participate or present in the developer room. Additionally, Participant A demonstrates a new native graphical user interface library for Ada called Ada 2, which is based on Simple DirectMedia Layer bindings and features cascading style sheet-like styling and flexbox support. Participant A notes that they compiled an example in under 15 minutes, though the libraries require Simple DirectMedia Layer 3 and GPR Build, with packaging underway for Alire.
Transition from ADL to the STM32 G4 Nucleo Board: Participant I asked Participant A for guidance on teaching bare-metal programming using the older STM32 F4 Discovery board and ADL. Participant A advised against teaching with ADL because they want to move away from it due to its STM32-specific nature, instead recommending the STM32 G4 Nucleo board (G431KB) because their crate chain is fully prepared and functional. Participant I agreed with this direction.
Generic Driver Framework and Crate Architecture: Participant A demonstrated their working crate chain via screen share, showcasing a portable driver framework built entirely on generics rather than object-oriented techniques. Participant A explained that components like I2C, GPIO, frame buffer, debug, touch, SDRAM, SPI, RNG, and machine types are organized as separate crates that compose properly using the package manager (`alr`), avoiding large monolithic chunks.
USART Component Structure and Planes: Participant A detailed the structural design using a USART example, dividing it into three core concepts: types, generic control planes, and generic data planes, all bound together by an interface crate. Participant I inquired about register mapping, and Participant A explained that board definition crates link MCU-specific peripherals and clock trees from the SVD and MCU crates to the generic interface functions.
Raspberry Pi Pico 2 Support and Community Runtimes: Participant I asked if the Raspberry Pi Pico 2 (RP2350) could be supported similarly, and Participant A confirmed it is supported up to the runtime level via Participant C’s community-driven runtimes, which offer full Ada core support such as light tasking. Participant I requested links to these resources, and Participant A agreed to provide them.
Community Contribution Opportunities and Zephyr Critique: Participant A identified community needs, suggesting that contributors build specific drivers (such as NOR flash, BMP390E, W25, and SRAM) on top of their portable generic framework. Participant I asked about using Zephyr as a normalizing low-level layer, but Participant A strongly critiqued Zephyr, arguing it introduces excessive friction, a nightmare of shims, and relies heavily on underlying C code rather than pure Ada from the registers up.
Zephyr Embedded Application Talks and AI-Assisted Code Generation: Participant A recommended Participant J’s workshop presentation on Zephyr for deeper context on the associated architectural friction. Additionally, Participant A noted that AI tools can effectively assist in generating platform-specific driver methods when provided with their generic crate interfaces. Participant I committed to purchasing the $16 STM32 G4 Nucleo board to test the framework.
Renesas S7 Board Experience and Hardware Brick Recovery: Participant I mentioned an interest in using an older Renesas S7 board. Participant A shared that they attempted to use the Renesas S7 board and had to generate an SVD file using AI due to missing vendor support, but accidentally corrupted protected memory and bricked their own device. Participant A explained that unbricking is possible using raw USART headers for a full memory reset, and suggested Participant C could help nail down the runtime for it.
