Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ada and SPARK enter the automotive ISO-26262 market with Nvidia

adacore.com

Post reply on HN
Print view View original

91–100 of 113 posts

Re: Ada and SPARK enter the automotive ISO-26262 market with Nvidia

#91

Post by whytevuhuni »

shakna wrote: post #87
whytevuhuni wrote: post #75

Earlier quoted context omitted.

But doesn't this copy the entirety of that slice? That's not what I meant, I was referring to a shared reference, akin to &str in Rust or std::string_view in C++.

It's a slice, with basically the same implementation as std::string_view. [0] If you want a copy, with Unbounded String, you'll need to call To_String on the slice. [0] https://sites.radford.edu/~nokie/classes/320/std_lib_html/ad...

From the documentation you linked, it seems slicing creates a brand new String, which is more like std::string than std::string_view. In other words, it allocates and copies all of the string's characters (although it might allocate on and copy those bytes to the stack).

Also, the Unbounded_String owns its copy of the data, as opposed to referencing other data. The difference with String seems to be just that it can grow. It's still more like std::string than std::string_view.

Note that both std::string and std::string_view are essentially just a pointer and a length (std::string also has a capacity but let's ignore that). The difference is that trying to duplicate a std::string will end up duplicating (deep-copying) the data behind the pointer as well, where as duplicating a std::string_view will not.

Could you help me understand/interpret that link the same way you do, in case I'm missing something?

Re: Ada and SPARK enter the automotive ISO-26262 market with Nvidia

#92

Post by shakna »

whytevuhuni wrote: post #91
shakna wrote: post #87

Earlier quoted context omitted.

It's a slice, with basically the same implementation as std::string_view. [0] If you want a copy, with Unbounded String, you'll need to call To_String on the slice. [0] https://sites.radford.edu/~nokie/classes/320/std_lib_html/ad...

From the documentation you linked, it seems slicing creates a brand new String, which is more like std::string than std::string_view. In other words, it allocates and copies all of the string's characters (although it might allocate on and copy those bytes to the stack). Also, the Unbounded_String owns its copy of the data, as opposed to referencing other data. The difference with String seems to be just that it can…

Allocating a new String, requires... "new String". You issue the "new" command, or the source does.

But what Unbounded does is... "U.Reference (U.First .. U.Last)". It returns a reference. It's not duplicating, because that would defeat the point of its entire existence. Its the buffer, containing one or more string objects, and you're just slicing a reference out of it - because that's the point.

If you want a String, you need to allocate one.

    function Slice
      (Source : in Unbounded_String;
       Low    : in Positive;
       High   : in Natural)
       return   String;
For this - there is no `out` marked. What you're grabbing is part of Unbounded, and the compiler won't let you deallocate it. Because it's owned, as a reference, to the Unbounded String.

For example, here's the actual GNAT source of the function [1]:

   function Slice
     (Source : Unbounded_String;
      Low    : Positive;
      High   : Natural) return String
   is
   begin
      --  Note: test of High > Length is in accordance with AI95-00128

      if Low - 1 > Source.Last or else High > Source.Last then
         raise Index_Error;
      else
         return Source.Reference (Low .. High);
      end if;
   end Slice;
A pre-existing reference is returned. There is no allocation that happens whatsoever.

[1] https://github.com/gcc-mirror/gcc/blob/master/gcc/ada/libgna...

Re: Ada and SPARK enter the automotive ISO-26262 market with Nvidia

#93

Post by zppln »

bb88 wrote: post #89
firesteelrain wrote: post #71

Earlier quoted context omitted.

I personally know of teams using modern tooling and expansive cloud based CI/CD with safety critical systems and we are talking hundreds of developers. This is in C++ with MISRA standards and DO-178 too.

I don't think it's fair to say C++ is safe and reliable as is. The only way it could be made safe is with a restricted version of C++. I'm reminded by mozilla's sign "You must be this tall to write threaded code." [1] How much do you restrict your language and libraries to make it safe? Like custom templates? How do you define ownership of objects and lifetimes -- or just malloc everything all at once? [1] https://bh…

We use C++ at my shop for Level A and of course we very much restrict it. But the restrictions are more due to reducing the scope of what you need to show for your compiler.

> or just malloc everything all at once?

Yes! But here's the thing: this isn't done due to the footguns associated with memory management, it is done because you want as little dynamic behavior as possible. For Level A software you need to show that your software has both bounded execution time and memory usage, and be robust against all inputs. Achieving that is so much easier without dynamic memory management.

Also, another thing to keep in mind is that DO-178 has you show that your software requirements are traceable to system requirements, your software design to your software requirements, your source code to your software design and your object code to your source code. But testing should be requirements based. So if your compiler inserts a bounds check now you have object code not traceable to source code and for which you won't have coverage because your requirement mention it. But what if you mention it in your requirements? Well, then you'd have to implement it manually in source code to uphold traceability anyway...

I will caveat the above by saying that other players may interpret things differently or have found ways to do things more cleverly.

Re: Ada and SPARK enter the automotive ISO-26262 market with Nvidia

#94

Post by FirmwareBurner »

cmrdporcupine wrote: post #69
FirmwareBurner wrote: post #68

Earlier quoted context omitted.

And you think enthusiasts of niche languages like Ada, will be more skilled and less elitist than C++ devs?

I think I'm tired, after 20+ years of being around the language, of hearing C++ developers tell people "they're holding it wrong" every time something blows up. Blaming the victim. C++ is a language seemingly designed with footguns built in on purpose. Even worse it has a community full of elitism and obscurantism. Rust isn't perfect (I have my gripes), but it has the right idea with ownership management at the stati…

>Even worse it has a community full of elitism and obscurantism.

Sorry but I' can't entertain such broad generalizations of people. That's like hearing a woman saying all men are trash.

I agree with comments on the technicality of the language but if you start attacking people, I'm out.

Re: Ada and SPARK enter the automotive ISO-26262 market with Nvidia

#95

Post by FirmwareBurner »

seabird wrote: post #74
FirmwareBurner wrote: post #59

Earlier quoted context omitted.

You mean the Patriot that ended up getting 28 people killed due to a SW bug?[1] That Patriot? Let me repeat myself again, Ada won't save you from human bugs. If you hire bad programmers or have bad dev and test practices, there's no magic programming language that will save you from your calculation and logic mistakes. You can code in raw machine code like you're 1960's NASA, and still have less bugs than a clueless…

The Patriot failures were the result of floating point error. Ada provides facilities specifically to deal with this, while you're left rolling your own in C/C++. Of course Ada won't save you from human bugs, but it's silly to say that you're no better off with a language giving you everything it can to avoid them than one that is a notorious fuckup dispenser.

1. How is Ada better at floating point than C++?

2. In mission critical systems we always used fixed point fractional numbers in C as a representation of floats, to avoid floating point issues, so any issues of the language are moot.

Re: Ada and SPARK enter the automotive ISO-26262 market with Nvidia

#96

Post by FirmwareBurner »

seabird wrote: post #73
FirmwareBurner wrote: post #46

Earlier quoted context omitted.

>Everything I've heard about it was that it was pressure from contractors because they didn't like training or finding Ada talent. Do you think the auto industry will have a easier time finding Ada talent at their pay rates? Or that talent will want to specialize into Ada just to pigeonhole themselves into the Automotive jobs market?

I'm near Detroit which has a huge amount of auto industry, and engineering pay is good across pretty much all disciplines. It'll pay for a happy life and then some as long as relentless title climbing and job hopping isn't your definition of happiness. Ada is not some exotic thing that requites SF comp. If it's such a major adjustment coming from C/C++ that it's actually causing you trouble, you have other problems.…

>I'm near Detroit which has a huge amount of auto industry, and engineering pay is good across pretty much all disciplines.

I dunno about Detroit since I don't live there, but in Europe the auto industry is on a major downturn with cost cutting, layoffs and hiring freezes. Good luck getting hired anywhere now if you're laid off from the Auto industry and your specialty is some niche stuff only used in the auto industry. Also, IIRC, the company I worked for recently laid off 35% staff at their Auburn Hills office overnight so I doubt the situation around Detroit is as rosy as you make it seem.

> If it's such a major adjustment coming from C/C++ that it's actually causing you trouble, you have other problems.

Like I said, there should be no problem for a (skilled) programmer to adjust from C++ to Ada or vice versa, the problem is convincing HR to hire you on that premise. Ask me how I know (see my username).

Gone are the days of the SW generalists programmer, who would be hired with the expectation to learn on the job the new language used at that job, companies now are only looking for people with X on-the-job YoE on that programming language or framework, not self taught people coming from other programing languages.

This is not something you can control, it's the hiring market that's broken, so you can only adapt to it by not pigeonholing yourself in things that might be a career dead-end.

>It's comical bringing up the automotive industry considering that its responsible for AUTOSAR

AUTOSAR did what it was supposed to do: be a vendor lock in program for German bureaucratic companies and job security program for workers in that industry. That's what Germany and German companies do best: create massive amounts of bureaucracy requirements as a moat for an industry they have a foothold in, then sell you the solution. Why do you think SAP is also German?

Re: Ada and SPARK enter the automotive ISO-26262 market with Nvidia

#97

Post by micronian2 »

whytevuhuni wrote: post #34
pjmlp wrote: post #29

Earlier quoted context omitted.

5 years ago NVidia did not consider Rust mature enough for their use cases. This is the original announcement from 2020, "SPARK/Ada Journey to Adoption" https://youtu.be/DZSSyWlsb28?si=vh4gO-LT2N3Skaql Also we are now on Ada 202x already, quite different from Ada83, that some Rust folks keep comparing their favourite language with. You get all the niceties of a language more in line with Object Pascal productivity, f…

I don't know Ada / SPARK, and I've been trying to figure this out. Based on the hallucinations I got from ChatGPT, it seems Ada itself is nowhere near as powerful as Rust in safety, while Ada with SPARK disallows some things I was considering to be quite basic, such as shared aliasing of data. For example, it seems it's not possible to get a sub-string slice reference to an original unbounded string. In rust, a &str…

A few days ago, I had ChatGPT compare Rust and Ada. It tended to penalize Ada for its runtime checks and access values (aka pointers). However, ChatGPT didn't account for the fact that many of Ada's runtime checks would need to be manually implemented by developers in other languages. An Ada compiler, can often optimizes these checks away, knowing where they're genuinely needed and where they can be removed. This often explains why speed comparisons between C and Ada code can be misleading, as they rarely factor in the extra manual effort required to make C code equivalently robust with necessary safety checks.

Regarding access values, I listed out some of Ada's various restrictions. Its scope rules prevent referencing objects at deeper levels, objects must be explicitly marked aliased to create an access value to them, and there's far less need for access values (for instance, no pointers are needed to pass parameters by reference). Additionally, Ada offers the ability to dynamically size some objects and reclaim their memory without explicit memory allocation.

After I highlighted these details, ChatGPT admitted it had unfairly evaluated Ada, concluding it's a very safe and robust language, albeit using different techniques than Rust.

Re: Ada and SPARK enter the automotive ISO-26262 market with Nvidia

#98

Post by FirmwareBurner »

cjbgkagh wrote: post #22
cjbgkagh wrote: post #15

Earlier quoted context omitted.

I think IBM Rational Ada was a thing back then. Never used it but heard stories about it.

I should add, what I was told is that they were amazing, especially the pre-IBM Rational stuff. Rational was acquired by IBM in 2003. I was working on tech adjacent to the JSF (F35). I was told by a guy working on the JSF that the extra bugs from C++ would mean better job security and he was 100% right. It’s pretty much that conversation that triggered my move into high tech and away from military. I think it’s a sha…

>It’s pretty much that conversation that triggered my move into high tech and away from military.

Could you elaborate on this please? What is "high tech" here?

Re: Ada and SPARK enter the automotive ISO-26262 market with Nvidia

#99

Post by FirmwareBurner »

anthk wrote: post #70
FirmwareBurner wrote: post #59

Earlier quoted context omitted.

You mean the Patriot that ended up getting 28 people killed due to a SW bug?[1] That Patriot? Let me repeat myself again, Ada won't save you from human bugs. If you hire bad programmers or have bad dev and test practices, there's no magic programming language that will save you from your calculation and logic mistakes. You can code in raw machine code like you're 1960's NASA, and still have less bugs than a clueless…

It will help a lot still. But as I said, Forth it's better than raw ASM. On integers casted into floats, a Forth programmer would use a fixed point in a much saner way, they had experience for decades on it.

C programmers have been using fixed point integer math instead of floats for decades. It's a solved engineering problem in safety critical systems. It's only a problem for clueless devs who look for reason to shit on C and think the magic lies in the right programming language, not in having the right knowledge.

Re: Ada and SPARK enter the automotive ISO-26262 market with Nvidia

#100

Post by cjbgkagh »

FirmwareBurner wrote: post #98
cjbgkagh wrote: post #22

Earlier quoted context omitted.

I should add, what I was told is that they were amazing, especially the pre-IBM Rational stuff. Rational was acquired by IBM in 2003. I was working on tech adjacent to the JSF (F35). I was told by a guy working on the JSF that the extra bugs from C++ would mean better job security and he was 100% right. It’s pretty much that conversation that triggered my move into high tech and away from military. I think it’s a sha…

>It’s pretty much that conversation that triggered my move into high tech and away from military. Could you elaborate on this please? What is "high tech" here?

High tech is cutting edge tech, I.e. applied research at big tech.
Post reply on HN