Hacker News Reader

Comment by BulgarianIdiot | Hacker News Reader

Absolutely. Piling on tech debt forever is like trying to eat endlessly and never to go the toilet, pardon the analogy. Legacy needs to be dealt with constantly and relentlessly. With a suitable overlap window for transition (but we've had enough x86-32 compatibility window already).

View on HN

If I'm reading the pdf correctly it proposes dropping 32-bit ring 0 (OS) but not 32-bit ring 3 (userspace), so most end-users are unlikely to notice much change even if they do have 32-bit legacy apps kicking around. I think 32-bit VMs would no longer be supported, though.

Shouldn't VMs run in ring 3, anyway?

I don't really kmow x86 VM architecture well enough to say -- I was guessing by analogy to Arm. But a lot of the complexity they want to get rid of is system-level stuff so if you leave it in for VMs you lose a lot of the point. It might be emulatable by the hypervisor, I guess.

You're kind of forced to. I have tried to do userspace emulation using a vmm in amd64, but it's a bit hard. It is possible to handle exceptions in userspace, but you can't do page table modifications because many important instructions are ring0 only. That said, if you simplify a bit and handle paging in the host-side VMM it still works fine. You still have to do system call emulation by trapping in the SYSCALL handler. SYSCALL forces you into kernel mode, unfortunately.

So bottom line is that no matter which way you try to do the userspace emulation, some parts are going to be ring0, and thus the answer to your question is indeed yes.

The VM runs in the host's ring 3, but the VM has virtual rings of its own. Removal of 32-bit ring 0 support including in VM guest mode could make it infeasible to run 32-bit OSes in VMs with reasonable performance on the new chips. The VM hypervisor software would have to switch to emulation QEMU-style whenever the guest was running it's kernel, or revive the old scanning and patching tricks from the early days of VMware before x86 had any hardware VM support.

IMHO a similar point could be made about the C++ language spec, sadly.

Same point can be made about anything. Never breaking BC is easier, and more comfortable, but in the end it's slow and inevitable death.

If C++ would have cleaned up legacy, Rust wouldn't need to exist for ex.

Java has long had a policy of never breaking BC, but few years ago they started marking packages deprecated for removal. They're very slow and systematic about it, as they should be, but the point is, eventually those packages will be removed. And that's good. It means Java has a future.

Rust is still in the noise vs the amount of market share that C++ has. That said I love it as a language but it's hardly "taking over", I have tried to push it at my company a bit for command line utilities.

There are similar efforts to revamp C++ or replace it with another language, too.

Rust is a famous example; there's also Carbon[1] and cppfront[2].

Even so, this may be a controversial opinion, but with C++20, it has become fairly straightforward to program relatively safely and avoid some old footguns.

[1]: https://github.com/carbon-language/carbon-lang

[2]: https://github.com/hsutter/cppfront

I use "modern C++" (a subset of it that suits my goals) and do not really have any real problems during last 3 years. My backend C++ application servers are running along just fine.

I have the same experience. All the tools at my disposal including mutrace for measuring contention, I just feel like C++ is a solid language. Sure, I wish there was more compile-time stuff, like the ability to force a function argument to be compile-time, but in my experience, modern compilers often have surprisingly deep reach, and you can expect much of your code to just be compiled away if written a certain way.

I recently wrote a server-client framework from scratch and used protobuf for messaging. The server is heavily multi-threaded with a lot of complex asynchronous rules, and there are no issues. If anything, I would hope for more concurrency primitives, as the C++ standard library is very high quality, and I would like concurrent hash maps and such.

Yup, it's absolutely true, navigating to the "good parts" is a nightmare

Just don't use "legacy parts" and be happy. Backwards compatibility is a great asset. Alternatively do something like Google's Carbon. Seems like a great product. Just do not call it C++. If it gets accepted by wider community you would know you are on the right path.

> Just don't use "legacy parts" and be happy.

Maybe that works for some new codebases.

When you need to integrate with other code, you can't necessarily understand the code semantics without knowing a lot more of the spec.

Also, I challenge any normal programmer to remember all of the "good" C++ rules regarding overload resolution in an arbitrary context.

>"When you need to integrate with other code, you can't necessarily understand the code semantics without knowing a lot more of the spec."

I mostly design and create new products but on some occasions I've had situations like this. There was not a single time that quick Google search and now ChatGPT did not shed the light.

>"Also, I challenge any normal programmer to remember all of the "good" C++ rules regarding overload resolution in an arbitrary context."

Knowing / remembering every nook and cranny does not make for a good programmer (except language experts who write standard libraries and design / implement language itself of course). There are way more important things to consider.

Luckily I'm only working on those code bases so I don't care if it causes other programmers' heartache. If you don't like your code base, then I swear it's never been easier to find a job on newer code bases.

>"Legacy needs to be dealt with constantly and relentlessly"

To make your life easier? The customers may have totally different opinion.

Reply on news.ycombinator.com