Given work on Circle (, Carbon, etc.) -- a "radically opinionated" Edition of C++ as a fork in the standard seems required (where Edition = Fork).
Incrementalism towards a "more polished" C++ won't be enough; not least due to branding.
Compiler Explorer lists it under Cpp2-cppfront. [3]
[1] https://herbsutter.com/2022/12/31/cpp2-and-cppfront-year-end...
There's a lot of "@nogc" D code out there. Audio FX plugins that do realtime DSP and game/graphics stuff come to mind.
I'd rather have the language give me a choice because it's very convenient to have. You'd be surprised how performant even GC'ed code in D's can be.
Not if you wish to use the standard library though right ?
All functions in the stdlib that are nogc are marked "nogc" in their definition
Now C++, Java and C# have many capabilities where D had an upper had back when Andrei's book came out, and naturally new competition also came into play with better corporate support.
If you make extensions for R/Tcl/Lisps for computations, plotting, abstract mathematics,
why the Garbage collection is bad?
You have native performance!
The only complaint is that D might think of adding some of the ergonomics of ML-family of languages. But it has its opinion (like Lisps) and I respect that.
Ergonomics and possibly safety could be goals.
I think it was a bit of a misnomer b/c it sounded like some glorified style guide. But it was actually a set of tools and helpers/wrappers that effectively made it impossible to write a lot of unsafe pre-modern C++.
For whatever reason it's never really caught on, though it looks like it's still being worked on: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
In principle it seems to kinda strikes the right balance where the language is narrowed - it's still all valid C++ (not an entirely new thing), but not all C++ is valid under the Core Guidelines
I'll be honest - I never tried it myself so I don't know it's deficiencies. Maybe someone who's given it a good try could weight in
There's only a few things I'm not a fan of, mostly around mutable out parameters (I prefer pointers not refs to make it clear at the call site it's a potential mutation)
That's my experience as well. Clang-tidy, clang-format, cppcheck and Core Guidelines. I don't recall the last project I've worked that didn't used that combo.
I don't believe this is true at all. I don't recall working on a single C++ for the last half dozen years which hasn't adopted the Core Guidelines up to the code review level.
Of course it's a blend of survivorship bias to claim that no project uses the Core Guidelines if you personally fail to consider it to start with.
Seems like something I would be interested in; I've increasingly felt overwhelmed by the endlessly growing scope of C++, and the challenge of understanding which parts are and are not "Modern C++".
I think the problem is a "safe C++" might look a lot like C++ but will have enough fundamental differences to be like a new language from a practical standpoint... devs will have to learn and use new patterns, new tools. Old code will need to be ported and possibly significantly rewritten, since we're talking about memory and threads. At that point, you might find using one of these other safe languages a better option.
C++ already crossed that threshold many years ago. Today's C++ is essentially a different language from C++ of yore. But it maintains compatibility with the old C++.
This is, I think, the central flaw in modern C++. Because of trying to keep that compatibility, so many newer features are bags-on-the-side and the language is bordering on unmanageable.
I think it would have been better to have branched off from C++, given it a new name, and waved goodbye to code compatibility. It would have been a better language for it.
And given that, if we have people working on Rust, Circle, Carbon etc, what would your idea actually change?
I guess most reasons are 'use what we know well', and 'use what we have tooling for'. But there's probably some others.
competitors will compete
For example:
- I think they bungled the Unicode transition by being too dogmatic and it took them a few point releases to include some quality of life improvements for migration that really allowed legacy libraries to transition
- the GIL dependency didn't go away
- typing was added later
Python 3 would have been a huge jump with those changes. Instead, Python 3.0 was very interesting but a major annoyance for limited benefits to 99% of Python app devs.
There's some serious work going on with the GIL these days. And also about immutability and reducing reference counting.
> [...] it took them a few point releases to include some quality of life improvements for migration that really allowed legacy libraries to transition
I wouldn't hold that against the transition too much. No one gets everything right from the start.
About typing: owing to Python's culture, I don't think mainstream Python will be statically typed by default (or even obligatorily) anytime soon.
As an opinionated js, definitely. Probably also incremental, in a way.
Browser frontends (in general) set not such demands (size, memory, speed guarantees) and its bloat more often comes from things outside of code (images, videos, trackers), so there's freedom to use whatever floats ones boat.
Combined with the ever increasing demands on app complexity, frameworks and born left and right. The strong movement into functional programming in this area has also led the way for other languages (SMLs, Lisps) that better fit that model.