Hacker News Reader

That's not going to happen. There's just too much friction to reach consensus on how to move the language in that kind of direction. It's like trying to get a centipede to walk to the food when none of the legs can agree on the best path to take. Before that happens, it's much more likely that some other language that interoperates well with C++ will reach a useful state (with regards to IDE support and other tools) and will be embraced by the community. By "community" I don't just mean hobbyists, but the major members of the C++ committee: Microsoft, Google, Nvidia, Intel, etc. That language might be Rust or it might be some other language that's yet to appear. It might not even be a single language, but several. I personally think Rust is not a suitable successor to C++.

> I personally think Rust is not a suitable successor to C++.

If you don't mind, what do you think are the main reasons for that?

One thing that rust doesn't (yet) have is a strong presence and toolbox for usage in scientific computing. In scientific computing, when speed matters, Fortran/C/C++ still very much rule and rust won't take their place anytime soon. Julia has a better chance at that, in fact.

I'm still developing my opinion of Rust, but

* It's too different. This is to be expected because it was never designed to be like C++. For example, if I have an OOP-heavy application, moving it over to Rust is not a matter of fixing up a few ideas here and there like it might be with, say, Java or C#. It calls for a redesign/rewrite. I don't think a memory safe C++ successor would need to be more like Rust than like C++.

* The language is not substantially simpler than C++. I find traits to be particularly difficult to reason about and to follow, to the point that I find myself just trying to find the right incantation that will appease the compiler. And that complexity shows up at build time just like it does with C++.

> I personally think Rust is not a suitable successor to C++.

You seem to know quite a bit. What drives this opinion?

> I feel C++ needs to do the following to be able to survive [...]

absolutely. unfortunately, saftey oriented proposals tend to focus on a weaker warning-esque approach ([[nodiscard]], contracts, etc.), which, in my opinion, will ultimately only make things worse. i'll stay away from my type-systems-are-great soapbox :)

the refusal to break ABI, remove non-destructive moves, the strengthening of concepts more akin to their original proposal, are not even on the horizon of discussion, despite us having exemplars of all 3.

it's perplexing, to say the least.

The refusal to do an ABI break is a crazy move on the C++ committee's part. C++ without an ABI break loses performance, has a bunch of confusing features (eg bucket iterators in hash tables...), and completely prevents a lot of proposals that would make smart pointers work a lot better.

Not entirely disagreeing there, but to clarify, breaking hash table iterator guarantees would be an API break, not merely an ABI break.

> Adopt language epochs

I guess the issue has always been that no one can agree on particular language subsets?

However, one could view projects such as Google's Carbon as precisely that. A restricted safer subset of C++ with a more succinct syntax.

> Adopt language epochs so that the language syntax and semantics can be evolved without having to fight backwards compatibility.

That's what Javascript got surprisingly right IMO: you can target the latest bleeding edge features, and still be able to compile and run them on 20-year-old browsers through code re-writing (aka transpilation) and polyfills [1]

I often wish this was available for other languages, too.

[1] Well, not all features because some if them are notoriously hard to polyfill (IIRC Proxies are one such unpolyfillable feature). And there's the huge issue of the entire world relying on just one guy: https://github.com/zloirock/core-js/blob/master/docs/2023-02...

> you can target the latest bleeding edge features, and still be able to compile and run them on 20-year-old browsers through code re-writing

The problem with C++ is the other way: you can't compile 10 year old code because the language has "evolved".

You still can compile 10 year old code - it's fully backwards compatible.

If you choose to write new code in the same way as you did in pre-11 C++, though, people might have a lot of questions for you.

Mostly backwards compatible.

…on the other hand it doesn't take a PhD to write a linked list in C++.

Linked lists are complicated. You can get something that compiles easily with C++, but to be sure it doesn't leak memory might require you to get that PhD after all.

Linked lists are a very simple data structure, and pretty much everyone can get them right. There haven't been any big memory safety CVEs to my knowledge around linked list manipulation. The same for binary trees.

These pointer-based data structures are used a lot when you are manipulating large structs in C and C++, as they let you "move" then between data structures without copying a ton of memory.

It's not exactly rocket science or even PhD worthy, but getting basic exception safety right around manual memory management can get tricky.

Well..implementing them in "safe" Rust is not just tricky - it requires a super-brain.

You can use unsafe in Rust to get basically the same guarantees for your simple linked list as in C++?

If you need a PhD to avoid memory leaks, stop coding immediately, you don’t know what you are doing

