arendjr @ arendjr @programming.dev

Posts

11

Comments

98

Joined

1 yr. ago

Of course, technically you can compile anything to almost anything. But I don’t think linking to a project that’s unmaintained for 15 years really helps your argument.

MSFT is known for changing names a lot, but not for killing technologies.

Silverlight would like a word ;)

Easy: GritQL

But I’m heavily biased, since I’m also the one implementing GritQL support into Biome :)

Second would be Rust macros, but they’re both more difficult to write and language-specific.

Yeah, it has its nice moments, but I also see it make mistakes and a lot of uselessly verbose text. It’s sometimes useful, sometimes funny, but mostly just noisy. Could be genuinely useful if it keeps improving though.

This is the actual PR, btw: https://github.com/getgrit/gritql/pull/85

I use Astro, because it allows me to write posts in Markdown and publish as a static website, though there are certainly other solutions that allow you to achieve the same thing. I just bundle it up in an Nginx Docker image and host it on Fly.io. If you want you can look at my setup here, though beware it isn’t documented (even the README is already out of date): https://github.com/arendjr/phebe

I would suggest writing blog posts about topics that you’re familiar with. Make sure you write the posts such that also people not too familiar with the material can follow it. Share your posts, and ask for questions and feedback.

I would still like to take a moment to answer your specific questions more directly:

And what does that exclude that C or C++ has that’s memory unsafe? I suppose use after free?

I think indeed use after free is the main one, although data races are another. Both are prevented in Rust by the borrow checker.

Dereference a pointer without a bounds check is the major problem when we’re talking about memory safety.

I think that's only half of the issue, with the other half indeed being use after free. After all, using a reference isn't much different from dereferencing a pointer. But doing bounds check on all your pointers is relatively easy to do by humans; you see where the pointer is being used and you see if there's a check or not. But proving liveness of your references before you use them is much harder, because it often requires whole-program analysis to understand when the target may be destroyed. And in terms of danger, use after free is just as dangerous as unbound pointer access.

Thread safe code isn’t the issue otherwise Java, Python, etc would all be on the list of languages to run from.

Thread safe code is also the issue. The reason people don't have to run from Java is because data races there don't escalate to memory unsafety; they're just caught as "ordinary" exceptions and thus manifest as ordinary (but still hard-to-debug) bugs. But in C++ those too can create invalid memory accesses, with a possibility for exploitation. In fact, even Go has a memory unsafe data race in its threading model that occurs because of its use of fat pointers that embed both a data type and an address.

Point being, that is still a very dangerous subset. Off-by one errors have done in a lot of C code (and C++ code that isn’t using range-based loops).

It is indeed a dangerous subset, but as I mentioned elsewhere, Rust's borrow-checker, which prevents use after free with references is still active, even in unsafe code. Off-by-one errors are still bound-checked even in unsafe code, unless you explicitly use the non-bound-checked versions. Any Rust code that is valid safe Rust is just as safe when wrapped in an unsafe block. It is only when you explicitly use the unsafe features that you're on your own when it comes to safety.

A lot of these issues can be avoided in C++ by just using existing types like std::variant, std::unique_ptr, std::shared_ptr, std::array, and std::vector (with the at based accessor) instead of lower level constructs.

They indeed avoid some of the issues, but notably don't protect against use after free at all. And take std::vector as an example:

 cpp

    
std::vector v;
v[2]; // out-of-bounds access

  

vs.

 rs

    
unsafe {
    let v = Vec::new();
    v[2]; // panic
}

  

Even wrapped in unsafe, the Rust equivalents are still safer.

I wouldn’t be so sure myself. Even unsafe Rust still uses the borrow checker, for instance. And you still get stricter checks around overflows and such as well. What unsafe does is that it unlocks the ability to use raw pointers and call other unsafe functions (among a few other things), but importantly it doesn’t disable the safety features that Rust has built-in. While unsafe Rust does indeed have some gotchas on its own, I think in general you’re still better off even with unsafe Rust than with C++.

I totally agree with this comment, and on top of that I would recommend anyone who really cares about the current state of affairs regarding safety in C++ to read this overview: https://accu.org/journals/overload/32/179/teodorescu/

