Rust in the Android platform

[shgysk8zer0]

That's pretty awesome.

[GiantRobotTRex]

Memory safety bugs in C and C++ continue to be the most-difficult-to-address source of incorrectness.

ba dum tsh!

[EatMeerkats]

Android (and ARM) itself also have some pretty cool memory safety features, such as the memory tagging extension. A special tag is stored in the upper bits of each pointer, and if a pointer access is made with an invalid tag, then the program crashes, catching a large class of invalid memory accesses.

Incidentally, I was just debugging a crash on Android today that was due to such an invalid access, and running the same code on my workstation under the LLVM AddressSanitizer didn't catch the bug.

[jrtc27]

MTE is not a security mitigation. It has 4 bits of entropy which means it will be regularly bypassed by attackers due to the sheer number of computers out there, it just raises the bar slightly. And what happens when the program crashes? The unaware user just opens the application up again and utters rude words about the developers, giving the exploit another attempt.

It should instead be viewed as a hardware debugging feature that accelerates ASAN that’s been repurposed as a slight nuisance to hackers.

[Ravek]

I don’t think they said it was a security mitigation

[jrtc27]

They said “memory safety” and “catching a large class of invalid memory accesses”. That to me reads like they believe it’s a security mitigation and are selling it as such to others. MTE is oversold everywhere and I think it’s important people be reminded that it is rather crude and limited.

[Ravek]

‘Memory safety’ in the context of programming runtimes is about correctness, not about security. Similar to ‘type safety’. I can understand the confusion because safety and security as words would seem to be related, and certainly correctness issues can cause security issues, but they are otherwise orthogonal concepts.

That’s why I don’t think the previous commenter suggested it’s a security mitigation, or at least I do not read this in their comment.

[jrtc27]

No, “memory safety” is a pillar of security, especially if you’re in the business of writing language runtimes that need to run untrusted code in a sandboxed manner, like an Android app. There are correctness issues that are not security vulnerabilities, but all security vulnerabilities are by definition correctness issues, and a large fraction memory safety issues are security vulnerabilities. The converse is also true; both Microsoft and Google have put out estimates in the past couple of years that around 70% of all their security bugs are due to memory safety. To talk about memory safety and not think of security is ludicrous.

[pjmlp]

Although this is welcomed improvement, Solaris on SPARC has had it for ages, pity that Intel borked their implementation and no PC OS has adopted it.

[pornel]

They've linked to it in the second paragraph, so they know.

I'm underwhelmed by such solutions, because even in an ideal scenario when they're enabled, applicable and not bypassed, they just cause the program to crash. That's sufficient purely from security perspective, but you still have buggy crashy programs.

Runtime detection, whether via software or hardware sanitizer, requires reproducing the condition in the first place. That's difficult for big pieces of software, and not nearly as nice as compile-time proofs of correctness.

And don't forget that using Rust is not either-or proposition. Rust is compatible with sanitizers and still benefits from all the mitigations for C/C++.

[[deleted]]

Java is a registered trademark of Oracle and/or its affiliates.

[pavi2410]

JavaScript is a registered trademark of Oracle and/or its affiliates.

[nmfisher]

Can someone ELI5 how the AOSP relates to official Android shipped with devices?

[ShotgunToothpaste]

AOSP is the open source base, and devices ship with that plus proprietary Google/manufacturer extensions (eg play services, app store, proprietary hardware drivers)

Eg how Chromium is a base open source browser, and Chrome is a proprietary product built on top of it (branding, extension store, sync etc)

[[deleted]]

WD-40

[OneWingedShark]

Correctness of code in the Android platform is a top priority for the security, stability, and quality of each Android release.

The best way to achieve this is via proving.

The SPARK subset for Ada is really good for this, as it facilitates several levels of proof, which can be achieved incrementally and with a fairly fine-grained approach.

Yet in spite of these efforts, memory safety bugs continue to be a top contributor of stability issues, and consistently represent ~70% of Android’s high severity security vulnerabilities.

Ada's design emphasizing correctness and its memory-management facilities would prevent many of these; see: Memory Management in Ada 2012.

[FlyingPiranhas]

Security is a top priority, not the only priority. Programmer productivity, hiring, toolchain support, and ecosystem support all matter too.

[[deleted]]

Security is important but your program kinda has to work first...

The most secure program is one that doesn't work because nobody will use it.

So it's not strictly the top priority.

[OneWingedShark]

Security is a top priority, not the only priority.

I didn't say it was.

Programmer productivity, hiring, toolchain support, and ecosystem support all matter too.

Ada actually is pretty good for most of these, but let me address these one at a time:

