I actually think Ada would be an easier sell today than it was back then. It seems to me that the software field overall has become more open to a wider variety of languages and concepts, and knowing Ada wouldn't be perceived as widely as career pidgeonholing today. Plus, Ada is having a bit of a resurgence with stuff like NVidia picking SPARK.
But, not because I think schools and colleges would jump at the opportunity and start training the next batch of students in said language just because some government department or a bunch of large corporations supported and/or mandated it. Mostly because that hasn't actually panned out in reality for as long as I can remember. Trust me, I _wish_ schools and colleges were that proactive or even in touch with with the industry needs, but... (shrug!)
Like I said, I still think the original argument is flawed, at least in the general case, because any good organization shouldn't be hiring "language X" programmers, they should be hiring good programmers who show the ability to transfer their problem solving skills across the panopticon of languages out there. Investing in getting a _good_ programmer upskilled on a new language is not as expensive as most organizations make it out to be.
Now, if you go and pick some _really obscure_ (read "screwed up") programming language, there's not much out there that can help you either way, so... (shrug!)
DoD did enforce a requirement for Ada but universities and others did not follow.
The JSF C++ guidelines were created for circumventing the DoD Ada mandate (as discussed in the video).
In the video, the narrator also claims that Ada compilers were expensive and thus students were dissuaded from trying it out. However, in researching this comment I founds that the Gnat project has been around since the early 90s. Maybe it wasn't complete enough until much later and maybe potential students of the time weren't using GNU?
The GNAT project started in 1992 when the United States Air Force awarded New
York University (NYU) a contract to build a free compiler for Ada to help
with the Ada 9X standardization process. The 3-million-dollar contract
required the use of the GNU GPL for all development, and assigned the
copyright to the Free Software Foundation.
Everyone likes to crap on C++ because it's (a) popular and (b) tries to make everyone happy with a ton of different paradigms built-in. But you can program nearly any system with it more scalably than anything else.
That's quite debatable. C++ is well known to scale poorly.
Secondly, when companies say "we can't hire enough X" what they really mean is "X are too expensive". They probably have some strict salary bands and nobody had the power to change them.
In other words there are plenty of expensive good Ada and C++ programmers, but there are only cheap crap C++ programmers.
Using C++ vs wishing an Ada ecosystem into existence may have been one of the few successful cost saving measures.
Keep in mind that these are not normal programmers. They need to have a security clearance and fulfill specific requirements.
You’ll be interviewed, your family, your neighbors, your school teachers, your past bosses, your cousin once removed, your sheriff, your past lovers, and even your old childhood friends. Your life goes under a microscope.
If I were back on the job market, I’d be demanding a big premium to go through it again. It’s very intrusive, puts significant limitations on where you can go, and adds significant job uncertainty (since your job is now tied to your clearance).
Why require that companies use a specific programming language instead of requiring that the end product is good? > And the F35 and America's combat readiness would be in a better place today with Ada instead of C++.
What is the evidence for this? Companies selling Ada products would almost certainly agree, since they have a horse in the race. Ada does not automatically lead to better, more robust, safer or fully correct software.
Your line of argument is dangerous and dishonest, as real life regrettably shows.[0]
[0]: https://en.wikipedia.org/wiki/Ariane_flight_V88
> The failure has become known as one of the most infamous and expensive software bugs in history.[2] The failure resulted in a loss of more than US$370 million.[3]
> The launch failure brought the high risks associated with complex computing systems to the attention of the general public, politicians, and executives, resulting in increased support for research on ensuring the reliability of safety-critical systems. The subsequent automated analysis of the Ariane code (written in Ada) was the first example of large-scale static code analysis by abstract interpretation.[9]
Relative to what? There are formal verification tools for other languages. I have heard Ada/SPARK is good, but I do not know the veracity of that. And Ada companies promoting Ada have horses in the race.
And Ada didn't prevent the Ada code in Ariane 5 from being a disaster.
> The programming language is just a small piece of the puzzle. But an important one.
100% true, but the parent of the original post that he agreed with said:
> And the F35 and America's combat readiness would be in a better place today with Ada instead of C++.
What is the proof for that, especially considering events like Ariane 5?
And Ada arguably has technical and non-technical drawbacks relative to many other languages.
When I tried Ada some weeks ago for a tiny example, I found it cumbersome in some ways. Is the syntax worse and more verbose than even C++? Maybe that is just a learning thing, though. Even with a mandate, Ada did not catch on.
That's a weak argument to say that Ada could not lead to a better place in term of software. It's like saying that it's not safer to cross at a crosswalk because you know someone who died while crossing on one.
(But I guess that's fair for you to say that, as the argument should probably be made by the people that say that Ada would be better, and because they made a claim without evidences, you can counterclaim without any evidence :-) )
There are no programming language that can prevent a software for working correctly outside of the domain for which the software is written, which was the case for Ariane 501. Any language that would have been used to write the same software for Ariane 4 may have led to the same exact error. Ariane 501 failure is a system engineering problem here, not a software problem (even if in the end, the almost last piece in the chain of event is a software problem)
Ariane 5 is a nice anti-ada catchphrase, but ada is probably the most used language for war machines in the United States.
now the argument can be whether or not the US military is superior to X; but the fact that the largest military in the world is filled to the brim with warmachines running ada code is testament itself to the effectiveness of the language/dod/grant structure around the language.
would it be better off in c++? I don't know about that one way or the other , but it's silly pretend ada isn't successful.
Ada is almost non-existent outside its niche.
The main companies arguing for Ada appear to be the ones selling Ada services, meaning they have a horse in the race.
I barely have any experience at all with Ada. My main impression is that it, like C++, is very old.
[0]: https://www.militaryaerospace.com/communications/article/167...
> The Defense Department`s chief of computers, Emmett Paige Jr., is recommending a rescission of the DOD`s mandate to use the Ada programming language for real-time, mission-critical weapons and information systems.
With C++ it's just too easy to make mistakes.
I know others who learned ADA on the job.
It’s not too terrible.
> And the F35 and America's combat readiness would be in a better place today with Ada instead of C++
What’s the problem with the F35 and combat readiness? Many EU countries are falling over each-other to buy it.
They are not buying it for its capabilities though, but to please their US ally/bully which would have retaliated economically otherwise.
See the very recent Swiss case were theirs pilots had chosen another aircraft (the french Rafale), only to be disavowed by their politics later on.
Nobody respects weakness, not even an ally. Ironically showing a spine and decoupling from the US on some topics would have hurt more short term, but would have been healthier in the long term.
I share the same opinion. If you're (on paper) the biggest economic block in the world, but you can be so easily bullied, then you've already failed >20 years ago.
But I don't think it was bullying, but the other way around. EU countries were just buying favoritism for US military protection, because it was still way cheaper than ripping the bandaid and building its own domestic military industry of similar power and scale.
Most defense spending uses the same motivation. You're not seeking to buying the best or cheapest hardware, you seek to buy powerful friends.
For example, the UK would like to use its own air-to-ground missile (the spear missile) with its own F-35 jets, but it's held back by Lockheed Martin's Block 4 software update delays.
Block 4 is very delayed for starters.
It's because we are obliged to want more freedom.
> And the F35 and America's combat readiness would be in a better place today with Ada instead of C++.
What is the evidence for this? Companies selling Ada products would almost certainly agree, since they have a horse in the race. Ada does not automatically lead to better, more robust, safer or fully correct software.
Your line of argument is dangerous and dishonest, as real life regrettably shows.[0]
[0]: https://en.wikipedia.org/wiki/Ariane_flight_V88
> The failure has become known as one of the most infamous and expensive software bugs in history.[2] The failure resulted in a loss of more than US$370 million.[3]
> The launch failure brought the high risks associated with complex computing systems to the attention of the general public, politicians, and executives, resulting in increased support for research on ensuring the reliability of safety-critical systems. The subsequent automated analysis of the Ariane code (written in Ada) was the first example of large-scale static code analysis by abstract interpretation.[9]
I can think of two reasons. First, achieving the same level of correctness could be cheaper using a better language. And second, you have to assume that your testing is not 100% correct and complete either. I think starting from a better baseline can only be helpful.
That said, I have never used formal verification tools for C or C++. Maybe they make up for the deficiencies of the language.
If Ada was "better" than C++, why did Ada not perform much better than C++, both in regards to safety and correctness (Ariane 5), and commercially regarding its niche and also generally? Lots of companies out there could have gotten a great competitive edge with a "better" programming language. Why did the free market not pick Ada?
You could then argue that C++ had free compilers, but that should have been counter-weighed somewhat by the Ada mandate. Why did businesses not pick up Ada?
Rust is much more popular than Ada, at least outside Ada's niche. Some of that is organic, for instance arguably due to Rust's nice pattern matching and modules and crates. And some of that is inorganic, like how Rust evangelists through force, threats[0], harassment[1] and organized and paid media spam force Rust.
I also tried Ada some time ago, trying to write a tiny example, and it seemed worse than C++ in some regards. Though I only spent a few hours or so on it.
[0]: https://github.com/microsoft/typescript-go/discussions/411#d...
[1]: https://lkml.org/lkml/2025/2/6/1292
> Technical patches and discussions matter. Social media brigading - no than\k you.
> Linus
A language that makes avoiding certain important classes of defects easier and more productive.
>how do you judge whether one programming language is better than another
Analytically, i.e. by explaining and proving how these classes of bugs can be avoided.
I don't find empirical studies on this subject particularly useful. There are too many moving parts in software projects. The quality of the team and its working environment probably dominates everything else. And these studies rarely take productivity and cost into consideration.
https://www.ghs.com/products/ada_optimizing_compilers.html
https://www.ptc.com/en/products/developer-tools/apexada
https://www.ddci.com/solutions/products/ddci-developer-suite...
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
What is true, is that those vendors, and many others, like UNIX vendors that used to have Ada compilers like Sun, paying for Ada compilers was extra, while C and C++ were already there on the UNIX developers SKU (a tradition that Sun started, having various UNIX SKUs).
So schools and many folks found easier to just buy a C or C++ compiler, than an Ada one, with its price tags.
Something that has helped Ada is the great work done by Ada Core, even if a few love hating them. They are the major sponsor for ISO work, and spreading Ada knowledge on the open source community.
> The failure has become known as one of the most infamous and expensive software bugs in history.[2] The failure resulted in a loss of more than US$370 million.[3]
> The launch failure brought the high risks associated with complex computing systems to the attention of the general public, politicians, and executives, resulting in increased support for research on ensuring the reliability of safety-critical systems. The subsequent automated analysis of the Ariane code (written in Ada) was the first example of large-scale static code analysis by abstract interpretation.[9]
It is just an example that it is possible to write garbage programs in any programming language, regardless if it is Rust or any other supposedly safer programming language.
A program written in C, but compiled with the option to trap on overflow errors would have behaved identically to the Ada program of Ariane.
A program where exceptions are ignored would have continued to run, but most likely the rocket would have crashed anyway a little later due to nonsense program decisions and the cause would have been more difficult to discover.
A better argument would have been based on statistics. But that might both be difficult to do, and statistics can also be very easy to manipulate and difficult to handle correctly.
I think companies should be free to choose any viable option, and then have requirements that the process and end product is good. Mandating Ada or other programming languages, doesn't seem like it would have prevented Ariane 5, and probably wouldn't improve safety, security or correctness, instead just open the door for limiting competition and cartels and false sense of security. I believe that one should never delegate responsibility to the programming language, more that programmers, organizations and companies are responsible for which languages they choose and how they use them (for instance using a formally verified subset). On the other hand, having standards and qualifications like ISO 26262 and ASIL-D, like what Ferrocene is trying to do with their products for Rust, is fine, I believe. Even though, specifically, some things about the Ferrocene-derived specification seem very off.
I’m sure I’m idealizing it, but at least I’m not demonizing it like folks did back in the day.
Are you sure? I cannot even find Ada in [0].
I tried modifying some Hello World example in Ada some weeks ago, and I cannot say that I liked the syntax. Some features were neat. I had some trouble with figuring out building and organizing files. Like C++, and unlike Rust I think, there are multiple source file types, like how C++ has header files. I also had trouble with some flags, but I was trying to use some experimental features, so I think that part was on me.
[0]: https://redmonk.com/sogrady/2025/06/18/language-rankings-1-2...
The main issue is mission assurance. Using the stack or the heap means your variables aren't always at the same memory address. This can be bad if a particular memory cell has failed. If every variable has a fixed address, and one of those addresses goes bad, a patch can be loaded to move that address and the mission can continue.
Your mention of STL makes it sound like you're talking about C++. But I don't know of any C++ compiler that lets you completely avoid use of the stack, even if you disable the usual suspects (RTTI and exceptions). Sure, you'd have to avoid local variables, defined within a function's body (or at block scope), but that's nowhere near enough.
* The compiler would need to statically allocate space for every function's parameters and return address. That's actually how early compilers did work, but today it would be inefficient because there are surely so many functions defined in a program's binary compared to the number being executed at any given time. (Edit: I suppose you already need the actual code for those functions, so maybe allocating room for their parameters is not so bad.)
* It would also mean that recursion would not work, even mutual recursion (so you'd need runtime checks because this would be hard to detect at compile/link time), although I suspect this is less of a problem than it sounds, but I'm not aware of a C++ compiler that supports it.
* You'd also need to avoid creating any temporary variables at all e.g. y = a + b + c would not be allowed if a,b,c are non-trivial types. (y = a + b would be OK because the temporary could be constructed directly into y's footprint, or stored temporarily in the return space of the relevant operator+(), which again would be statically allocated).
Is that really what you meant? I suspect not, but without all that your point about avoiding the stack doesn't make any sense.
In most other surviving CPU ISAs the return address is saved in a register and it is easy to arrange in a compiler to use only procedure arguments that are passed in registers, the only price being paid for this being a reasonable upper limit for the number of parameters of a function, e.g. 12 or 24, depending on the number of general-purpose registers (e.g. 16 or 32). For the very rare case when a programmer would want more parameters, some of them should be grouped into a structure.
With this convention, which normally should not be a problem, there is no need for a call stack. There can be software managed stacks, which can be used even for implementing recursion, when that is desired.
The use of static memory for passing function arguments was necessary only in the very early computers, which were starved in registers.
What do you get by doing it like this?
Also, in your described structure, how do you handle nested function calls? I'm sure there exists a convoluted scheme that does this, but not sure with the current call assumptions.
You also lose ABI compatibility with a bunch of stuff.
And regardless, I mostly program in Risc-v and ARM -most compiles like to pass arguments on the registers, but use the stack anyway for local context.
I don't think it's too hard to imagine a compiler that does that, although it would obviously be very limited in functionality (nesting would be disallowed as you note, or I guess limited to the number of registers you're willing to waste on it...).
This seems like a rather manual way to go about things for which an automated solution can be devised. Such as create special ECC memory where you also account for entire cell failure with Reed-Solomon coding or some boot process which blacklists bad cells etc.
This is what make remote debugging possible. It is impossible to do interactive remote debugging over a ultra low bandwidth link. If everything have static address and deterministic static, you can have a exact copy on ground and debug there.
You can also have deterministic dynamic - the satellite could transmit its dynamic state (a few bits signifying which memory cells failed) and then you proceed deterministically on the ground.
A local exact replica with deterministic state save lots of time.
Where do you place the variables then? as global variables? and how do you detect if a memory cell has gone bad?
That may be a perfectly good solution in many embedded environments, but in most other context's global variables are considered bad design or very limiting and impractical.
Global mutable variables, and they usually tend to be grouped into singletons (solving initialization issues, and fewer people bat an eye)
For instance, how would better tooling help with storing a TCP buffer in global memory?
The first will be a real pain, as you now have 3 global variables, and the second will look pretty much like multi-threaded Rust running on a normal OS, but with some extra logic to handle the buffer growing too big.
You can probably squeeze more performance out of the C code, specially if you know your system in-depth, but (from experience) it's very easy to lose track of the program's state and end up shooting your foot.
So it's mostly about the absence of abstraction, in the C example? C++ would offer the same convenience (with std::mutex and std::array globals), but in C it's more of a hassle. Gotcha.
One more question because I'm curious - where would you anticipate C would be able to squeeze out more performance in above example?
> If every variable has a fixed address, and one of those addresses goes bad, a patch can be loaded to move that address and the mission can continue.
You can and do put the stack and heap pool at fixed memory ranges, so you can always do this. I'm not sold at all with this reasoning.
A good example of what I'm talking about is a program that I was peripherally involved with about 15 years ago. The lead wanted to abstract the mundane details from the users (on the ground), so they would just "register intent" with the spacecraft, and it would figure out how to do what was wanted. The lead also wanted to eliminate features such as "memory dump", which is critical to the anomaly resolution process. If I had been on that team, I would have raised hell, but I wasn't, and at the time, I needed that team lead as an ally.
What does the OS do? I don’t know about aerospace specifically, but plenty of embedded microcontroller systems don’t have an OS, and I would assume that having an OS is a massive risk against any mission assurance goals, no?
The main purpose of the OS is to centralize, schedule, and manage the resources needed for the mission. It's usually pretty lightweight. Different philosophies are used on different missions. The OS risks can be mitigated. Usually there's a backup "golden copy" OS that can boot if needed. There's also "Safe Mode", which prioritizes communications with the ground, so anomalies can be worked.
So does being able to download a new version of software that uses different memory addresses. The point is if you are able to patch software, you are able to patch memory maps.
Or maybe I would use an MMU but drive it with a kernel written in the old fashioned way with no allocation. It would depend on what hardware I had available and what faults I wanted to survive.
(I’m not an aerospace software developer.)
You could have two copies of the OS mapped to different memory regions. The CPU would boot with the first copy, if it fails watchdog would trigger and the CPU could try to boot the second copy.
I mean, even when I have the codebase readily accessible and testable in front of my eyes, I never trust the tests to be enough ? I often spot forgotten edge cases and bugs of various sort in C/embedded projects BECAUSE I run the program, can debug and spot mem issues and whole a lot of other things for which you NEED to gather the most informations you can in order to find solutions ?
I actually do this as well, but in addition I log out a message like, "value was neither found nor not found. This should never happen."
This is incredibly useful for debugging. When code is running at scale, nonzero probability events happen all the time, and being able to immediately understand what happened - even if I don't understand why - has been very valuable to me.
In fact, not using a default (the else clause equivalent) is ideal if you can explicitly cover all cases, because then if the possibilities expand (say a new value in an enum) you’ll be annoyed by the compiler to cover the new case, which might otherwise slip by.
fn g(x: u8) { match x { 0..=10 => {}, 20..=200 => {},
}That for example would complain about the ranges 11 to 19 and 201 to 255 not being covered.
You could try to map ranges to enum values, but then nobody would guarantee that you covered the whole range while mapping to enums so you’d be moving the problem to a different location.
Rust approach is not flawless, larger data types like i32 or floats can’t check full coverage (I suppose for performance reasons) but still quite useful.
x->foo();
if (x == null) {
Return error…;
}
I would say that using unreachable() in mission critical software is super dangerous, moreso than an allocation failing. You want to remove all potential for UB (ie safe rust with no or minimal unsafe, not sprinkling in UB as a form of documentation).
The projects that I've worked on, unconditionally define it as a thing that crashes (e.g. `std::abort` with a message). They don't actually use that C/C++ thing (because C23 is too new), and apparently it would be wrong to do so.
Funnily enough, Rust's pattern matching, an innovation among systems languages without GCs (a small space inhabited by languages like C, C++ and Ada), may matter more regarding correctness and reliability than its famous borrow checker.
Maybe it is too primitive to be considered proper pattern matching, as pattern matching is known these days. Pattern matching has actually evolved quite a bit over the decades.
Thanks for sharing
allocation/deallocation from/to the free store (heap)
shall not occur after initialization.
I can't think of anything about "modern AI-guided drones" that would change the fundamental mechanics. Some systems support very elastic and dynamic workloads under fixed allocation constraints.
The overwhelming majority of embedded systems are desired around a max buffer size and known worst case execution time. Attempting to balance resources dynamically in a fine grained way is almost always a mistake in these systems.
Putting the words "modern" and "drone" in your sentence doesn't change this.
These systems have limits but they are extremely high and in the improbable scenario that you hit them then it is a priority problem. That design problem has mature solutions from several decades ago when the limits were a few dozen simultaneous tracks.
In this way you can use pools or buffers of which you know exactly the size. But, unless your program is always using exactly the same amount of memory at all times, you now have to manage memory allocations in your pool/buffers.
Where dynamic allocation starts to be really helpful is if you want to minimize your peak RAM usage for coexistence purposes (eg you have other processes running) or want to undersize your physical RAM requirements by leveraging temporal differences between different parts of code (ie components A and B never use memory simultaneously so either A or B can reuse the same RAM). It also does simplify some algorithms and also if you’re ever dealing with variable length inputs then it can help you not have to reason about maximums at design time (provided you just correctly handle an allocations failure).
stdio.h is fine in some embedded contexts, and very very not fine in others
Actual code i have seen with my own eyes. (Not in F-35 code)
Its a way to avoid removing an unused parameter from a method. Unused parameters are disallowed, but this is fine?
I am sceptical that these coding standards make for good code!
Notably this document is from 2005. So that's after C++ was standardized but before their second bite of that particular cherry and twenty years before its author, Bjarne Stroustrup suddenly decides after years of insisting that C++ dialects are a terrible idea and will never be endorsed by the language committee, that in fact dialects (now named "profiles") are the magic ingredient to fix the festering problems with the language.
While Laurie's video is fun, I too am sceptical about the value of style guides, which is what these are. "TABS shall be avoided" or "Letters in function names shall be lowercase" isn't because somebody's aeroplane fell out of the sky - it's due to using a style Bjarne doesn't like.
I do early returns in code I write, but ONLY because everybody seems to do it. I prefer stuff to be in predictable places: variables at the top, return at the end. Simpler? Delphi/Pascal style.
There is an element of taste. Don’t create random early returns if it doesn’t improve the code. But there are many, many cases where it makes the code much more readable and maintainable.
It might be a good guideline.
Its not a good rule because slavishly following results in harder to follow code written to adhere to it.
Basically, you have code in an "if" statement, and if you return early in that if statement, you might have code that you needed to run, but didnt.
Forcing devs to only "return once" encourages the dev to think through any stateful code that may be left in an intermediate state.
In practice, at my shop, we permit early returns for trivial things at the top of a function, otherwise only one return at the bottom. That seems to be the best of both worlds for this particular rule.
I think you're talking about this "goto fail" bug?
https://teamscale.com/blog/en/news/blog/gotofail
> In practice, at my shop, we permit early returns for trivial things
Are you also writing C or similar? If so, then this rule is relevant.
In modern languages, there are language constructs to aid the cleanup on exit, such as using(resource) {} or try {} finally {} It really does depend on if these conveniences are available or not.
For the rest of us, the opposite of "no early return" is to choose early return only sometime - in cases where results in better code, e.g. shorter, less indented and unlikely to cause issues due to failure to cleanup on exit. And avoid it where it might be problematic. In other words, to taste.
> Kent Beck, Martin Fowler, and co-authors have argued in their refactoring books that nested conditionals may be harder to understand than a certain type of flatter structure using multiple exits predicated by guard clauses. Their 2009 book flatly states that "one exit point is really not a useful rule. Clarity is the key principle: If the method is clearer with one exit point, use one exit point; otherwise don’t".
https://en.wikipedia.org/wiki/Structured_programming#Early_e...
this thinking is quite different to say, 25 years earlier than that, and IMHO the programming language constructs available play a big role.
For example of the rule, a function might allocate, do something and then de-allocate again at the end of the block. A second exit point makes it easy to miss that de-allocation, and so introduce memory leaks that only happen sometimes. The code is harder to reason about and the bugs harder to find.
source:
> A problem with early exit is that cleanup statements might not be executed. ... Cleanup must be done at each return site, which is brittle and can easily result in bugs.
https://en.wikipedia.org/wiki/Structured_programming#Early_r...
About 90% of us will now be thinking "but that issue doesn't apply to me at all in $ModernLang. We have GC, using (x) {} blocks, try-finally, or we have deterministic finalisation, etc."
And they're correct. In most modern languages it's fine. The "no early returns" rule does not apply to Java, TypeScript, C#, Rust, Python, etc. Because these languages specifically made early return habitable.
The meta-rule is that some rules persist past the point when they were useful. Understand what a rule is for and then you can say when it applies at all. Rules without reasons make this harder. Some rules have lasted: we typically don't use goto at all any more, just structured wrappers of it such as if-else and foreach
Early return is perfectly manageable in C as long as you aren't paranoid about function inlining. You just have a wrapper that does unconditional setup, passes the acquired resources to a worker, and unconditionally cleans up. Then the worker can return whenever it likes, and you don't need any gotos either.
Right, so you allow early return only in functions that do not have any setup and clean-up - where it's safe. Something like "pure" functions. And you describe a way to extract such functions from others.
My memory might be lapsing here, but I don't think MISRA has such a rule. C89/C90 states that _external_ identifiers only matter up to their first 6 characters [1], while MISRA specifies uniqueness up to the first 31 characters [2].
[1] https://stackoverflow.com/questions/38035628/c-why-did-ansi-...
[2] https://stackoverflow.com/questions/19905944/why-must-the-fi...
And boiling down these guidelines to style guides is just incorrect. I've never had a 'nit: cyclomatic complexity, and uses dynamic allocation'.
Comments like yours are difficult because they’re not actionable or able to be responded to in a way you’ll find satisfying if you don’t link to the comments that you mean.
Programming language flamewars have always been lame on HN and we have no problem taking action against perpetrators when we’re alerted to them.
I doubt I can satisfy you as to whether I'm somehow a paid evangelist, I remember I got a free meal once for contributing to the OSM project, and I bet if I dig further I can find some other occasion that, if you spin it hard enough can be justified as "payment" for my opinion that Rust is a good language. There was a nice lady giving our free cookies at the anti-racist counter-protests the other week, maybe she once met a guy who worked for an outfit which was contracted to print a Rust book? I sense you may own a corkboard and a lot of red string.
(void) a;
https://godbolt.org/z/zYdc9ej88
clang gets this right.
and assigning to std::ignore works for both.
I encounter this when trying to do best-effort logging in a failure path. I call some function to log and error and maybe it fails. If it does, what, exactly, am I going to do about it? Log harder?
When my database logging fails, I write a file that logs the database fail (but not the original log file).
When my file logging fails, depending on application, I'll try another way of getting the information (the fact that for file logging failed) out - be that an http request or an email or something else.
Databases fail, file systems fill up. Logging logging failures is extremely important.
I like to have a separate monitoring process that monitors my process and a separate machine in a different datacenter monitoring that. But at the end of the day, the first process is still going to do try to log, detect that it failed, try the final backup log and then signal to its monitor that it’s in a bad state. It won’t make any decisions that depend on whether the final backup logging succeeds or fails.
While maybe 10% of rules are sensible, these sensible rules also tend to be blindingly obvious, or at least table stakes on embedded systems (e.g. don't try to allocate on a system which probably doesn't have a full libc in the first place).
_ = a;
Isn't it just bad design that makes both experimenting harder and for unused variables to stay in the code in the final version?
It's extremely annoying until it's suddenly very useful and has prevented you doing something unintended.
In almost every code base I have worked with where warnings weren't compile errors, there were hundreds of warnings. Therefore it just best to set all warnings as errors and force people to correct them.
> Unless you're working with barbarians who commit code that complies with warnings to your repo and there is 0 discipline to stop them.
I work with a colleague that doesn't compile/run the code before putting up a MR. I informed my manager who did nothing about it after he did it several times (this was after I personally told him he needed to do it and it was unacceptable).
This BTW this happens more often than you would expect. I have read PRs and had to reject them because I read the code and they wouldn't have worked, so I know the person had never actually run the code.
I am quite a tidy programmers, but it difficult for people even to write commit messages that aren't just "fixed bugs".
It's kind of like the olden days.
It's a slightly different mindset, for sure, but having gofmt bitch about stuff before you commit it rather than have the compiler bitch about it helps you "clean as you go" rather than writing some hideous ball of C++ and then a day of cleaning the stables once it actually runs. Or at least it does for me...
This BTW can cause issues with dependency chains and cause odd compile issues as a result.
There are many areas of software where bureaucracy requires MISRA compliance, but that aren't really safety-critical. The code is a hot mess. There are other areas that require MISRA compliance and the domain is actually safety-critical (e.g. automotive software). Here, the saving grace is (1) low complexity of each CPU's codebase and (2) extensive testing.
To people who want actual safety, security, portability, I tell them to learn from examples set by the Linux kernel, SQLite, OpenSSL, FFMpeg, etc. Modern linters (even free ones) are actually valuable compared to MISRA compliance checkers.
[1] https://ieeexplore.ieee.org/abstract/document/4658076
[2] https://repository.tudelft.nl/record/uuid:646de5ba-eee8-4ec8...
In my opinion, the MISRA C++ 2023 revision is a massive improvement over the 2008 edition. It was a major rethink and has a lot more generally useful guidance. Either way, you need to tailor the standards to your project. Even the MISRA standards authors agree:
"""
Blind adherence to the letter without understanding is pointless.
Anyone who stipulates 100% MISRA-C coverage with no deviations does not understand what the are asking for.
In my opionion they should be taken out and... well... Just taken out.
- Chris Hill, Member of MISRA C Working Group (MISRA Matters Column, MTE, June 2012
(void) a;
#if otherbuild
dosomething(param);
#endif
How does the code work with timing? It counts cycles?
Honestly I think that's probably the correct way to write high reliability code.
Which therein lies the clue. They wrote software that was simply unmaintainable. Autogenerated code isnt any better.
The idea that processors from the last decade were slower than those available today isn't a novel or interesting revelation.
All that means is that 10 years ago you had to rely on humans to write the code that today can be done more safely with auto generation.
50+ years of off by ones and use after frees should have disabused us of the hubristic notion that humans can write safe code. We demonstrably can't.
In any other problem domain, if our bodies can't do something we use a tool. This is why we invented axes, screwdrivers, and forklifts.
But for some reason in software there are people who, despite all evidence to the contrary, cling to the absurd notion that people can write safe code.
No. It means more than that. There's a cross-product here. On one axis, you have "resources needed", higher for code gen. On another axis, you have "available hardware safety features." If the higher resources needed for code gen pushes you to fewer hardware safety features available at that performance bucket, then you're stuck with a more complex safety concept, pushing the overall system complexity up. The choice isn't "code gen, with corresponding hopefully better tool safety, and more hardware cost" vs. "hand written code, with human-written bugs that need to be mitigated by test processes, and less hardware cost." It's "code gen, better tool safety, more system complexity, much much larger test matrix for fault injection" vs "human-written code, human-written bugs, but an overall much simpler system." And while it is possible to discuss systems that are so simple that safety processors can be used either way, or systems so complex that non-safety processors must be used either way... in my experience, there are real, interesting, and relevant systems over the past decade that are right on the edge.
It's also worth saying that for high-criticality avionics built to DAL B or DAL A via DO-178, the incidence of bugs found in the wild is very, very low. That's accomplished by spending outrageous time (money) on testing, but it's achievable -- defects in real-world avionics systems overwhelming are defects in the requirement specifications, not in the implementation, hand-written or not.
Do you have any evidence for "probably"?
See https://www.safetyresearch.net/toyota-unintended-acceleratio...
"I know for a fact that Italian cooks generate spaghetti, and the deceased's last meal contained spaghetti, therefore an Italian chef must have poisoned him"
It is impossible for a simulink model to accidentally type `i > 0` when they meant `i >= 0`, for example. Any human who tells you they have not made this mistake is a liar.
Unless there was a second uncommanded acceleration problem with Toyotas, my understanding is that it was caused by poor mechanical design of the accelerator pedal that caused it to get stuck on floor mats.
In any case, when we're talking about safety critical control systems like avionics, it's better to abstract away the actual act of typing code into an editor, because it eliminates a potential source of errors. You verify the model at a higher level, and the code is produced in a deterministic manner.
The Simulink Coder tool is a piece of software. It is designed and implemented by humans. It will have bugs.
Autogenerated code is different from human written code. It hits soft spots in the C/C++ compilers.
For example, autogenerated code can have really huge switch statements. You know, larger than the 15-bit branch offset the compiler implementer thought was big enough to handle any switch-statement any sane human would ever write? So now the switch jumps backwards instead when trying to get the the correct case-statement.
I'm not saying that Simulink Coder + a C/C++ compiler is bad. It might be better than the "manual coding" options available. But it's not 100% bug free either.
Nobody said it was bug free, and this is a straw man argument of your own construction.
Using Autocode completely eliminates certain types of errors that human C programmers have continued to make for more than half a century.
That's a classic bias: Comparing A and B, show that B doesn't have some A flaws. If they are different systems, of course that's true. But it's also true that A doesn't have some B flaws. That is, what flaws does Autocode have that humans don't?
The fantasy that machines are infallible - another (implicit) argument in this thread - is just ignorance for any professional in technology.
The main flaw of autocode is that a human can't easily read and validate it, so you can't really use it as source code. In my experience, this is one of the biggest flaws of these types of systems. You have to version control the file for whatever proprietary graphical programming software generated the code in the first place, and as much as we like to complain about git, it looks like a miracle by comparison.
It's an interesting question and point, but those are two different things and there is no reason to think you'll get the same results. Why not compile from natural language, if that theory is true?
I admit that's mostly philosphical. But I think saying 'C can autogenerate reliable assembly, therefore a specification can autogenerate reliable C' is also about two different problems.
From https://news.ycombinator.com/item?id=45562815 :
> awesome-safety-critical: https://awesome-safety-critical.readthedocs.io/en/latest/
From "Safe C++ proposal is not being continued" (2025) https://news.ycombinator.com/item?id=45237019 :
> Safe C++ draft: https://safecpp.org/draft.html
Also there are efforts to standardize safe Rust; rust-lang/fls, rustfoundation/safety-critical-rust-consortium
> How does what FLS enables compare to these [unfortunately discontinued] Safe C++ proposals?
Highly recommend checking her other videos out if you like this
Reading through the JSF++ coding standards I see they ban exceptions, ban the standard template library, ban multiple inheritance, ban dynamic casts, and essentially strip C++ down to bare metal with one crucial feature remaining: automatic destructors through RAII. When a variable goes out of scope, cleanup happens. That is the entire value proposition they are extracting from C++, and it made me wonder if C could achieve the same thing without dragging along the C++ compiler and all its complexity.
GLib is a utility library that extends C with better string handling, data structures, and portable system abstractions, but buried within it is a remarkably elegant solution to automatic resource management that leverages a GCC and Clang extension called the cleanup attribute. This attribute allows you to tag a variable with a function that gets called automatically when that variable goes out of scope, which is essentially what C++ destructors do but without the overhead of classes and virtual tables.
The heart of GLib's memory management system starts with two simple macros: g_autofree and g_autoptr. The g_autofree macro is deceptively simple. You declare a pointer with this attribute and when the pointer goes out of scope, g_free is automatically called on it. No manual memory management, no remembering to free at every return path, no cleanup sections with goto statements. The pointer is freed whether you return normally, return early due to an error, or even if somehow the code takes an unexpected path. This alone eliminates the majority of memory leaks in typical C programs because most memory management is just malloc and free, or in GLib's case, g_malloc and g_free.
The g_autoptr macro is more sophisticated. While g_autofree works for simple pointers to memory, g_autoptr handles complex types that need custom cleanup functions. A file handle needs fclose, a database connection needs a close function, a custom structure might need multiple cleanup steps. The g_autoptr macro takes a type name and automatically calls the appropriate cleanup function registered for that type. This is where GLib shows its maturity because the library has already registered cleanup functions for all its own types. GError structures are freed correctly, GFile objects are unreferenced, GInputStream objects are closed and released. Everything just works.
Behind these macros is something called G_DEFINE_AUTOPTR_CLEANUP_FUNC, which is how you teach GLib about your own types. You write a cleanup function that knows how to properly destroy your structure, then you invoke this macro with your type name and cleanup function, and from that moment forward you can use g_autoptr with your type. The macro generates the necessary glue code that connects the cleanup attribute to your function, handling all the pointer indirection correctly. This is critical because the cleanup attribute passes a pointer to your variable, not the variable itself, which means for a pointer variable it passes a double pointer, and getting this wrong leads to crashes or memory corruption.
The third member of this is g_auto, which handles stack-allocated types. Some GLib types like GString are meant to live on the stack but still need cleanup. A GString internally allocates memory for its buffer even though the GString structure itself is on the stack. The g_auto macro ensures that when the structure goes out of scope, its cleanup function runs to free the internal allocations. Heap pointers, complex objects, and stack structures all get automatic cleanup.
What's interesting about this system is how it composes. You can have a function that opens a file, allocates several buffers, creates error objects, and builds complex data structures, and you can simply declare each resource with the appropriate auto macro. If any operation fails and you return early, every resource declared up to that point is automatically cleaned up in reverse order of declaration. This is identical to C++ destructors running in reverse order of construction, but you are writing pure C code that works with any GCC or Clang compiler from the past fifteen years.
The foundation beneath all this is GLib's memory allocation functions. The library provides g_malloc, g_new, g_realloc and friends which are drop-in replacements for the standard C allocation functions. These functions have better error handling because g_malloc never returns NULL. If allocation fails, the program aborts with a clear error message. This might sound extreme but for most applications it is actually the right behavior. When malloc returns NULL in traditional C code, most programmers either do not check it, check it incorrectly, or check it but then do not have a reasonable recovery path anyway. GLib acknowledges this reality and makes the contract explicit: if you cannot allocate memory, the program terminates cleanly rather than stumbling forward into undefined behavior.
Reference counting is another critical component of GLib's memory management, particularly for objects. The GObject system, which is GLib's object system for C, uses reference counting to manage object lifetimes. Every object has a reference count starting at one when created. When you want to keep a reference to an object, you call g_object_ref. When you are done with it, you call g_object_unref. When the reference count reaches zero, the object is automatically destroyed. This is the same model used by shared_ptr in C++ or reference counting in Python, but implemented in pure C.
This also integrates with the autoptr system. Many GLib types are reference counted, and their cleanup functions simply decrement the reference count. This means you can declare a local variable with g_autoptr, the reference count stays positive while you use it, and when the variable goes out of scope the reference is automatically released. If you were the last holder of that reference, the object is freed. If other parts of the code still hold references, the object stays alive. This solves the resource sharing problem that makes manual memory management so difficult in C.
GLib also provides memory pools through GMemChunk and the newer slice allocator, though the slice allocator is being phased out in favor of standard malloc since modern allocators have improved significantly. The concept was to reduce allocation overhead and fragmentation for programs that allocate many small objects of the same size. You create a pool for objects of a specific size and then allocate from that pool quickly without going through the general purpose allocator. When you are done with all objects from that pool, you can destroy the entire pool at once. This pattern shows up in many high-performance C programs but GLib provided it as a reusable component.
The error handling story in GLib deserves special attention because it demonstrates how automatic cleanup enables better error handling patterns. The GError type is a structure that carries error information including a domain, a code, and a message. Functions that can fail take a GError double pointer as their last parameter. If the function succeeds, it returns true or a valid value and leaves the error NULL. If it fails, it returns false or NULL and allocates a GError with details about what went wrong. The calling code checks the return value and if there was an error, examines the GError for details.
The critical part is that GError is automatically freed when declared with g_autoptr. You can write a function that calls ten different operations, each of which might set an error, and you can check each one and return early if something fails, and the error is automatically freed on all code paths. You never leak the error message string, never double-free it, never forget to free it. This is a massive improvement over traditional C error handling where you either ignore errors or write incredibly tedious cleanup code with goto statements jumping to labels at the end of the function.
The GNOME developers could have switched to C++ or Rust or any modern language, but instead they invested in making C excellent at what C is good at. They added just enough infrastructure to eliminate the common pitfalls without fundamentally changing the language. A C programmer can read GLib code and understand it immediately because it is still just C. The auto macros are syntactic sugar over a compiler attribute, not a new language feature requiring a custom compiler.
This philosophy aligns pretty well with what the F-35 programmers want: the performance and predictability of C with the safety of automatic resource management. No hidden allocations, no virtual dispatch overhead, no exception unwinding cost, no template instantiation bloat. Just deterministic cleanup that happens exactly when you expect it to happen because it is tied to lexical scope, which is something you can see by reading the code.
I found it sort of surprising that the solution to modern C was not a new language or a massive departure from traditional practices. The cleanup attribute has been in GCC since 2003. Reference counting has been around forever. The innovation was putting these pieces together in a coherent system that feels natural to use and composes well.
Sometimes the right tool is not the newest or most fashionable one, but the one that solves your actual problem with the least additional complexity. GLib proves you can have that feature in C, today, with compilers that have been stable for decades, without giving up the simplicity and predictability that makes C valuable in the first place.
If you look around outside Linux world, everyone was going into C++, PC world with OS/2, MS-DOS and Windows, Apple, Epoch (later Symbian), BeOS,.... UNIX was playing with CORBA, OpenInventor,....
Here the original version of the GNU Manifesto,
"Using a language other than C is like using a non-standard feature: it will cause trouble for users. Even if GCC supports the other language, users may find it inconvenient to have to install the compiler for that other language in order to build your program. So please write in C."
The GNU Coding Standard in 1994, http://web.mit.edu/gnu/doc/html/standards_7.html#SEC12
Moving a bit forward to 1998, when GNOME 1.0 was still being made ready,
"Using a language other than C is like using a non-standard feature: it will cause trouble for users. Even if GCC supports the other language, users may find it inconvenient to have to install the compiler for that other language in order to build your program. For example, if you write your program in C++, people will have to install the C++ compiler in order to compile your program. Thus, it is better if you write in C. "
https://www.ime.usp.br/~jose/standards.html#SEC9
Yes, the actual version is a bit more welcoming to programming language variety,
https://www.gnu.org/prep/standards/html_node/Source-Language...
The evidence for this claim was found in testing for the F35 where it was dog fighting a older F16. The results of the test where that the F35 won almost every scenario except one where a lightweight fitted F16 was teleported directed behind a F35 weighed down by heavy missiles and won the fight. This one loss has spawned hundreds of articles about how the F35 is junk that can't dogfight.
In the end the F35 has a lot of fancy features that are not optional for modern operations. The jet has now found enough buyers across the west for economies of scale to kick in and the cost is about ~80 million each which is cheaper than retrofitting stealth and sensors onto other air frames like what you get with the F15-EX
Definitely not a failure.
Criticism is fair however: they did probably extend themselves too far with the helmet technology, and I do have concerns about touch screens in cockpits (a touch screen requires you to take your eyes off of a target to move your hand to the right location, rather than locating a button by touch).
Anyhow, a fair assessment is the program has gone massively over timeline and budget, so in that sense is a failure, however the resulting aircraft is very clearly the best in its class both in absolute capability and value.
Going forward there's broad awareness in the government that the program management mistakes of the F-35 program cannot be repeated. There's a general consensus that 3 decade long development projects just won't be relevant in a world where drone concepts and similar are evolving rapidly on a year by year basis. There's also awareness the government needs to act more as the integrator that owns the project to avoid lock in issues.
From a european perspective, I can tell you that the mood has shifted 180 degrees from "buy American fighters to solidify our ties with the US" to "can't rely on the US for anything which we'll need when the war comes".
Europe is wise and capable enough to develop their own platform.
I’m from one of those countries, and I can assure you a lot of people would now have preferred that we went with an EU competitor instead.
Countries are buying it because it is the only game in town for certain high-value capabilities, not because they necessarily like the implications of there being a single seller of those capabilities. For better or worse, the US has been flying these for 30 years and has 6th generation aircraft in production. Everyone else is still figuring out their first 5th generation offering.
Closing that gap is a tall order. Either way, European countries need these modern capabilities to have a capable deterrent.
How well will the european countries survive with it if the US cuts off access to spare parts, SW maintenance links etc?
Anyway we're all just crossing our fingers that the US is just temporarily insane and will eventually come to its senses. What else can you do.
You know the answer, but I'll say it anyway. There is no comparable alternative today, and there will not be one in the near future.
There have been over 1,200 F-35s built so far, with new ones being built at a rate of about 150 per year. For comparison, that’s nearly as many F-35s built per year as F-22s were built ever, and 1,200 is a large amount for a modern jet fighter. The extremely successful F-15 has seen about that many built since it first entered production over 50 years ago.
That doesn’t mean it must be good, but it’s a strong indicator. Especially since the US isn’t the only customer. Many other countries want it too. Some are shying away from it now, but only for political reasons because the US is no longer seen as a reliable supplier.
In terms of actual capabilities, it’s the best fighter jet out there save for the F-22, which was far more expensive and is no longer being made. It’s relatively cheap, comparable in cost to alternatives like the Gripen or Rafale while being much more capable.
There have been a lot of articles out there about how terrible it is. These fall into a few different categories:
* Reasonable critiques of its high development costs, overruns, and delays, baselessly extrapolated to “it’s bad.”
* Teething problems extrapolated to “it’s terrible” as if these things never get fixed.
* Analyses of outcomes from exercises that misunderstand the purpose and design of exercises. You might see that, say, an F-35 lost against an F-16 in some mock fights. But they’re not going to set up a lot of exercises where the F-35 and F-16 have a realistic engagement. The result of such an exercise would be that the F-16 gets shot out of the sky without ever knowing the F-35 was there. This is uninformative and a waste of time and money. So such a matchup will be done with restrictions that actually make it useful. This might end up in a dogfight, where the F-16 is legitimately superior. This then gets reported as “F-35 worse than F-16,” ignoring the fact that a real situation would have the F-35 victorious long before a dogfight could occur.
* Completely legitimate arguments that fighter jets are last century’s weapons, that drones and missiles are the future, and the F-35 is like the most advanced battleship in 1941: useful, powerful, but rapidly becoming obsolete. This may be true, but if it is, it only means the F-35 wasn’t the right thing to focus on, not that it’s a failure. The aircraft carrier was the decisive weapon of the Pacific war but that didn’t make the Iowa class battleships a failure.
The new 6th generation platforms being rolled out (B-21, F-47, et al) are all pure first-principles drone-warfare native platforms.
Ok, joking aside: If it is considered a failure, what 100B+ military programme has not been considered a failure?
In my totally unqualified opinion, the best cost performance fighter jet in the world is the Saab JAS 39 Gripen. It is very cheap to buy and operate, and has pretty good capabilities. It's a good option for militaries that don't have the infinite money glitch.
I haven’t heard anything particularly bad about the software effort, other than the difficulties they had making the VR/AR helmet work (the component never made it to production afaik).
https://www.nwfdailynews.com/story/news/local/2021/08/02/f-3...
The electrical system performs poorly under short circuit conditions.
https://breakingdefense.com/2024/10/marine-corps-reveals-wha...
They haven't even finished delivering and now have to overhaul the entire fleet due to overheating.
https://nationalsecurityjournal.org/the-f-35-fighters-2-big-...
This program was a complete and total boondoggle. It was entirely the wrong thing to build in peace time. It was a moonshoot for no reason other than to mollify bored generals and greedy congresspeople.
At least before we had zero-cost exceptions. These days, I suspect the HFT crowd is back to counting microseconds or milliseconds as trades are being done smarter, not faster.
The rule is likely speaking to this code.
what leads to better code in terms of understandability & preventing errors
Exceptions (what almost every language does) or Error codes (like Golang)
are there folks here that choose to use error codes and forgo Exceptions completely ?
In C++, which supports both, exceptions are commonly disabled at compile-time for systems code. This is pretty idiomatic, I've never worked on a C++ code base that used exceptions. On the other hand, high-level non-systems C++ code may use exceptions.
Exceptions have very brittle interaction with some types of low-level systems code because unwinding the stack can't be guaranteed to be safe. Trying to make this code robustly exception-safe requires a lot of extra code and has runtime overhead.
Using exceptions in these kinds of software contexts is strictly worse from a safety and maintainability standpoint.
Note that both MISRA and AUTOSAR's guidelines have been combined into a single standard "MISRA C++ 2023" which has been updated for C++17.
Breaking Down the AUTOSAR C++14 Coding Guidelines - https://www.parasoft.com/blog/breaking-down-the-autosar-c14-...
That is of course not to say that exceptions and error codes are the same.
- no exceptions
- no recursion
- no malloc()/free() in the inner-loop
It is "C++", but we also follow the same standards. Static memory allocation, no exceptions, no recursion. We don't use templates. We barely use inheritance. It's more like C with classes.
The C++ was atrocious. Home-made reference counting that was thread-dangerous, but depending on what kind of object the multi-multi-multi diamond inheritance would use, sometimes it would increment, sometimes it wouldn't. Entire objects made out of weird inheritance chains. Even the naming system was crazy; "pencilFactory" wasn't a factory for making pencils, it was anything that was made by the factory for pencils. Inheritance rather than composition was very clearly the model; if some other object had function you needed, you would inherit from that also. Which led to some object inheriting from the same class a half-dozen times in all.
The multi-inheritance system given weird control by objects on creation defining what kind of objects (from the set of all kinds that they actually were) they could be cast to via a special function, but any time someone wanted one that wasn't on that list they'd just cast to it using C++ anyway. You had to cast, because the functions were all deliberately private - to force you to cast. But not how C++ would expect you to cast, oh no!
Crazy, home made containers that were like Win32 opaque objects; you'd just get a void pointer to the object you wanted, and to get the next one pass that void pointer back in. Obviously trying to copy MS COM with IUnknown and other such home made QueryInterface nonsense, in effect creating their own inheritance system on top of C++.
What I really learned is that it's possible to create systems that maintain years of uptime and keep their frame accuracy even with the most atrocious, utterly insane architecture decisions that make it so clear the original architect was thinking in C the whole time and using C++ to build his own terrible implementation of C++, and THAT'S what he wrote it all in.
Gosh, this was a fun walk down memory lane.
Also, serious question: Are they any GUI toolkits that do not use multiple inheritance? Even Java Swing uses multiple inheritance through interfaces. (I guess DotNet does something similar.) Qt has it all over the place.
Actually the only toolkit that I know that sort of copied this style is Nakst's Luigi toolkit (also in C).
Neither really used inheritance and use composition with "message passing" sent to different controls.
it was painful for me to accept that the most elite programmers i have ever encountered were the ones working in high frequency trading, finance, and mass-producers of 'slop' (adtech, etc.)
i still ache to work in embedded fields, in 8kB constrained environment to write perfectly correct code without a cycle wasted, but i know from (others) experience that embedded software tends to have the worst software developers and software development practices of them all.
I feel like that's the way to go since you don't obscure control flow. I have also been considered adding assertions like TigerBeetle does
https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/TI...
Some large commercial software systems use C++ exceptions, though.
Until recently, pretty much all implementations seemed to have a global mutex on the throw path. With higher and higher core counts, the affordable throw rate in a process was getting surprisingly slow. But the lock is gone in GCC/libstdc++ with glibc. Hopefully the other implementations follow, so that we don't end up with yet another error handling scheme for C++.
You can compile with exceptions enabled, use the STL, but strictly enforce no allocations after initialization. It depends on how strict is the spec you are trying to hit.
- C++ Exceptions Reduce Firmware Code Size, ACCU [1]
- C++ Exceptions for Smaller Firmware, CppCon [2]
Provocative talk though, it upends one of the pillars of deeply embedded programming, at least from a size perspective.
So, what exact parts of the STL do you use in your code base? Most be mostly compile time stuff (types, type trait, etc).
I mean .at is great and all, but it's really for the benefit of eliminating undefined behavior and if the program just terminates then you've achieved this. I've seen decoders that just catch the std::out_of_range or even std::exception to handle the remaining bugs in the logic, though.
No algorithms or containers, which to me is probably 90% of what is most heavily used of the STL.
My guess is that you're assuming all user defined types, and maybe even all non-trivial built-in types too, are boxed, meaning they're allocated on the heap when we create them.
That's not the case in C++ (the language in question here) and it's rarely the case in other modern languages because it has terrible performance qualities.
C++ is designed to make this pretty easy.
And if you’re using pooling I think RAII gets significantly trickier to do.
The idea of `become` is to signal "I believe this can be tail recursive" and then the compiler is either going to agree and deliver the optimized machine code, or disagree and your program won't compile, so in neither case have you introduced a stack overflow.
Rust's Drop mechanism throws a small spanner into this, in principle if every function foo makes a Goose, and then in most cases calls foo again, we shouldn't Drop each Goose until the functions return, which is too late, that's now our tail instead of the call. So the `become` feature AIUI will spot this, and Drop that Goose early (or refuse to compile) to support the optimization.
But ... that rewrite can increase the cyclomatic complexity of the code on which they have some hard limits, so perhaps that's why it isn't allowed? And the stack overflow, of course.
Because Rust is allowed (at this sort of distance in time) to reserve new keywords via editions, it's not a problem to invent more, so I generally do prefer new keywords over re-using existing words but I'm sure I'd be interested in reading the pros and cons.
> no recursion
Does this actually mean no recursion or does it just mean to limit stack use? Because processing a tree, for example, is recursive even if you use an array, for example, instead of the stack to keep track of your progress. The real trick is limiting memory consumption, which requires limiting input size.
Also improvements to low level programming, being done since C# 7, a few semantic changes, aren't for removing boilerplate code.
Then since a language is useless without its standard library, there have beem plenty of changes on how to do P/Invoke, COM interop, development of Web applications, and naturally knowing in what release specific features were introduced.
That explains all the delays on the F-35....,
But honestly, with this sort of programming the language distinctions matter less. As the guide shows you restrict yourself to a subset of the language where distinctions between languages aren't as meaningful. Basically everything runs out of statically allocated global variables and arrays. Don't have to worry about fragmentation and garbage collection if there's no allocation at all. Basically remove any source of variability in execution possible.
So really you could do this in any c style language that gives you control over the memory layout.
https://plato.stanford.edu/entries/technology/
https://bpb-us-e2.wpmucdn.com/sites.uci.edu/dist/a/3282/file...