- cross-posted to:
- [email protected]
- [email protected]
- cross-posted to:
- [email protected]
- [email protected]
You must log in or register to comment.
The inherent problem with this kind of solution is that if you don’t break backwards compatibility, you don’t get rid off all the insecure code.
And if you do break backwards compatibility, there’s not much reason to stick to C++ rather than going for Rust with its established ecosystem…
Given how long and widely C++ has been a dominant language, I don’t think anyone can reasonably expect to get rid of all the unsafe code, regardless of approach. There is a lot of it.
However, changing the proposition from “get good at Rust and rewrite these projects from scratch” to “adopt some incremental changes using the existing tooling and skills you already have” would lower the barrier to entry considerably. I think this more practical approach would be likely to reach far more projects.
There’s been plenty of interop options between C++ and just about anything for decades. If languages like D, that made it piss easy, weren’t gonna change people’s minds, nothing can. Ditching C++ is the only way forward.
Interop between Rust and C++ is pretty bad actually - I can understand wanting to avoid that.
However I still agree. I can’t see opt-in mechanisms like this moving the needle.
I’m a bit surprised that it’s supposed to be this bad, given that Mozilla uses it in Firefox and there’s the whole CXX toolchain.
Granted, Rust was not designed from the ground up to be C+±like, but I’m really not sure that’s a good idea anyways.
Wanting bug-free programs without wanting functional programming paradigms is a bit like:
Of course, if we’re able to migrate a lot of old C++ codebases to a slightly better standard relatively easily, then that is still something…
The biggest issue is move constructors. Explanation here: https://cxx.rs/binding/cxxstring.html#restrictions
Probably seems like a little thing but I found it quite annoying in practice, and there are other things like not being able to combine serde-derive and cxx FFI on the same struct.
Sounds like you’ll always have to do this little dance for any string you want to pass through, so I can definitely see how that could become quite annoying.
For not being able to combine serde-derive and cxx FFI on the same struct, there’s a simple trick that can be used for many such situations:
struct CxxThingamabob { ... } #[derive(Serialize, Deserialize)] #[serde(transparent)] struct SerializableCxxThingamabob(CxxThingamabob);That just moves the Serde implementation to a different struct, so that you can choose which one you want by either wrapping or unwrapping it.
I gave C++ and D as an example. A language that for all intents and purposes is irrelevant despite being exactly what everyone wanted, something like Java/C#, but with no compromise and direct bindings to C/C++. And why I’m more apologetic to the idea of something more drastically different like Rust as opposed to another touched up clone of C.
Unfortunately, I don’t think D is good enough to prove your point. From your follow-up comment:
A language that for all intents and purposes is irrelevant despite being exactly what everyone wanted,
As someone who uses D, I can attest that it is not what everyone wanted; at least not yet. Despite all the great things in the language, the ergonomics around actually using it are mediocre at best: Several of its appealing features quickly turn it into a noisy language, error messages are often so obtuse as to be useless (especially with templates and contracts in play), and Phobos (the standard library) is practically made of paper cuts. Also, the only notable async support is a fragile mess, and garbage collection is too deeply embedded into both the stdlib and the ecosystem.
(To be fair, D could be vastly improved with better defaults and standard library. That might happen in time, as Walter and the other maintainers have shown interest, but it’s just wishful thinking for now.)
Also, D is an entirely different language from C++, and as such, would require code rewrites in order to bring safety to existing projects. It’s not really comparable to a C++ extension.
wake me up when Rust fixes its’ supply chain attacks susceptibility (solid stdlib and rejecting external crates, including transitive deps
Probably not going to happen. I will say that it’s less bad than you might think, because there is more-or-less an unofficial extended stdlib, i.e. high-quality, widely used libraries which are maintained by people in the Rust team.
But yeah, I’m involved in a somewhat larger project and we’ve cracked 1000 transitive dependencies a few weeks ago, and I can tell you for free that I don’t personally know the maintainers of all of those.
If this was more of a security-critical project, there’s probably a dozen or so direct dependencies that we would have implemented ourselves instead.This has been one of my biggest frustrations while learning Rust. I’m coming from .NET which has an incredible wealth of official System and Microsoft libraries all of which are robust and well documented.
Rust on the other hand has the bare minimum std library, with everything else implemented by the community. There isn’t even a std async library. It’s insane.
Even the popular community libraries are severely lacking in documentation or inexplicably unmaintained.
Rust has a ton of potential but it desperately needs some broad funding to align the fundamentals to a decent standard.
I’ve done a bit of C++ coding in my time. The feature list of the language is so long at this point that it is pretty much impossible for anyone new to learn C++ and grok the design decisions anymore. I don’t know if this is a good thing or not to keep adding and extending or whether C++ should sail into the sunset like Fortran and others before it.
Fortran is still a good language for some purposes I think.
And I feel the same way, C++ tries to solve the problem of having too many features by adding more features.
Don’t get me wrong. There is still a time and a place for Fortran. And this will also likely always be the case for C++. But I’m not sure it is entirely wise to choose it if you’re creating a new project anymore.
I’m barely competent at programming. What is the use case for Fortran, besides maintaining ancient code?
A lot of computational heavy tasks for science were done in Fortran at least ten years ago (and I think still are). I was told that’s mainly because Fortran has a good deal of libraries for just that, and it was widely taught in academia so this is a common ground between the older and newer generations.
I think it may be gradually superseded by Python, but I don’t know if it is
A lot of the underlying libraries in python are actually written in Fortran (or were when they were conceived, and the Fortran components later replaced). Numpy, for example, was originally pretty much a wrapper on top of BLAS and LAPACK.
It was designed from its very start to be used for numerical computing. So the language it built around it and it sort of excels in that use case.
This used to be the holy bible of numerical methods, if you want to see some sample code: https://s3.amazonaws.com/nrbook.com/book_F210.html
You might be right, but I have heard that song a lot of times, python, java, ml, pascal, obscure webdev.languages, AI will do it, typescript, etc etc etc
I’d go with a better python than rust, you can put that “once in a lifetime asm optimized memsafe multi threaded code” in a package and just use it from python. But python has GIL and you can’t just remove it so who knows what will be the next shiny thing? Probably several languages, like for easy peasy stuff up to hardcore multi threaded memory safe stuff. Gotta push us oldtimers out in some way, right :-) ?
But python has GIL and you can’t just remove it so
https://docs.python.org/3/using/configure.html#cmdoption-disable-gil
The GIL appears to be slowly going away.
What I meant with that is if you remove the GIL, the people have to understand parallel access to data and a lot of orher quite complicated paradigms, which defeats, IMO, the whole idea of having a “simpler” language paired with a more versatile but more complex and complicated language, like C++.
… for the very reason that Fortran you can grasp in an evening.
The feature list of the language is so long at this point that it is pretty much impossible for anyone new to learn C++ and grok the design decisions anymore.
Even if it is possible, it’s a high bar. The height of that bar matters in bringing new people in.
I have seen decades of would-be “C++ killers” come and go. I think that in the end, it is C++ that kills C++. The language has just become unusably large. And that’s one thing that cannot be fixed by extending the language.
I have seen decades of would-be “C++ killers” come and go. I think that in the end, it is C++ that kills C++.
I think you’re right.
I am, admittedly, a card carrying member of the C++ curmudgeon club. But I would gladly gravitate to a sexy new C++ subset for my projects, if one gains some momentum.
I do a lot with goLang, right now, instead.
But I would adore joining with a community effort to choose reasonable safe default C++ libraries for a bunch of use cases, if one gained the traction to cover my own use cases.
Google started work on Carbon due to the difficulty of getting the C++ standards committee to accept any real, fundamental changes to the language. If Google, a grandmaster at manipulating standards committees, couldn’t get something passed, I don’t foresee this proposal getting anywhere.
The C++ standards committee don’t see memory safety or UB as a problem. If they did they wouldn’t keep introducing new footguns, e.g. forgetting
return_void()in a coroutine. They still think everyone should just learn the entire C++ spec and not make mistakes.It boggles the mind that any language - let alone a systems programming language that most of the world’s infrastructure is built upon - wouldn’t adjust their specification to eliminate undefined behavior wherever possible. And C++'s all seem to be in the worst possible places, too.
I think once things get established the people in charge see any attempt to change it as some kind of personal insult, so they just go into defence mode. You see the same thing e.g. with Python - for literally decades they’ve denied that performance matters and it’s really only recently that that has changed.
I think it will only get worse for C++ because the people who understand this stuff have mostly given up on C++.
I’m a bit skeptical that a borrow checker in C++ can be as powerful as in rust, since C++ doesn’t have lifetime annotations. Without lifetime annotations, you have to do a whole program analysis to get the equivalent checks which isn’t even possible if you’re e.g. loading dynamic libraries, and prohibitively slow otherwise. Without that you can only really do local analysis which is of course good but not that powerful.
Lifetime annotations in the type system is the right call, since it allows library authors to impose invariants related to ownership on their consumers. I doubt C++ will add it to their typesystem though.
Read the proposal: Lifetimes annotations, the rust standard library (incl. basic types like Vec, ARc, …), first class tuples, pattern matching, destructive moves, unsafe, it is all in there.
The proposal is really to bolt on Rust to the side of C++, with all the compatibility problems that brings by necessity.
Gonna need to start calling it C++++ at this point. So much extra shit in the standard library
C# be like, am i a joke to you?
I’m not sure, C# wants to hear the response to this…
C/C++ : Yeah.
Honestly, i prefer that over minimal standard libraries where you need dotzens of changing depencies for the simplest stuff.
Nah standard libraries are great but C++ has a lot of… cruft. Maybe don’t plonk a lot of Rust in there despite all the positives
Sure, not saying C++ isn’t cluttered.
Well, its a brand new standard library. A fresh start.
Ah ok just read the article and not the proposal. I’m surprised that they went that far but as I wrote I think that lifetime annotations are a good idea, hope the C++ people find a way to add them to the language that actually works well, which sounds like an incredibly difficult task.
“They” did not go anywhere yet. This is a proposal, nothing more. It will take serious discussions over years to get this into C++.
Prominent figures already said they prefer safety profiles as a less intrusive and more C++ approach at conferences It will be fun to watch this and the other safety proposals going forward.
On one hand, I’m pleased that C++ is answering the call for what I’ll call “safety as default”, since as The Register and everyone else since pointed out, if safety constructs are “bolted on” like an afterthought, then of course it’s not going to have very high adoption. Contrast this to Rust and its “unsafe” keyword that marks all the places where the minimum safety of the language might not hold.
On the other hand, while this Safe C++ proposal adopts a similar notion of an “unsafe” context, it also adds a “safe” keyword, to specify that a function will conform to compile-time safety checks. But as the proposal readily admits:
Rust’s functions are safe by default. C++’s are unsafe by default.
While the proposal will surely continue to evolve before being implemented, I forsee a similar situation as in C where code that lacked initial const-correctness will struggle to work with newer code and libraries. In this case, it would be the “unsafe” keyword that proliferates everywhere just to call older, unsafe code from newer, safe callers.
Rust has the advantage that there isn’t much/any legacy Rust to upkeep, and that means the volume of unsafe code in Rust proframs is minimal, making them safer overall today. But for Safe C++ code, there’s going to be a lot of unsafe legacy C++ code and that reduces the safety benefit for programs overall, for the time being
Even as this proposal progresses, the question of whether to start rewriting some code anew in Rust remains relevant. But this is still exciting as a new option to raise the bar in memory safety in C++.
Null safety is orders of magnitude simpler than memory safety. Kotlin is a null safe language by default. Java is infamously not. Anyone who has worked on a mixed-language Kotlin project can tell you how quickly null safety becomes a pain once guarantees break down - and that’s in a language where these issues are flagged instantly and you can “fix” the problem in a couple of characters! Mixed memory safe/unsafe codebases would be a nightmare in comparison.
Also, C++'s ecosystem consists of deeply entrenched libraries with ancient codebases. Safe C++ might be useful in a decade or two if library maintainers could be pushed to make the switch (good luck with that, if it’s half as much of a paradigm shift as Rust), but by then there will probably be multiple competing language features that claim to solve the same problem. It’s the C++ Way™.
As much legacy code as has been written in C++, I’d think a total rewrite might be better ironically, in terms of passing on important institutional knowledge, to the extent large-scale production codebases are concerned. Attacking it bit by bit (pun not intended) might even take longer than just ripping things up and starting anew.
The big downside is that, for backwards compatibility, the default must still be unsafe code. Ideally this could be toggled with a compiler flag, rather than having to wrap most code in “safe” blocks (like rust, but backwards).
One potential upside that people don’t seem to be discussing is that the safe subset could also be the place to finally start cutting down the bloat of C++. We could encourage most developers to write exclusively in the safe subset, and aim to make that the “much smaller and cleaner language” trying to get out of C++.
Oh yes! Let’s keep adding more bloat to ultra complex language C++ surely it will fix everything !
That’s a wild screenshot.
void main(void) is an abomination
Is this going to be re-posted every month?
Anyway, I’ve come to know since then that the proposal was not a part of a damage control campaign, but rather a single person’s attempt at proposing a theoretical real solution. He misguidedly thought that there was actually an interest in some real solutions. There wasn’t, and there isn’t.
The empire are continuing with the strategy of scamming people into believing that they will produce, at some unspecified point, complete magical
mushroomsguidelines and real specified and implemented profiles.The proposal is destined to become perma-vaporware. The dreamy guidelines are going to be perma-WIP, the magical profiles are going to be perma-vapordocs (as in they will never actually exist, not even in theoretical form), and the bureaucracy checks will continue to be cashed.
So not only there was no concrete strike back, it wasn’t even the empire that did it.
Is this going to be re-posted every month?
That was a different community.
Also: https://xkcd.com/1053/