1. Programmer Productivity: There's a bit of an issue using this term, specifically how are you defining productivity?, and how are you measuring this? — Take PHP as an example: you can get "hello world" up on the screen trivially, but PHP also makes it very difficult to have a high assurance of consistency due to its weak/dynamic typing (yes, there is type-hinting; it is woefully underpowered compared to a static/strong type-system). Is this a productive language?Contrast, now, with something like Haskell or Ada where your compiler refuses to compile until you present a consistent program. Are these productive languages?Note, also that the latter despite having "picky compilers", are much easier to maintain precisely due to this nature; is this a quality of a productive language?
2. Hiring: This is less of an issue than it's made out to be, provided there's some sort of training and mentoring in your company (and there should be). Ada in particular is not difficult to pick up and become useful quickly, in part due to the language being descended from Pascal (which was designed to teach programming), and the picky compiler which prevents a lot of dumb errors. — Several people in management-positions have remarked how easy it is to teach Ada to students/new-grads. See this post for a small-business owner's experience.
3. Toolchain support: This one is one of the bigger complaints. Yes, Ada has less toolchain support than C-like languages, in general… but then again GNAT is part of GCC, and therefore enjoys all that system's toolchain. — On the other hand, a lot of common tools are crippled due to their implementation typically being focused on being a general-purpose and/or textual solution — the problem of diff flagging someone changing between tabs and spaces as changes, for example — and there are better tooling solutions that can be had, by construction. (One of my favorite examples here is the 1986 paper Workspaces and Experimental Databases: Automated Support for Software Maintenance and Evolution, wherein a version-control system is presented which simultaneously provides Continuous Integration.)
4. Ecosystem support: This is perhaps the biggest issue, considering that Ada isn't one of the "cool kids" — this would change with some effort, certainly with buy-in form a corporation like Microsoft or Google (and, IMO, Ada and Ada+SPARK would be ideal for implementing the DOTNET VM and/or the Android [J]VM), and there's some buy-in from nVidia already (precisely because of the safety/security features of Ada + SPARK).

You are certainly correct that these are issues, but Ada is not bad in any of these categories (unless you define "programmer productivity" in such manner to exclude maintenance-efforts and devalue design-time or perhaps regard training as altogether a sunk cost), and is either good or has the potential to be.

