C++ needs to give itself up and make way for other, newer, modern, language that have far, far fewer baggage. It should be working with other language to provide tools for interop and migration.
C++ will never, ever be modern and comprehensible because of 1 and 1 reason alone: backward compatibility.
It does not matter what version of C++ you are using, you are still using C with classes.
Half-serious reason: because with each C++ version, we seem to get less and less what we want and more and more inefficiency. In terms of language design and compiler implementation. Are we even at feature-completeness for C++20 on major compilers yet? (In an actually usable bug-free way, not an on-paper "completion".)
Feature complete is a pretty hard goal to reach. It sounds like "added all the features" but is closer to "bug compatible across compilers" (not saying there are bugs just that recent versions have removed a lot of wiggle room for implementations)
Also modules was a lot and was kind of the reason it took so long. They are wonderful and I want them but proper implementations (even with many details being implementation defined) required a lot of work to figure out.
Most of the time all the compilers get ahead of the actual release but in that case there were so many uncertainties only rough implementations were available beforehand and then post release they had to make adjustments to how they handled incremental compilation in a user facing way effectively.
The compiler design is definitely becoming more complicated but the language design has become progressively more efficient and nicer to use. I’ve been using C++20 for a long time in production; it has been problem-free for years at this point. It is not strictly complete, e.g. modules still aren’t usable, but you don’t need to wait for that to use it.
Even C++23 is largely usable at this point, though there are still gaps for some features.
Funny how gcc seems to be the top dog now, what happened to clang? Thought their codebase was supposed to be easier and more pleasant to work with? Or maybe just more hardcore compiler devs work on gcc?
I think you need to spend more time with literally any tool -- "Haven't seen anything I'd rather used" reads like "Haven't gotten over the initial learning curve with any other tool"
C++ is sub-optimal for almost any task. For low level stuff plain C or maybe Rust. for higher level Python, Lua, or some Lisp. C++ is a weird in-between language that's impossible to hold correctly.
The nice thing about C++ is that you can more or less turn it into C, if you want. My C++ code is closer to C than idiomatic, modern C++, but I wouldn't want to miss the nice parts that C++ adds, such as lambda functions and the occasional template for generalization. Pretty much the only thing I'm missing from C are order-independent designated initializers, which became order-dependent in C++, and thus useless.
> "Haven't seen anything I'd rather used" reads like "Haven't gotten over the initial learning curve with any other tool"
What an odd thing to say. I simply don't like certain design decisions in other languages that I've checked out and tried, and therefore do not see any reason to switch. E.g. I tried Rust, but it's absolutely terrible for quick&dirty prototyping, which is my main job.
Some other language need to step up and rewrite/replace LLVM then, because no language that relies on a ~30 million loc backend written in C++ can ever hope to replace it.
Zig plans to make LLVM optional. Rust has Cranelift. Go afaik has no dependencies on the C++ ecosystem including LLVM. Python and some other languages are built with C, not C++. So, progress is being made slowly to replace LLVM as the defacto optimizing code backend. Alternatives are out there, may they compete and win! C++ makes me pessimistic about the future of humanity..
Languages don't write code, people do. No one has rewritten LLVM because it already exists, and such a project would be insanely expensive for little benefit.
I for one can write C++ but I cannot write a single program in C. If the overlap was so vast, I would be able to write good C but I cannot.
I've done things with templates to express my ideas in C++ that I cannot do in other languages, and the behaviour of deterministic destructors is what sets it apart from C. It is comprehensible and readable to me.
I would argue that C++ is modern, since it is in use today. Perhaps your definition of "modern" is too narrow?
What do you think is causing the issue? We are having the same kind of problem. Core isolation, no_hz, core pinning, but i am still getting interrupted by nmi interrupts
Details depend, but the root cause is basically the same every time: your hardware is designed to do something other than what you want it to do. It might be close enough that you want to give it a shot anyway (often works, often doesn't), but solutions can be outside of the realm of what's suitable for a "prod-ready" service.
If you're experiencing NMIs, the solution is simple if you don't care about the consequences; find them and remove them (ideally starting by finding what's generating them and verifying you don't need it). Disable the NMI watchdog, disable the PMU, disable PCIe Error Reporting (probably check dmesg and friends first to ensure your hardware is behaving correctly and fix that if not), disable anything related to NMIs at the BIOS/UEFI/IPMI/BMC layers, register a kernel module to swallow any you missed in your crusade, and patch the do_nmi() implementation with something sane for your use case in your custom kernel (there be dragons here, those NMIs obviously exist for a reason). It's probably easier to start from the ground up adding a minimal set of software for your system to run than to trim it back down, but either option is fine.
Are you experiencing NMIs though? You might want to take a peek at hwlatdetect and check for SMIs or other driver/firmware issues, fixing those as you find them.
It's probably also worth double-checking that you don't have any hard or soft IRQs being scheduled on your "isolated" core, that no RCU housekeeping is happening, etc. Make sure you pre-fault all the memory your software uses, no other core maps memory or changes page tables, power scaling is disabled (at least the deep C-states), you're not running workloads prone to thermal issues (1000W+ in a single chip is a lot of power, and it doesn't take much full-throttle AVX512 to heat it up), you don't have automatic updates of anything (especially not microcode or timekeeping), etc.
Also, generally speaking, your hardware can't actually multiplex most workloads without side effects. Abstractions letting you pretend otherwise are making compromises somewhere. Are devices you don't care about creating interrupts? That's a problem. Are programs you don't care about causing cache flushes? That's a problem. And so on. Strip the system back down to the bare minimum necessary to do whatever it is you want to do.
As to what SystemD is doing in particular? I dunno, probably something with timer updates, microcode updates, configuring thermals and power management some way I don't like, etc. I took the easy route and just installed something sufficiently minimalish and washed my hands of it. We went from major problems to zero problems instantly and never had to worry about DMA latency again.
If social media, alcohol, drugs, gambling, phones are so, so, so bad for children. Just ban them from children.
We were completely fine 30 years ago without any phone. They will survive. They will probably thrive because now they have to learn how to hack the system.
Instead, we just give them everything they need and all the thinking they do is scrolling.
This is patently false because no one can actually understand something from just trading RFCs or understand things from just purely reading the code. 90% of the time the damn thing is unspecified so you have to give motivating examples
I'd agree- I think the analysis I was referring to believed that analyzing a taboo makes it no longer useful as a shortcut. Guess that didn't come across enough for anyone to offer a refutation.
Preventing spam is as easy as gatekeeping. We should be bringing it back. Perhaps there should be multiple layers of social media. There’s deeper and deeper level of authenticity as you go deeper into the network
I think they're saying that OpenSSL is NOT elegant, but that it is successful regardless; hence, code elegance is irrelevant to whether a product is successful or not (and thus that horribly ugly LLM-generated code has a shot at becoming successful).
reply