this post was submitted on 21 Oct 2024

194 points (99.0% liked)

Programming

17248 readers

255 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 1 year ago

MODERATORS

snowe

Ategon

[email protected]

194

The empire of C++ strikes back with Safe C++ proposal (www.theregister.com)

submitted 2 days ago by [email protected] to c/programming

54 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 68 points 1 day ago (2 children)

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...

[–] [email protected] 35 points 1 day ago* (last edited 1 day ago) (1 children)

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.

[–] [email protected] -2 points 1 day ago (2 children)

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.

[–] [email protected] 1 points 9 hours ago* (last edited 8 hours ago)

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.

[–] FizzyOrange 8 points 1 day ago (2 children)

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.

[–] [email protected] 8 points 1 day ago (1 children)

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...

[–] FizzyOrange 2 points 9 hours ago (1 children)

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.

[–] [email protected] 1 points 2 hours ago

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.

[–] [email protected] 2 points 1 day ago

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.

[–] pkill -1 points 21 hours ago (3 children)

wake me up when Rust fixes its' supply chain attacks susceptibility (solid stdlib and rejecting external crates, including transitive deps

[–] [email protected] 4 points 13 hours ago

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.

[–] [email protected] 3 points 13 hours ago* (last edited 13 hours ago)

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.

[–] [email protected] 4 points 20 hours ago* (last edited 20 hours ago)

If you're hoping for the standard lib to have things built on evolving standards and ecosystems like HTTP clients, then I doubt that will ever happen. There are plenty of examples of why that would be a terrible idea (urllib, std::regex, etc).