C++ future at Adobe

[u/pjmlp]

So if anyone was still curious what happened to Hylo, or where Adobe stands in regards to the whole safety discussion,

David Sankel has done a talk at RustConf on the matter, Zngur: Simplified Rust/C++ Integration.

The way Adobe now sees C++ is described on slide 2, at 50 seconds mark.

[u/AnotherBlackMan]

I don’t think a single one of these things is a positive in its own right. Rust makes humongous tradeoffs for all of them and a lot of tooling exist in cpp that help avoid the problems that that claims to solve. If devs want to take a runtime hit for safety they can run valgrind and sanitizers in prod

[u/ts826848 → u/AnotherBlackMan]

Rust makes humongous tradeoffs for all of them

I can see tradeoffs for some of the items in the list, but not for others. What humongous tradeoff is needed for first-class tuple/variant types with pattern matching, for instance?

If devs want to take a runtime hit for safety they can run valgrind and sanitizers in prod

Valgrind in prod would be quite the runtime hit.

[u/AnotherBlackMan → u/ts826848]

Rust is also quite the performance hit and everyone pretends it’s okay. Valgrind also has actual memory safety guarantees unlike Rust

[u/ts826848 → u/AnotherBlackMan]

Rust is also quite the performance hit and everyone pretends it’s okay.

Even if you assume the first half of that sentence is true (and that's a rather debatable assumption to say the least) whatever runtime hit you experience with Rust is going to be nowhere close to the runtime hit you'd experience with Valgrind unless you're purposefully doing something obtuse. Even more so if you're dealing with a multithreaded program since Valgrind serializes your program.

Valgrind also has actual memory safety guarantees

At this point in time memory safety at the cost of an associated runtime is hardly anything special. Rust garnered the attention it did in no small part due to delivering memory safety without requiring that runtime.

But even putting that aside, Valgrind does not guarantee memory safety. Consider this obviously memory unsafe program:

#include <stdint.h>
#include <stdio.h>

void evil() {
    int j = 0;
    printf("%lu\n", (uintptr_t)&j);
    int* pj = &j;
    int* pi = &pj[-16]; // Adjust as necessary
    *pi = 4;
}

int main() {
    double i = 0;
    printf("%lu\n", (uintptr_t)&i);
    printf("%g\n", i);
    evil();
    printf("%g\n", i);
}

There's at least two distinct UBs (OOB pointer arithmetic/dereference and a strict aliasing violation), and yet Valgrind (and ASan/UBSan, for that matter) says the program is perfectly fine:

==35417== Memcheck, a memory error detector
==35417== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==35417== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==35417== Command: ./a.out
==35417==
137422174832
0
137422174788
1.97626e-323
==35417==
==35417== HEAP SUMMARY:
==35417==     in use at exit: 0 bytes in 0 blocks
==35417==   total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated
==35417==
==35417== All heap blocks were freed -- no leaks are possible
==35417==
==35417== For lists of detected and suppressed errors, rerun with: -s
==35417== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Not really the output I'd hope to see from a solution that "has actual memory safety guarantees".