First, Rust is a handful of people working on a research project.

Electrolysis was "put on hold" because there were better ways to make Firefox a more responsive browser, now. That's projects snappy and supersnappy. See https://wiki.mozilla.org/Performance/Snappy and http://taras.glek.net/ and https://bugzilla.mozilla.org/show_bug.cgi?id=718121 -- the final bug being what I think will make Firefox a great browser again.

I thought people want electrolysis or 64 bit because they have so many tabs open that they run out of address space; no amount of snappiness will fix that problem.

That's probably a valid concern, but it's at best a fringe requirement, I would suspect, compared to the huge number of people who would want a snappier browser. Electrolysis provided some benefits here, because less parts of the browser would run in the same processes and threads.

Unlike the quip about working on Rust above, this is a matter of prioritization of effort. I would not qualify myself as experienced enough to make the decisions to run a project as large and with as many users as Firefox, but I don't think that Mozilla is wrong here.

I and about half of the people I know regularly test the limits of how many tabs they can keep open. The other half can't imagine doing so. I suspect this is a sharp bifurcation of use case that the project leads have found themselves on one side of, not a "fringe requirement."

The Memshrink project is the one geared towards the lowering of memory consumption for Mozilla projects (Firefox, Thunderbird, and Boot2Gecko mainly).

New programming languages have been the downfall of many a great tech company, but not nearly as many as "focusing on your flagship product" to the exclusion of a changing world.

Rust, Typescript, Go, Dart are all awesome. I'd love to see any one of them change the world of development.

Electrolysis also broke compatibility with many Firefox add-ons. The code is not dead, however. It's used in B2G.