Quote:

Personally, I am not convinced that in the near future, C++ can do something to stop this trend. C++ will leak talent to other languages (currently Rust, but perhaps in the future to Cppfront, Carbon, Hylo or Swift). If the progress towards safety started in 2015 as Bjarne suggested, the last 8 years have seen very little progress in safety improvements. Even with accelerated efforts, the three-year release cycle and slow adoption of new standards will keep C++ a decade away from addressing major safety concerns.

Also, writing memory safe code honestly isn’t that hard. It just requires a different approach to problem solving, that just like any other design pattern, once you learn and get used to it, is easy.

This statement is kinda ironic after you just said it’s “easier” to just ban the entire STL and dynamic memory allocation as a whole. You already left the domain of what most consider “easy” quite a while ago.

I’m learning c++ via exercism because I’d like to use it for game development and other high performance use cases, and because it’s a good pip for the resume.

I think for game development you don't need to worry about a shortage of C++ opportunities any time soon. Both Unreal and Godot are built in C++ as well as many in-house engines. Similarly, there are other niches where C++ is king and it would decades for that to change.

That said, there are certainly areas where C++ is already being replaced by Rust. Areas where both performance and security are important are the first movers, such as webbrowsers, operating system components, but also things like high-frequency traders (crypto ones almost exclusively use Rust, while traditional ones will move slower).

Personally, I also used to be heavily invested in C++, but I'm happy to have moved to Rust myself. I recently became an independent contractor, and while I would be happy to take contracts involving C++ to migrate them to Rust, I would certainly not start new projects in C++ anymore. But for you, I wouldn't worry about that yet. The experience you gain working with C++ will help you appreciate Rust more down the line. Just keep in mind that at some point you will be likely to be exposed to Rust too.

I’d be surprised if C tooling wasn’t available to provide sufficient proof for a given statically-linked program.

Be prepared to be surprised then. If such tooling was available, why isn't it being used by the projects for whom it matters? Yes, there is tooling available, but all the big parties using them are admitting it's not good enough for them. Those tools help, but they do fail in the "sufficient proof" department.

For some follow-up reading:

• Microsoft: https://msrc.microsoft.com/blog/2019/07/why-rust-for-safe-systems-programming/
• Chromium: https://security.googleblog.com/2023/01/supporting-use-of-rust-in-chromium.html
• Android: https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html
• Apple: https://security.apple.com/blog/towards-the-next-generation-of-xnu-memory-safety/

They all share the same basic facts: C and C++ are inherently memory unsafe. If any of them could've "just prove[n] your programs are memory safe", I think they would have.

Even references aren’t safe in C++ though, since there’s no borrow checker. Unless you copy everything or use reference counting types everywhere, you’ll still hit plenty of memory-violating footguns. But at that point, why use C++ at all?

Zig is better than C, but still a far stretch from the memory safety of Rust: https://www.scattered-thoughts.net/writing/how-safe-is-zig/

Go is almost memory safe, but it does suffer from an issue with its thick pointers (type + address) that can cause race conditions to misrepresent the type of a data structure. This can lead to true segmentation faults and out of bound memory accesses, though it will probably be quite difficult (but not impossible) to exploit them.

Zig is better than C, but still a far stretch from memory safe: https://www.scattered-thoughts.net/writing/how-safe-is-zig/ I think Nim is better because it uses a garbage collector and doesn’t have any pointer arithmetic, but I couldn’t find as much on the topic.

Generally, I don't think it really matters how many people are involved for the conflict resolution how many people are editing. There is one person who will reach the server first, and then the other(s) need to apply transformation(s).

But I think in your example the tricky part is when you say "each want to add their item as 3rd in the list because it is a todo list and its place in the list is important". The algorithm will be able to resolve for each of them that their item will come after the 2nd, and before what was originally the 3rd. But it will not be able to put them all on the 3rd position, of course, so it will sort their items and insert them adjacent to one another. So with 3 people inserting simultaneously into the 3rd position, one will end up in the 4th position and one in the 5th.