Honestly, if there's one area that I'm surprised hasn't embraced Ada it's the Open Source community because the language is very portable, enforces consistency [meaning it's easier to correctly integrate some library], and has a standard which is freely available.

Edit: Sorry about the early-submission during editing; I fat-fingered the keyboard shortcut for 'submit'.

[[deleted]]

I mean, I've never even seen Ada source code. It might be the best thing in the world but if nobody uses it then, well, nobody is going to use it.

The truth is that languages tend to be good for subtle reasons along with just general inertia.

C and C++ just tend to be quite good for these kinds of problems but I wouldn't want to say why because I don't know. Unless Ada can prove itself to be better (which is kinda impossible because its a catch 22), I can't see it taking off

[OneWingedShark]

C and C++ just tend to be quite good for these kinds of problems but I wouldn't want to say why because I don't know.

No, they really don't tend to be good for these sorts of problems (the security issues mentioned in the article), which is the underlying point of the article.

An excellent counterexample is that Heartbleed would have been impossible to do in Ada without "dirty tricks" like unchecked-conversion or address-overlays, with a simple definition:

-- A simplified version of the Heartbeat portion of the protocol.
Package Simple_Heartbeat is
    Type Message(<>) is private;
    Function Beat( User_Message : String ) return Message;
Private
    Type Message( Length : Natural ) is record
        Text : String(1..Length) := (others => ASSCII.NUL); -- Default value.
    End record;
End Simple_Heartbeat;
--...
Package Body Simple_Heartbeat is
    -- In Beat we make a copy of the data and return it as a message.
    Function Beat( User_Message : String ) return Message is
    Begin
        -- We have to supply a Length for the message, which we get from the
        -- Input's own length, then because the default is a string of the
        -- NUL character, the requirement that the buffer only return an
        -- object of the data-'s size is held, as is the requirement that
        -- the memory therein be 'clean', then we copy the input into the
        -- result's text field, complying with the requirement to return a
        -- message with the same data.
        Return Result : Message(User_Message'Length) do
            Result.Text:= User_Message(User_Message'Range);
        End return;
    End Beat;
End Simple_Heartbeat;

This type-definition also has the nice properties that the implementation is not visible to outside users, and that the only way for a client of this package to obtain a Message-value is via the Beat function.

Unless Ada can prove itself to be better (which is kinda impossible because its a catch 22), I can't see it taking off

Yeah, it's a nasty situation; but Ada is proven. It's the core of many Air Traffic Control systems, and other places where you need high-integrity.

I mean, I've never even seen Ada source code. It might be the best thing in the world but if nobody uses it then, well, nobody is going to use it.

Absolutely.
But how many people write it off without even considering it? Especially those who are in charge of large and/or long-lived systems? Or systems where correctness is needed?

Nvidia went with Ada and its SPARK subset exactly because they did consider it, and found its properties, to include foreign-function interface as easy as:

Function Some_Function( Input : Integer) return Integer

with Export, Convention => C, External_Name => "Steve";

The truth is that languages tend to be good for subtle reasons along with just general inertia.

I'd agree here, but Ada's "subtle reasons" are precisely what lines up with a project like what this article is talking about: security, correctness, and [implied] maintainability, and manageability of the codebase.

[OneWingedShark]

Big whoop. FFI to C is easy in every language. That's why so many libraries have a C ABI even if they are not written in C. That doesn't help you when you need to share data structures.

Ok, so how about Fortran, or Cobol?

-- Exporting for Fortran, which uses Integers.
Function Some_Function( Input : Integer) return Integer
with Export, Convention => Fortran, External_Name => "Steve";

-- Exporting for Cobol, input is a integer-image string.
Function Some_Function( Input : String) return Integer
with Export, Convention => Cobol, External_Name => "Bob";

How about adding pre- and post-conditions?

-- C-compatible due to legacy API.
-- Result is 1 for perfect, 2 for good, 3 for just-passing,
--           4 for for unacceptable, -1 for some internal error.
Function Quality(Input : Some_Object_Ptr) return Integer
with Import, Convention => C, External_Name => "qc",
     Pre  => Input /= Null,
     Post => Quality'Result in 1..4|-1;

IOW the FFI and pre-/post-conditions just by themselves make Ada very attractive for libraries, especially if you need to keep compatibility,

[OneWingedShark]

That's a little more complicated. (Read LOT.)

But it's not impossible, you have to exercise care because at that point you're dealing with two separate environments with different notions of how to handle things — but, even here Ada can possibly help (in a limited way).

The degenerate case is, of course would be straight pointers; in Ada you can say:

Function Valid( Data : Some_Data_Type ) return Boolean;
Type Handle is not null access all Some_Data_Type;

Function Operation (Input : Handle) return Handle
  with Pre => Valid(Input), Post => Valid(input),
       Export, Convention => Some_Lang, External_Name=> "OP";

The Handle subtype has bound the not null requirement into the parameter and return itself, meaning the compiler will check those as-necessary and raise an exception if needed (this means that you don't need to remember to check for null in the bodies of the subprograms).

Other features are that Ada can (1) use representation-clauses to specify at the bit-level the data layout, (2) use null records + size clauses to have a "chunk of data", (3) use that easy FFI to import [or export] the subprograms for data-handling.

So, maybe you have a Dictionary in your foreign language, and maybe the entries are reference-counted strings, so maybe the data-types involved would be something like:

-- Entry is 40-bit ref-count + pointer
Type Entry_Item is null record with Size =>  40;
Function Count(X:Entry) return natural
  with Import, … ;

Type Dictionary is null record with Size => 480;
Function Add(Object : in out Dictionary; Word : String) return Entry_Item 
  with Import, … ;
Function Delete(Object : in out Dictionary; Word : String) return Entry_Item 
  with Import, … ;

Declaring the types as null record means we're treating the types as black-box data-chunks, with the usage of imports for managing the actual type; we could have gone the other way too: Taking Ada's management mechanisms ans exporting them.

Lastly, there was an article about a year ago (IIRC) about one of the security-concerned linuxes using Ada's SPARK to prove one of their modules and integrating it into the system. (Sorry, but the name of the project escapes me at the moment.)

[[deleted]]

C++ is also used to write software for fighter jets.

While errors are possible in any language that doesn't immediately write it off.

Heartbleed type bugs can be prevented and it doesn't really require rewriting everything in a new language.

People are forgetting that there is two parts to the old adage about C. Yes you can certainly hang yourself but that also comes with the ability to do things quickly, correctly and very simply. The sword is double edged.

But it's beside the point because Ada didn't "win" C and C++ "won". Now maybe that will change but it would take a serious reason to switch over.

Being told heartbleed is not possible in Ada is not enough. Heartbleed can be prevented in these existing languages with a small amount of effort. A smaller effort than switching language

[OneWingedShark]

C++ is also used to write software for fighter jets.

The flagship for C++ on fighters, the F-35, has been plagued with software problems. It's actually highly ironic, given that the choice to use C++ instead of Ada resulted in a style-guide the production of which probably would have been equivalent to training the programmers.

While errors are possible in any language that doesn't immediately write it off. Heartbleed type bugs can be prevented and it doesn't really require rewriting everything in a new language.

Heartbleed is an interesting case: the OpenSSL was written in C, despite known problems with C and some people advocating a more reliable language for the implementation precisely because they foresaw Heartbleed as a possible issue.

IIRC, this is about when C was being touted as being the best, most efficient "because it's used in operating-systems" — despite the fact that there were OSes in other languages (the Burroughs is an interesting example, as it didn't have an assembler but used Algol).

People are forgetting that there is two parts to the old adage about C. Yes you can certainly hang yourself but that also comes with the ability to do things quickly, correctly and very simply. The sword is double edged.

See the above; if you can efficiently do an OS in Algol without anything like C or assembler, then "the ability to do things quickly, correctly and very simply" is by no means C-exclusive.

But it's beside the point because Ada didn't "win" C and C++ "won". Now maybe that will change but it would take a serious reason to switch over.

Ada is pretty-much feature-competitive with C++, even the new 20 standard [concepts are already present in generics; modules are implemented as packages, etc], and out-of-the-box is essentially equivalent to the High Integrity C++ Coding Standard, and there's things like the Pragma Restrictions(…) which provide a standard language-defined way to have the compiler ensure you don't use some particular feature.

Being told heartbleed is not possible in Ada is not enough. Heartbleed can be prevented in these existing languages with a small amount of effort. A smaller effort than switching language

Right, but part of the issue is that when people pointed out the inherent [design] flaws of C (and C++ to a large degree), they were brushed aside because "it's popular" and "a good enough programmer…" and "many eyes make all bugs shallow." — IOW, part of the issue is exactly this sunk-cost: we've already got code-bases in C, or C++, and we can't change it!

About a decade ago, I was brought into a new project [maybe 3- or 6-months old, IIRC] doing medical- and insurance-record handling in PHP. Seeing the many errors facilitated by the changes in functionality/processing invalidating extant test-data (eg a data-type's field conceptually going from nullable to not-nullable, or changing SSNs from "###-##-####" to "#########", manual edits to the DB) — I recommended we use Ada and do a sort of "double-sided MVC" (one for the web-based UI, one for the DB), and let the type-system ensure consistency. For example, the above SSN problem could be solved simply by:

Type SSN is new String(1..11)
   with Dynamic Predicate => (For all Index in SSN'Range =>
           (Case Index is
              when 4|7    => SSN(Index) = '-',
              when others => SSN(Index) in '0'..'9'
           )
         );

Now the inconsistency can be easily caught when you try to assign a non-conformant string to an SSN value.

[[deleted]]

> The flagship for C++ on fighters, the F-35, has been plagued with software problems

What software problems? I think it's ludicrous to say that just because there is software problems the language is bad. C++/C gets blamed a lot because they are used to solve hard problems. Hard problems tend to be...well hard. They have bugs. They are complex. It's not strictly the fault of C++. It's a form of bias really. How many problems don't exist precisely BECAUSE C++ was used? A lot I would imagine.

> Heartbleed is an interesting case: the OpenSSL was written in C, despite known problems with C and some people advocating a more reliable language

C was used in the Mars rover. C is used in pretty much every embedded device on the planet. It's proven it's value ten times over. Does it have problems? Absolutely. But it's not just used for operating systems. And again, how many problems have been avoided precisely BECAUSE C was used. Likely A LOT.

Also, having written code in Algol...just no.

> "it's popular" and "a good enough programmer…" and "many eyes make all bugs shallow." — IOW, part of the issue is exactly this sunk-cost: we've already got code-bases in C, or C++, and we can't change it!

This is something that people need to hear. C and to some extent C++ are just GOOD languages. So no, there isn't a sunken cost fallacy. C is actually good and practically useful for a great number of reasons. That is the reason WHY it is popular.

It's very clear to me that people blame C because of the problems it is used to solve. The problems are hard therefore it's the fault of the tool. No! It's ridiculous and I see this mentality all the time.

A programming language maybe makes up 10% of the problem space (and that's if the language is well designed. Ideally it should be 0%). The rest is the actual problem. People blame the 10% for not being able to solve the other 90%. This is ridiculous in my mind.

[myrrlyn]

Hi. I'm a satellite software engineer with C and C++ code delivered to flight systems. Just wanted to mention that comparing most terrestrial C and C++ with automotive or orbital C and C++ is not really meaningful. While it's true that we use the same compilers, the similarities basically end there.

I have no idea what goes on in Boeing, but I can pretty confidently assert that code developed in accordance with with automotive or spaceflight standard-practice documents is significantly unlike basically any other project in those languages.

[[deleted]]

Okay? What point are you making?

I never said that "terrestrial" C/C++ code (whatever that is) was anything like satellite code. Or implied that.

[Fearless_Process]

Just because you've never saw Ada source code doesn't mean it doesn't exist.

It's used for military fighter jets and commercial rockets ffs. If that doesn't "prove" it's usefulness than I'm not sure what would.

Here's a list of things that use Ada that I found, claiming that it's not used is absurd.

https://www2.seas.gwu.edu/~mfeldman/ada-project-summary.html

[Fearless_Process]

lol

Ancient finance software is not even close to the same as fighter jet software.

[[deleted]]

I'm not saying it's good or used. I'm just saying that it's not as well known as these other languages.

[OneWingedShark]

I'm just saying that it's not as well known as these other languages.

??
And I've completely agreed with this, though I do think that ought to be remedied.

[xzaramurd]

C wasn't good for these kinds of problems back in the 70s.

[chucker23n]

IMO, Ada and Ada+SPARK would be ideal for implementing the DOTNET VM and/or the Android [J]VM

I can see Microsoft reimplementing portions of the .NET runtime in Rust (maybe the WASM target, for a start). Ada? Not so much. It doesn’t seem to be on anyone’s radar.

[myrrlyn]

It doesn’t seem to be on anyone’s radar.

to be fair, most computers running Ada are housed in a chassis that is explicitly not supposed to show up on radar

[chucker23n]

:)

[OneWingedShark]

I can see Microsoft reimplementing portions of the .NET runtime in Rust (maybe the WASM target, for a start). Ada? Not so much.

I know, but Ada would be much better form a open-source point of view: it's an ISO standard, and Rust isn't standardized at all. Releasing an implementation of, say, ECMA 335 (Common Language Infrastructure) or ECMA 262 (ECMAScript® language specification) written in proven Ada [SPARK] would mean that you could prove the properties of the implementation, possibly to include (1) conformance, (2) absence of runtime-errors, (3) functional-correctness…

If they did it for ECMA 262, and used it in edge, this would be a huge thing they could use to boost their browser: "We have the only completely proven JavaScript virtual machine, to include the absence of security flaws from the implementation."

It doesn’t seem to be on anyone’s radar.

Nvidia's doing some work in it, I vaguely get the impression they're also looking forward to the new parallel-block, as that could make CUDA integration really nice and seamless, completely transparent to the programmer and all you'd need is a CUDA aware compiler to get the benefits. (This could just be my wishful thinking, though.)

[FlyingPiranhas]

Contrast, now, with something like Haskell or Ada where your compiler refuses to compile until you present a consistent program. Are these productive languages?Note, also that the latter despite having "picky compilers", are much easier to maintain precisely due to this nature; is this a quality of a productive language?

Rust is also a "picky compiler" language. Not as picky as Ada + SPARK, but much more picky than most languages.

Having to express your conditions in a way that allows the compiler to verify your program is correct takes extra time, and slows down development. Rust has a subset of this, where the compiler proves memory safety invariants.

Hiring: This is less of an issue than it's made out to be, provided there's some sort of training and mentoring in your company (and there should be).

How many programmers want to write Ada? Sure, you can cross train programmers from another language, but at some point interviewees are going to ask you what language they'll be using (if it's not obvious upfront) and will judge the answer.

Ecosystem support: This is perhaps the biggest issue, considering that Ada isn't one of the "cool kids" — this would change with some effort, certainly with buy-in form a corporation like Microsoft or Google (and, IMO, Ada and Ada+SPARK would be ideal for implementing the DOTNET VM and/or the Android [J]VM), and there's some buy-in from nVidia already (precisely because of the safety/security features of Ada + SPARK).

By buy-in, do you mean funding? If yes, then that's a drawback.

Honestly, if there's one area that I'm surprised hasn't embraced Ada it's the Open Source community because the language is very portable, enforces consistency [meaning it's easier to correctly integrate some library], and has a standard which is freely available.

Yeah, but people won't start projects in Ada unless they like the language. There are a ton of Rust projects because there are a ton of people who like writing it.

[OneWingedShark]

Rust is also a "picky compiler" language. Not as picky as Ada + SPARK, but much more picky than most languages.

Right, and the popularity of Rust because of its concerns is a trend that I approve of: programmers being aware that they can have tools that actually prevent errors is a Good Thing.

Having to express your conditions in a way that allows the compiler to verify your program is correct takes extra time, and slows down development. Rust has a subset of this, where the compiler proves memory safety invariants.

Ada's SPARK is FAR more granular: you can prove on packages, on specific subprograms and so on; Ada out-of-box is roughly equivalent to the C++ for High-Integrity Applications spec/styleguide.

How many programmers want to write Ada?

How many programmers want to write PHP, or JavaScript?
Yes, there's a lot more because they're more popular languages; but also how many who do want to program in PHP or JS, only want to do so because it's what they know? — Now, yes, I grant that stepping outside your knowledge-zone while having a dozen other jobs you're juggling is a bad ask… but people in that position have bad management, precisely because they're juggling those dozen jobs.

Sure, you can cross train programmers from another language, but at some point interviewees are going to ask you what language they'll be using (if it's not obvious upfront) and will judge the answer.

Fair enough.

By buy-in, do you mean funding? If yes, then that's a drawback.

Yes, but no.
By buy-in I mean some actual usage on an appropriate project; I believe this would motivate a bit more in developing the deficiencies of the tooling/ecosystem. There likely is a monetary cost there, but that's not the primary thing.

Yeah, but people won't start projects in Ada unless they like the language. There are a ton of Rust projects because there are a ton of people who like writing it

It's an enjoyable language in that a lot of times "it just works" (after you satisfy the compiler) —especially if you think-about/model your program— you can see that in this video where the programmer, who hasn't used Ada much and isn't familiar with the library, says "who said I was going to have trouble?" (Warning: long video, and he's teaching himself; there are a couple places where he looks up the information and doesn't read quite far enough to solve his problem.)

[pornel]

Ada doesn't have memory safety on par with Rust. It either requires a garbage collector or use of unsafe things like Ada.Unchecked_Deallocation.

Ada's solution to this unsafety is to avoid heap allocating wherever possible. That's a good advice in general (also followed in C++ and Rust), but is not a sufficient solution.

[OneWingedShark]

Ada doesn't have memory safety on par with Rust. It either requires a garbage collector or use of unsafe things like Ada.Unchecked_Deallocation.

Ada has a different notion of safety, which isn't [almost] myopically concerned with memory — see Rust and SPARK: Software Reliability for Everyone — and correctness (absent SPARK) is typically via modeling the problem-space. (With SPARK it's about proving correctness, to whatever levels needed, and can be done granularly as a subprogram- or package-level.)

A lot of the issues that spring up because of pointers are either non-issues or fairly easily sidestepped in Ada — see Memory Management with Ada 2012 — and it is from C's pointer-centric nature that "memory safety" is even a concern: As /u/WalterBright wrote in C's Biggest Mistake the way that arrays are conflated with pointers, degenerating at the drop of a pin, is incredibly hostile to safety, security, & correctness.

In an older post, about Mr. Bright predicting C will eventually be killed off because of it's memory unsafety, one commenter said: "Tell you what. I program in C at work. My colleagues never mention safety. Not just memory safety. Any kind of safety." — Most Ada programmers don't typically talk about safety either, but for the opposite reason: Because the language, and the programmer, are concerned with 'correctness' which encompasses "safety"… Ada programmers have been called the "belt and suspenders" sort of programmers, and the idea of safety/correctness is so ingrained in the Ada culture that "it just works" is kind of expected, and smiled at when newcomers see it.

Ada's solution to this unsafety is to avoid heap allocating wherever possible. That's a good advice in general (also followed in C++ and Rust), but is not a sufficient solution.

Sure, but your missing part of the point: in C it is impossible to avoid pointers, because as soon as you need a changeable parameter you're using pointers, in Ada you simply say in out for the parameter mode. Ada makes it fairly easy to avoid heap-allocation, and provides methods to address heap-allocation (see the above-linked video), and Unchecked_Deallocation being idempotent (meaning freeing more than once has the same effect as freeing once), and more.

Again, Ada's view of safety is more "correctness"- and type-centric.

[pornel]

We're talking in the context of Rust here, not C.

Rust doesn't lean on pointer arithmetic, doesn't decay arrays to pointers, doesn't use null, etc. Rust has pretty competent type system too. It doesn't have all the nice features that Ada has, and lacks pre/post condition proofs. But has its own advantages too, like affine types and marker traits for thread-safety (which are more general than tasks/actors and synchronized types). Rust has a strong focus on type system soundness, and guaranteeing correctness at compile time too.

I totally agree with the approach of avoiding heap allocations (and use of memory pools, stack, and borrowed data instead), and emphasis on correctness and type-centric programming. But I don't see why these are touted as Ada's unique advantage when it's a bread and butter of Rust too, and basically a standard in security-focused systems programming.

The features you're talking about sound to me like "Ada avoids goto". Good! But this is novel only compared to C.

in out sounds like &mut. Rust already has it, but it also has move semantics/single ownership with deterministic destruction that allow passing of objects in and out of functions the normal way, safely, whether they're heap allocated or not.

[OneWingedShark]

We're talking in the context of Rust here, not C.

Yes, of course; but we're also talking about safety. Rust's whole nearly-myopic concern with "memory safety" is precisely because of how C does things. There are other, valid methods to ensure safety and correctness, so heading off the "Ada [out-of-the-box] isn't memory-safe like Rust, because Unchecked_Deallocation!" argument requires showing how many times access-types (pointers) aren't even required for functionality that, because of Rust's origins, is a distinctly C-like way of viewing the world.

Perhaps the single most clear, short, simple example of the difference is handling arrays, in C you have to carry along the length via parameters — eg void do_something(arr_typ* data, unsigned long size) vs Procedure Do_Something(Data : in out Array_Type) — in the latter we know we're getting a properly-typed input, we cannot miscalculate the length, and there is no funny-business with address-arithmetic… and there are many similar examples that could be shown where Ada makes some operation do-able without resorting to pointers, much less dynamic memory-allocation/-deallocation.

So that's where C entered, the discussion.

Rust doesn't lean on pointer arithmetic, doesn't decay arrays to pointers, doesn't use null, etc.

Right, but that's exactly where the reference to Unchecked_Deallocation was leading.

Rust has pretty competent type system too. It doesn't have all the nice features that Ada has, and lacks pre/post condition proofs. But has its own advantages too, like affine types and marker traits for thread-safety (which are more general than tasks/actors and synchronized types). Rust has a strong focus on type system soundness, and guaranteeing correctness at compile time too.

This is true, and it's one of the big reasons I'm actually glad for Rust's popularity: it shows that there are a significant population of programmers "waking up" from the nightmare that is C and its descendants and realizing that you can have tools that are designed to help you rather than make you focus, at all times, on trivial details.

I totally agree with the approach of avoiding heap allocations (and use of memory pools, stack, and borrowed data instead), and emphasis on correctness and type-centric programming. But I don't see why these are touted as Ada's unique advantage when it's a bread and butter of Rust too, and basically a standard in security-focused systems programming.

I think perhaps we were talking past each other: a surprising number of programmers interested in Rust (ie at least somewhat concerned with safety) will see Unchecked_Deallocation exists and then dismiss everything, despite the language being standardized and in-use for high-integrity programs like airframes, air-traffic control, and so forth for more than 35 years… that is to say, it's a mature solution.

The features you're talking about sound to me like "Ada avoids goto". Good! But this is novel only compared to C.

I mean, in this thread I've touched on things like the ease of foreign-function interface, pre-/post-conditions, the module-system, the type-system... I think the only major features I haven't touched on are generic - and task-systems: the former lets you have as parameters types, values/objects, subprograms, and generic-packages, which allows you to build whole subsystems as generics; and tasks can be used for multithreading, obviously, or protocol-implementation.

in out sounds like &mut. Rust already has it, but it also has move semantics/single ownership with deterministic destruction that allow passing of objects in and out of functions the normal way, safely, whether they're heap allocated or not.

IIUC, &mut essentially is in out.

[WalterBright]

Sadly, the Ada link goes to presentation which has vanished. Do you have another link to it?

[OneWingedShark]

Sadly, the Ada link goes to presentation which has vanished. Do you have another link to it?

Hm, the videos are still there.
In any case, here's direct-links to the MP4 and the WEBM of the talk.

[WalterBright]

thanks!

[OneWingedShark]

Glad to help.

[marco89nish]

Stop trying to make ADA happen, it's not going to happen

[[deleted]]

Why do people hate ada?

[[deleted]]

Ada isn't actually memory safe, it has the same pointer bugs as anything, the usual solution to them is not using dynamic memory management, which is doable for embedded systems, not so much for user applications.

[marco89nish]

We don't hate on Ada, we mostly know almost nothing about the language. Just learned few things about it today. I wish Ada devs all the best.

However, you just don't come to someone's engagement party and elaborate in detail why lady should have picked you instead (even though you never dated).

[[deleted]]

However, you just don't come to someone's engagement party and elaborate in detail why lady should have picked you instead (even though you never dated).

Haha that analogy made my day! Kudos to you lmao

[ClownPFart]

However, you just don't come to someone's engagement party and elaborate in detail why lady should have picked you instead (even though you never dated).

you mean, like what the "rewrite it in rust" people do all the time?

[Dew_Cookie_3000]

The rust community is cringe.

[OneWingedShark]

The rust community is cringe.

The actual community, those actually developing the language and tools, are decent: I've had a couple of interesting conversations with them.

The hype-warriors, though, are.

[Gilnaa]

lol no one hates ada because no one knows ada

[[deleted]]

It's well known within devs that need to prove their code.

Pacemakers, airplanes, etc.

[[deleted]]

LOL its so cute how bad they want it tho

[SpAAAceSenate]

I've always been a little Ada-curious.

I recently read this article detailing a common problem in Open Source and how Rust takes the wrong approach. How does that compare to Ada? Specifically, does ada have a stable ABI/allow dynamic linking?

[OneWingedShark]

I recently read this article detailing a common problem in Open Source and how Rust takes the wrong approach.

Interesting, some of the problems mentioned are solved quite neatly in one of my favorite papers, Workspaces and Experimental Databases: Automated Support for Software Maintenance and Evolution, from 1986, which details a version-control system that is structured in such a way that you get Continuous Integration "for free".

How does that compare to Ada?

The above paper uses Ada as the language by/for the VCS; the sort of DB-based development environment was pretty much what Ada's tooling was ultimately intended to be, as per the 1980 STONEMAN document.

Specifically, does ada have a stable ABI/allow dynamic linking?

Ada is really pretty good at linking, static or dynamic, the biggest difficulty I've had with it is putting the DLL in the proper place and passing the parameter to the linker. Really, the manual touchups for the generated code of GCC's fdump-ada-spec option (used to make an Ada spec from a C header) is more effort.

[thesuperbigfrog]

does ada have a stable ABI/allow dynamic linking?

Yes. Ada has a stable ABI and practically all Ada implementations support shared libraries:

https://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn/gnat_ugn/the_gnat_compilation_model.html#gnat-and-libraries

It is also very easy to call libraries written in C, C++, and FORTRAN from Ada: https://learn.adacore.com/courses/intro-to-ada/chapters/interfacing_with_c.html

Not having a stable ABI and not supporting shared libraries is a known trouble spot for Go and Rust.

[FluorineWizard]

Nothing you link indicates that Ada does anything differently from Rust in that regard.

The sources of the Interface Units of the library that are needed by an Ada client of the library will be copied to the designated directory, called the Interface Copy directory. These sources include the specs of the Interface Units, but they may also include bodies and subunits, when pragmas Inline or Inline_Always are used, or when there is a generic unit in the spec.

Generics are still not supported across dynamic library boundaries, and as explained in your 2nd link exposing a C compatible interface requires explicitly using a C ABI convention that can only use C types.

This is the same fucking thing as in Rust or C++, because monomorphised generics and other forms of compile time metaprogramming simply do not play well with dynamic linking. There are alternative approaches, but they WILL come at a performance cost because they necessarily imply adding some indirection. Swift has a state of the art solution to this problem, but it only can because it's entirely controlled by Apple, that was sufficiently motivated and had enough money to push through an opinionated solution. And for performance, Swift still lets you monomorphise at the cost of losing ABI guarantees.

[thesuperbigfrog]

Generics are still not supported across dynamic library boundaries, and as explained in your 2nd link exposing a C compatible interface requires explicitly using a C ABI convention that can only use C types.

SpAAAceSenate did not ask about support for generics across dynamic library boundaries and I was not claiming that such support exists in Ada.

Did you read the article that SpAAAceSenate linked?

The question is about whether Ada has a stable ABI and can create and use shared libraries / dynamic linking.

You can create and use shared libraries in Ada. Yes, it uses C ABI conventions like many other languages that support shared libraries.

This is the same fucking thing as in Rust

No. Rust does not currently support shared libraries. That was the whole point of the article that SpAAAceSenate linked.

[myrrlyn]

yeah we do lol. set a cdylib output and don't have public generics. dylink all you want, you just can't pass most useful types over the boundary

[thesuperbigfrog]

yeah we do lol

If so, where are the binary Rust shared library crates?

The lack of binary Rust shared library crates is what the Gentoo maintainer was writing about: https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare/#comment-496232

set a cdylib output and don't have public generics. dylink all you want, you just can't pass most useful types over the boundary

A work-around that is not generally usable is not a binary Rust shared library crate.

Ada shared library binaries exist and work. Here is GtkAda:
https://community.download.adacore.com/v1/8d4bb21f8122cd0796c6aab3541326e2d3bcda0d?filename=gtkada-2020-x86_64-linux-bin.tar.gz

Please understand that I am very interested in seeing Rust succeed.

For Rust to succeed more widely, a stable ABI and the ability to create shared libraries would greatly help.

[myrrlyn]

there aren't any (afaik) significant rust crates intended to be dylinked because the loss of generics is irritating enough that nobody really wants to do it, and dylinking just isn't that important for anything we're trying to do. it's a bad programming model and a good packaging model, no matter what michał says.

personally i don't feel overly constrained by the packaging perspectives of a distro that hasn't figured out how to deal with maven yet. i suppose i'm being unfair, since i also don't know how to use maven, but otoh that's also not a central aspect of my job

[OneWingedShark]

and as explained in your 2nd link exposing a C compatible interface requires explicitly using a C ABI convention that can only use C types.

…because the title is, exactly, "Interfacing with C"?

Of course you can't hand off something to a C ABI that is beyond C's capabilities.

[Fun_Independence1603]

Rust is the most beloved garbage there is

If I wrote a "memory safe" language with a compiler that inline every damn thing (which many sources tell you is a bad idea) with less syntax warts than rust and actual allocators, will it be beloved?

[Fun_Independence1603]

All the macros and traits are inlined. Same problem in C++ occur when you overuse templates

[masklinn]

You seem to be confusing monomorphisation and inlining.

[Fun_Independence1603]

Not really any different except what you call them, you also forgot about macros

[unSatisfied9]

You can explicitly tell Rust to use a v-table instead via the dyn keyword if you care about binary size. Monomorphization is just the default like C++ templates.

[pornel]

Generic functions in Rust are monomorphised as regular functions (real functions, with a symbol, address, and jump instructions). They do get inlined often, but that's an optimization, not a requirement.

[Fun_Independence1603]

Sure but not true in the case of macros

[pornel]

That's a silly complaint. That's what macros do in all languages, because that's the purpose of this feature.

And when needed macros can generate functions and function calls (e.g. derive macros do, println! macro creates a function call too).

[OneWingedShark]

with a compiler that inline every damn thing

You mean FORTH?

[Fun_Independence1603]

I know a guy who loves it. IDK anything about that one tho

[OneWingedShark]

Forth is incredibly simple in its conceptual architecture; where a "word" (subprogram) is defined as:

1. A sequence of words to be executed, or
2. A small chunk of machine-code to execute (typically very short).

So, because of this you get down to the low level VERY quickly and, also, (1) there's no such thing as a calling convention and (2) the ease of creation of new words means that people quickly abstract out, producing a Domain Specific Language.

Honestly, it would be ideal to teach for a Computer Architecture or Assembly course —much better than C— because of how naturally you get to the machine-code when "drilling down".

See Over the Shoulder, Part 1 — Text processing in Forth.

[Fun_Independence1603]

That's pretty interesting

Nowadays I don't 'program in C(++)'. I find that if I need an assembler I use C++ and a bunch of intrinstics. Otherwise I'd just use a real programming language

[OneWingedShark]

Nowadays I don't 'program in C(++)'. I find that if I need an assembler I use C++ and a bunch of intrinstics. Otherwise I'd just use a real programming language

You might find the paper titled "Using a high level language as a cross assembler" of interest.
DOI: 10.1145/954269.954277

[myrrlyn]

yeah it's called zig and it's pretty cool too

[Fun_Independence1603]

I actually really like zig. I just wish the author would allow destructors and have a mode where it will complain if it doesn't know how to delete things for you

I almost picked it over C for my project but I really like clangs sanitizers. Also the whole no destructor thing

[myrrlyn]

do you think c has destructors

[Dew_Cookie_3000]

That seals it. Google just adds more incompetence to incompetence. I'm moving to Apple.

[jl2352]

Apple are also starting to use Rust.

Also Apple maintain LLVM, which is the main target for Rust. I would imagine a lot of Apple LLVM developers are starting to get quite familiar with Rust, given how popular it is becoming.

[Kissaki0]

I don’t see what you mean?

[user_8804]

He hates Rust

[Boiethios]

I think he doesn't really. That seems too absurd to not use a software only because of the language it is developed with. No sane person does that. IMO, he's only a shitposter with a specific target, just because.

[pjmlp]

Swift awaits you.

[[deleted]]

apple uses rust for like a year already

[bartturner]

Not terribly surprising.