Hacker News Reader

Comment by pcwalton | Hacker News Reader

> Both of those issues would exist regardless of the language chosen--D, Erlang, Java, Python, Rust, w'ever.

Not necessarily. If the language provides a way to ensure memory management of DOM objects is correct across language boundaries, it would provide an effective defense against these issues.

Safe memory management across a combination of managed and unmanaged code is a tough problem, and Rust (and perhaps Swift?) are the only languages I know of that have any attempts to solve it. It requires both language and library support. There are several competing solutions in the community: luster [1], shifgrethor [2], and josephine [3] come to mind. All of them allow this kind of code to be implemented safely.

[1]: https://github.com/kyren/luster

[2]: https://github.com/withoutboats/shifgrethor

[3]: https://github.com/asajeffrey/josephine

View on HN

GraalVM also has a way to do this - the 'unmanaged' C/C++ is upgraded to be automatically memory managed on the fly by compiling pointers into (gc'd reference, integer field offset) and then redirecting allocations to GCd heaps. There's more to it than that of course, but it means traditional C/C++ using new/delete and GCd languages can interop and coexist in the same process and heaps, and memory management errors in the unmanaged side are caught (cause VM termination).

If you want GC there are available GCs for C++.

You are forgeting SOM and COM/UWP.

Actually something where Rust still fails short of being an alternative to Delphi/C++ on Windows, regarding tooling and productivity.

Looking forward to the HoloLens collaboration or Microsoft now pushing for Rust on their security guidelines will actually improve that experience.

From the rust Oxidization page (hip name):

- "Crossing the C++/Rust boundary can be difficult."

- "For components that are relatively standalone, with small and simple APIs."

- "This minimizes the C++/Rust boundary layer issues."

Not only does Rust not have a good JavaScript integration story, it doesn't have a good C++ integration story.

Most of Firefox is still (8 years later) not written in Rust.

Chrome with C++ has a waaaaay better safety record than Firefox. Guess what? The C++ in Chrome tries to ensure memory safety for JS.

The C++ Chrome tooling does a better job of memory safety as a whole system than Firefox.

> Most of Firefox is still (8 years later) not written in Rust.

<nit>In part because 1.0 release of Rust popped up in 2015, not 2011.</nit>

You make a lot of points about Rust and mention Firefox in your conclusion, right after saying Firefox is by and large not Rust. I think your logical argument would be better served by using clear language and a single subject. After you have those two things you can think about coming up with examples.

None of this is responsive to my points.

Rust is bad at managing DOM memory in Firefox.

Reply on news.ycombinator.com