I started my life as a dev with PHP, learning it on the job to set up a custom Wordpress theme with plugins for special datatypes (eg STCs).

When I was 21, they offered to pay for my tuition so I went back for a CoE degree (later switching to CS). The moment I touched C++ - on my very first day in their “intro to programming” class - I fell in love. The type system, debugging, and ecosystem was fantastic compared to PHP 7 that I was using at the time. With my manager's permission, I went back to some of our existing intranet apps and built a C++-based API for them that our PHP would call over a web-socket, so that I could leverage the type system (and performance). Those systems are still in daily use, company wide. Maintenance hasn't been a problem. And that’s despite running in a really weird environment (IBM Pase for i).

Now, after using Rust and Axum, I'd vastly prefer the Rust ecosystem for creating that type of API. But C++ deserves credit. It really is a great language, especially if you’re coming from web languages like (non-TS) JavaScript or PHP.

> If you are working on an older codebase that has evolved over 20-30 years, or one that has not been maintained by talented people, you will have a very different experience.

I'm trying to think of any other language that could fit that description and not also be a terrible experience. In fact, I'd prefer C++ to many other possibilities I can think of (C, Java, Fortran). The exception would be C#, but I'm not sure if it's old enough to fit.

Fair point, although I think it's true that C++ gives you more rope to hang yourself with, and if I had to choose, I'd rather maintain a crusty old codebase written in Java than one written in C++.

The issue is that the JVM has started deprecating features which old codebase rely on.

I don't work with it, but even I know about the JVM no longer supporting sandboxing or being able to kill threads programmatically.

C++ doesn't have this issue because you can still deploy code from an old toolchain onto a modern OS.

You can and always have been able to .destroy() threads in java, but doing so breaks the memory model in ways that make it clear that you should never do it. My guess is that if you're kill heavy in c++, then you've also run into bugs waiting on locks of threads you've now just murdered. That's why there's a ton of great abstractions for how to "kill work running somewhere else" that doesn't leave your application in a potentially unstable state.

Java 9+ sure did kill off a lot of things that weren't particularly ideal. Most normal devs who don't write libraries probably can't even name a single feature removed (corba, script interpreters, some jmx cruft, etc). Most of what was culled still exists in libraries that could easily be added back with project imports. Maybe Java applets are super dead now? I don't believe any modern browsers still support native plugins, but maybe there are some niche individuals bemoaning the loss of java web start.

As for the "can still deploy code" comment, the same applies to java. Look around, and sadly you see very old releases of java still in use today. My guess is that if I fired up a java 1.0 compiler and JVM today, it would run on my PC (poorly).

Before criticising something, please consider being well enough informed to warrant the comment.

I want to run untrusted code in the JVM, and limit its access to IO and compute so it can't phone home or mess up my system. This used to work with the Security Manager plus being able to kill threads.

Now, based on the new thread killing implementation, a malicious thread can just catch the exception and keep running, and on top of that the Security Manager is being removed too.

So now my options are, switch to C++ and Lua, or run every sub-component in its own VM and add a bunch of IPC in the middle of my application. Or maybe port it all to JavaScript. Massive headache, performance implications are bad and it breaks continuity in an open source community that's been running since 2001.

This is my use case, maybe hello world 101 doesn't have any problems but I'm sure anyone doing more complex stuff is going to hit the same kind of issues.

You do have some options in the JVM world. As mentioned, you should still be able to kill threads if you really wanted to, but if you wanted to pivot to JS/LUA, there are still jsh alternatives like rhino in JVM to avoid some of the larger reworks. They are based on their own stack/continuation work of over a decade ago, so not fresh. You may want to look at virtual thread pools through. Since these are green threads and the JVM preempts them aggressively, there may be the abstractions you're able to exploit for your more aggressive culling needs.

I don't know about security manager though. I haven't poked at it for a while, but I wasn't aware that they removed it? Maybe you just need to opt I to the JVM access rule to support it. You can always layer your security with a separate class loader, which can prevent child tenants from even seeing protected classes and statics, which is always good security layering if untrusted is your problem.

So that's a fun one. C# the language people know first released in y2k and the 1.0 release was 2002.

So it definitely is old enough to fit and it certainly has it's warts from age that show up in long lived projects.

I used to work on a codebase at Microsoft that was classified as a microservice. Pretty much entirely written in C# and it was about 12 years old.