Show an example of a lock-free concurrent stack freeing nodes memory.

... on the third hand it's better not to roll your own list in any language ;-)

Joking aside, some stuff are currently really hard in Rust, but the rate of change slowed down, and all I can see now is everyday ergonomic improvements, so there is hope for (slightly) simpler syntax in the future.

Doubly linked lists break one of the fundamental promises you make to the borrow checker: single ownership. I doubt they're going to get much easier.

It's also just generally not a wise structure to be making or using in applications level development at this point. Vectors will outperform them most of the time, are more cache friendly, and easier to write these days. And Rust has already done the work of building collections you can already use, including some that can be used no-std in embedded/baremetal environments.

And if you really need a linked-list type structure, and are competent to make it and use it properly/safely, unsafe {} is waiting for you.

You tend to see linked lists in places like operating systems, storage systems, and stackless asynchronous server systems. These kinds of linked lists actually do perform better than vectors in most cases.

Specifically, linked lists do well when objects are: 1. Large, specifically 100s of bytes 2. Moved frequently between collections 3. Intrusively linked (meaning that the pointers are part of the struct, not a separate library) and 4. Never randomly accessed

One size does not fit all when it comes to performance of list structures, unfortunately. In particular, large items tend to break standard library structures, since they are not the usual case.

Yes, hence why I said "applications level" development specifically. 99% of developers will never need to go this path. Those that do, they're already working down in unsafe land usually in embedded systems and OS development, and they need to think carefully about what they're doing.

I'm personally not entirely sold on Rust's memory safety model, though I did learn to work with it when I was getting paid to work in it.

I don’t think it takes a PhD to write an unsafe linked list in Rust. And an unsafe linked list in Rust would still be safer than the equivalent linked list in C++

How would the equivalent linked list in c++ be unsafe?

The problem with c++ was never writing simple data structures, but was writing complete programs without a single mistake in the informal contracts between functions. Static analysis tools and other crutches help but having a stricter ruleset to enforce is what makes rust a winner.

The list itself would not be unsafe, but the usages of it could be. For example, iterator invalidation, access from another thread, etc that Rust would prevent you from doing even if you used unsafe to implement the linked list.

If you feel strongly about this, I suggest you get involved. This page lists a bunch of different ways you can participate:

https://isocpp.org/std/meetings-and-participation

As far as epochs go, you’re not the only one:

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p18...

Why would you waste time on that? They will never break ABI now.

Rust still needs to prove itself on being a GCC/LLVM alternative, CUDA, SYSCL, HPC and HFT compiler toolchains, MPI, AUTOSAR and MISRA standards, game console SDKs, mobile OS SDKs, ....

C++ still has lot of momentum for the upcoming decades, regardless how much we would like to RIIR everything.

I pretty strongly disagree with this. Rust doesn't replace all of C++; it only replaces some. Specifically, there's not a great reason to write a compiler in a language with manual memory management. HPC is also starting to move to higher level alternatives like Julia.

Also AUTOSTAR/MISRA are funny to bring up because they are desparate and only semi-successful attempts to bring a semblance of safety to fundamentally unsafe languages. You get all of the safety of them (and more) in Rust with the 2 rules of 1. don't use unsafe. 2. have tests.

Julia is implemented in C++, and makes use of LLVM, written in C++.

Apparently AUTOSAR and MISRA are relevant enough for Rust, that efforts are being made to allow a Rust certification subset as well.

Julia isn't primarily implemented in C++. Most of the implementation is in Julia (68%). About 25% is C/C++, but that could be changed if someone wrote a good enough compiler in a fast enough memory safe language. The rest is in a custom scheme dialect (femptolisp) and is in the process of being replaced by Julia (see JuliaSyntax.jl).

Waiting for the LLVM rewrite in Julia.

I'm hoping we get there. LLVM has really good codegen, but I think we can probably do a better job on the optimizer side than they do. Don't expect anything soon though. Replacing LLVM is (kinda obviously) a ridiculously huge project.

It would be interesting to see it happening.

> If C++ doesn’t come up with a good story real soon to deal with memory safety at the language level and deal with the mess of language complexity, it will be relegated to a legacy language.

That's exactly the purpose of WG21 SG23, convened for the study of safety and security for C++26 and beyond. You can complain or you can join and influence the future.

> With Rust, C++ now has a free, popular competitor language

Rust is so oldtimer. C++ is at version 24 and counting.