I'd up-vote you, but I've already commented elsewhere. This comment, and the XKCD cartoon, are exactly correct, as far as I can tell.

The tightly-constrained "nano-VM" model of module isolation has exactly the same restrictions as CSP-based parallelism, or the Actor model, compared to threads and shared data, and will very probably be about as successful. (I.e., there will be successful niches, but most code will continue to play fast-and-loose and be a security problem.)

It will have to be _very_ sophisticated, because (a) WASM execution environment prevents most of the existing styles of exploit by design, and (b) the _point_ of the exercise is to sandbox even sub-modules of programs into spaces so small that they can't do any harm. Capbility-based system access, assuming they can get that to work. Similar levels of sandboxing to running apps in Docker images, but at much finer grain and much lower overhead.

Quite a few of the (security relevant) bugs in those "memory safe" languages are actually memory-unsafety bugs in underlying libraries (OS, graphics and codecs). And the fact that almost no-one does rigorous input parameter checking.

Modern garbage collection, as found in ART, Go and V8 is very impressive. Threaded and time-bound collection sprints mean that there's never a "stop the world" collection as used to happen in old Lisps and similar systems. So you almost certainly could get away with using that sort of language for most user-interface and server-side code. There is still a cost though: on average it costs about twice the memory footprint of a non-garbage-collected system, and it's very difficult (mostly due to construction-heavy idiomatic language use) to make hard-real-time systems with it. That's certainly not everything, but there are fields where it can matter. Deeply embedded systems are typically tight on memory (and "IoT" is getting bigger) and multimedia codecs need to run on small-memory systems glitch-free for long stretches of time. Since both codecs and IoT devices are typically "internet facing" it makes sense to make it as hard as possible to write buggy code.
I'm not a fan of C++ myself: too much inscrutable magic. C still works though, and with good coding practices and tests (including fuzzing) the bugs still left tend to be design and specification problems, rather than memory safety.

If you're using passwords with ssh, then you're doing it wrong.

Also, not every new thing has to benefit everyone. Companies introduce new things that are no help to me all the time...

Except that Apple Mail.app, while not flawless by any stretch, is a really great mail client.
Android has some good ones too: K9 is only missing cross-account message store/move and it'd be as good as mail.app.
I've tried Microsoft Mail a few times and decided that it just doesn't work (for me.) Outlook works, for small values of work, but is the sort of obliquely painful experience that you'd expect of an unloved "legacy" technology.

Microsoft wants you to transition to MS Teams. It also doesn't work, but it's much shinier than their mail offerings and has the advantage of locking you and your content into their infrastructure.

This isn't even remotely true. Sure, housing is vastly more expensive everywhere in the world at the moment (not just the US), but that is mostly the effect of extremely low interest rates and the common case of two adults in employment to pay the mortgages. All else follows according to supply and demand. Look at the fraction of household income paid on mortgages, and that will be nearly the same as it was fifty years ago. It's what people will stand.

The issue isn't that web sites are doing real-time analytics. It's that they've all out-sourced the process to a handful of third party companies. No one cares that the information they've provided to the company they are interacting with over SSL gets seen by that company: of course it does. What they care about is that this stream of data is parceled up and sent (not necessarily securely, according to the article) to some company you've never heard of, and have no business relationship with.

ACK Basic on a TRS-80. Wasn't very long before that was swept away by Z80 assembly language though. I remember magazines of the day containing articles that included listings (can't remember if it was asm or hex) that I would diligently enter. And then debug. I don't think that reading hex opcodes is something that the youft still get to experience, more's the pity.

Javascript is OK. It's a bit like lisp in sheep's clothing, and that goes all the way back to the beginning.

Highschool was only more Basic I think. University started with a local dialect of Object-Pascal and a little Fortran. C came later.

I don't think that there is enough emphasis on assembly language these days. By by the time I had graduated I had used assembly for Z-80 and 8085, 68000, NS16032, VAX, PDP-11. Maybe early SPARC. Perhaps TI DSP32010. One machine that I built myself for a project. Probably 8086 and 80286. ARMv2.

Lisp and its decendents (everything that uses garbage collection) are OK for theory and explorartory programming. Practice is important though. You have to understand what things cost, and why.

a) 64 bit processors can do 64-bit arithmetic in a single cycle.
b) The 64-bit processors in question have more named registers (fewer stack spills), and a significantly more efficient function calling convention (ABI)
c) 64-bit ABI doesn't touch the old x87 register set, which is another net performance win. (Not that VS2015 will use this much.)
Ergo: most of the time they are faster.
The only way to make a 64-bit program slower than a 32-bit one is to have enough pointer-chasing and associated irregular dynamic data that the change in pointer size materially affects the data cache miss rate. Certainly there is some code like that: VS2015 might even be an example.

How fast do you need your IDE to be though, and how much is performance really the instruction set's fault? Versions of Visual Studio have been produced that run in everything from .NET to JavaScript, and that's fair because most of the cycles are going to be consumed in GUI and file stacks anyway. Native code performance is hardly going to be the issue.

The issue is almost certainly that LLP64 is a dumb idea, and the code base will have lots and lots of pieces of historical code that assume that you can manipulate pointers with long arithmetic, and all of those are going to have to be found and fixed by hand, often involving real understanding and design decisions.

Only people who don't actually use processors at the instruction set level are uncertain about whether or not a processor is "32 bit" or "64 bit". If you look at the architecture, it is usually very easily apparent. Not always, but usually.

Does it take more than one instruction to shift a 64-bit value? It probably isn't a 64-bit processor.

This.

With a slight caveat that in that last one percent is probably the use case of DOM inside a browser page looks sufficiently like an irreducible thicket of tiny objects, and still wants all the speed that it can get, which is why Google is pushing x32 for Chrome plugins. Maybe it helps a bit for Javascript compilation too.

At least if your x32 is (a) sandboxed in a browser process and (b) generated by a JIT then the library duplication badness should be negligible and the result mostly invisible to the user.

For my own code, I wouldn't touch it with a bargepole. Storing pointers in memory? Madness...

HTML5/WebGL/etc not doing it for you? They say it's all the rage.

Personally, I prefer X11R5 or DisplayPostscript, but these wheels have to be re-invented every so often, in case "round" stops being the right answer...

You've seen a lot of applications that work like that?

Sure it might be feasible. Might even happen, one day. Isn't the case now though, and I think that you're radically under-estimating the amount of re-work (basically re-design) that would be required to have fully-useful two-mode applications.

There are some, I suppose. Apple's got versions of Pages and their other iWork applications that run in desktop and tablet mode. So they're probably ahead of the game as far as useful convergence is concerned.

Old school apps, the programs we used to run on PCs automatically had access to everything that the user who ran it had access to. And that didn't seem to be a problem. People would report "spyware" and programs that did badness would be shunned.

It seems that the fine grain permission protections of the mobile platforms have the inverse effect to the seeming intention: permission explicitly granted is exploited ruthlessly. And that seems to still be OK.