The key drawback of steam is that building a steam catapult that can vary its power output well enough to launch both large manned planes and (much more fragile) small drones is rather hard. And people _really_ want to launch drones from carriers.

There is no useful subset of C++ that is a) statically checkable and b) guarantees absence of dangling pointers and null dereferences.

You can build Rust programs and libraries that don't link to the standard library (as you can in C) This is very useful. Rust is pretty much the only language that lets you write complex safe code and still not link to any standard library (since its memory-safe competitors all require GC).

Your last sentence sums it up nicely. If you stick to the safe subset of Rust (which is almost the entire language, and enough to write almost all of a high-performance Web browser in, for example) then you can't trigger undefined behaviors, and references that claim to be non-null are guaranteed to really not be null. Escaping from that subset requires you to write the "unsafe" keyword.

OTOH C++ has nothing like that. It's very very easy in practice for C++ code to accidentally trigger undefined behaviors that can cause anything to happen, and there's no way to tell at compile time whether the code is safe.

int* p = nullptr;
int& p2 = *p; // Hello, null reference

C++ provides no safety guarantees: there's no subset of C++ that can be statically checked to be safe, that's rich enough for C++ programmers to use in practice. As soon as you use pointers or references you have the possibility of the underlying object dying and leaving a dangling reference.

The scenario you describe is pretty much how it worked, with Google and Netflix doing most of the forcing, and Microsoft only helping out a little bit.

It supports consoles as well, via JSMESS. https://archive.org/details/gg...

Don't let the perfect be the enemy of the good. Also, your browser is dynamically recompiling the javascript.

I'd say it's gotten a bit metaphysical at this point. The browser is is running the Javascript inside of a sandbox. This particular javascript file is a cross-compiled version of Dosbox, plus some API wrappers to make Dosbox think that it's running in Linux with SDL2. Dosbox in turn is emulating the CPU and hardware of a typical 386, as well as providing implementations of various DOS facilities.

Browser exploits exist (or at any rate have existed in the past, and may exist in the future; a 0-day may or may not exist at any given time), and most of them use Javascript in some way; this much is true. However, why write a DOS program that tricks Dosbox into tricking Emscripten into running that exploit when you could just run the exploit directly? This might be a great way to show off, but wouldn't be very practical.

Systems submitted for evaluation under TCSEC B2 and better had to be designed for security - layering, TCB minimization, ... were all mandated in addition to support for trusted MAC functionality. When I am designing for "SECURITY" I want to simplify the critical protocols so that they can be described by a state machine and then implement them in silicon.

So you would not have helped save the thousands of Yazidi lives that were saved last August?

FWIW Hobby Lobby always provided, and still provides, at least ten different kinds of contraceptive coverage to its employees.

That MediaMatters page --- like most other material on this subject --- is artfully designed to mislead.

Rust offers manual memory management with automatic safety checking --- the language guarantees you don't leak memory, and you can't access an object after it's freed (assuming you don't opt into unsafe code). No other mainstream language, including Ada, offers that.

Unfortunately, postal voting enables vote-buying.