Hacker News Reader

Comment by max76 | Hacker News Reader

As an industry we should deprecate all unmanaged code. We've proven time and time again that even very professional and highly scrutinized unmanaged code can have critical data safety faults.

Yes, I understand this includes Linux, Windows, BSD, Darwin (iOS, MacOS, watchOS, etc), The Android Runtime, and lots of critical software that runs on top of those systems.

We have the tools to write very efficient managed code. Critical security flaws involving unauthorized access to data will continue to appear until we make the transition. The cost of these security flaws is likely to become more expensive than the cost of replacing the existing software. To make matters worse we are continuing to write more unmanaged code everyday.

View on HN

I would much rather switch to a compiler-restricted memory safe unmanaged alternative such as Rust, before I throw out performance for safety completely.

A lot of applications, such as video games, don't require the type of security others do, but require performance to a much higher degree.

Rust is a good middle-ground, since it does have some compile-time issues at the moment still which are getting better. But it is incredibly stingy about anything unsafe. Even unsafe blocks of code are borrow-checked.

Considering how slowly things run these days on any OS, and OS's specifically having performance issues, I doubt the user experience will benefit from a completely managed OS either, but I'm no expert.

I'd agree that Rust would be a great alternative to C/C++ in performance critical applications.

Video games often have direct or indirect access to personal and credit card data. To double the issue of memory safety some popular video games encourage user generated content to be consumed in game. While less critical than an http server I still think it would benefit. Unity runs game logic in managed c#. Opengl is still wirrten in C.

> The cost of these security flaws is likely to become more expensive than the cost of replacing the existing software.

I think that you massively under-estimate the cost of rewriting all that code. Yes, the security flaws are expensive. Rewriting the code would be, I'd guess, at least one order of magnitude more expensive.

If we start getting more recalls and lawsuits due to CVEs, things will change.

The cost of these security flaws is likely to become more expensive than the cost of replacing the existing software.

Expensive to whom? When was Microsoft or RedHat or Oracle or the FreeBSD foundation last fined or sued because of a security flaw - an unmanaged memory one, specifically?

When was a random company or developer fined or sued for same?

Shutting down servers or stealing credit card info certainly has a cost

The bandwidth costs for Globalsign incurred for revoking SSL certificates in response to Heartbleed was estimated to $400K in a Cloudflare blob post [0] and eWeek estimated the total cost of Heartbleed to be $500M [1], although admittedly this price tag is an educated guess.

You're question is expensive to whom. The answer is the expenses are spread across the entire industry. Every time a software author needs to write a patch the bigger cumulative expense is to all of their customers that need to apply the patch.

[0] https://blog.cloudflare.com/the-hard-costs-of-heartbleed/ [1] https://www.eweek.com/security/heartbleed-ssl-flaw-s-true-co...

Agreed on principle but not sure it can be bootstrapped.

What would you write, say, v8 in? Rust doesn't have any provisions against type confusion, JIT bugs, etc, and v8 seems way too complex for a formal verification.

Does C/C++ have any provisions against type punning or JIT bugs? The fact that you have to use unsafe code for a lot of things in a JIT doesn't change the basic reality that Rust is safe by default, whereas C/C++ cannot be made memory-safe practically, except for small programs like seL4.

That's extremely easy to answer.

The answer is you'd write an interpreter for JavaScript in Java, use a partial evaluation framework also written in Java to convert it to a JIT compiler, and then run it on a multi-purpose optimising polyglot virtual machine that's also written in Java. Such a thing would be fully bootstrapped and fully managed.

And usefully, it exists already. That's what happens if you run JavaScript on SubstrateVM using TruffleJS and Graal:

https://www.graalvm.org/

The closest thing you find to unmanaged code is parts of the garbage collector, where "SystemJava" is used, a dialect that gives access to pointer arithmetic. But everything else including the JIT compiler itself is fully managed.

If I understand what you are describing this is how PyPy works.

Reply on news.ycombinator.com