Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I’m curious, what memory safe alternative is there for a C/C++ codebase that doesn’t give up performance?

Also for what it’s worth Rust ports tend to perform faster according to Russinovich. Part of that may be second system syndrome although the more likely explanation is that the default std library is just better optimized (eg hash tables in Rust are significantly better than unordered_map)



Ada has been around for years. The approach to memory safety isn't as strong as Rust, but it is a lot strong than C or C++. C++ is also adding a lot of memory safety, it is a lot easier to bypass than it is in Rust (though I've seen Rust code where everything is marked unsafe), but you still get some memory safety if you try.

All benchmarks between Ada, C, C++, and Rust (and others) should come down to a wash. A skilled programmer can find a difference but it won't be significant. A skilled C++ programmer wouldn't be using unordered_map so it is unfair to point out you can use something bad.


It has but you need spark too to avoid the runtime overhead. And I haven’t seen adoption of Ada in the broader industry so I wouldn’t pick it based on that. I would need to understand why it remains limited to industry’s that mandate government certification.

> A skilled C++ programmer wouldn't be using unordered_map so it is unfair to point out you can use something bad.

Pretending defaults don’t matter is naive especially in a language that is so hostile to being easy to add 3p dependencies (even without that defaults matter).


Rust has plenty of runtime overhead, or do you think Vec is fully static checked?

There are other examples for other data structures.


> A skilled C++ programmer wouldn't be using unordered_map so it is unfair to point out you can use something bad.

C++ isn't my primary language. Pray tell - what's wrong with unordered_map, and what's the alternative?


std::unordered_map basically specifies a bucket-based hashtable implementation (read: lots of extra pointer chasing). Most high-performance hashtables are based on probing.


Bluntly: exactly why does Ada matter, at all? The code footprint of software (1) written in Ada and (2) of concern when we talk about memory safety has measure zero. Is Ada better than C++? It turns out, I don't have to care: to go from C++ to Ada, one needs to rewrite, and if one is going to rewrite for memory safety, they're not going to rewrite to Ada.


If I'm going to rewrite I'm going to look at if formal proofs offer me anything, something ada can give. Ada is tiny I'll grant, but it has always been there.


A lot of Rust versus C or C++ comparisons be like: "Yo, check this Rust rewrite of Foo, which runs 2.5 faster¹ than the C original²".

---

1. Using 8 cores.

2. Single-threaded


1. Amdahl's law

2. That's a language feature too. Writing non-trivial multi-core programs in C or C++ takes a lot of effort and diligence. It's risky, and subtle mistakes can make programs chronically unstable, so we've had decades of programmers finding excuses for why a single thread is just fine, and people can find other uses for the remaining cores. OTOH Rust has enough safety guarantees and high-level abstractions that people can slap .par_iter() on their weekend project, and it will work.


Given most machines have cores to spare, and people want answers faster, is that a bad thing?


I think the complaint is that the C version isn’t multi threading ignoring that Rust makes it much easier to have a correct multithreaded implementation. OP is conveniently also ignoring that the Rust ports that I reference Russinovich talking about are MS internal code bases where it’s a 1:1 port, not a rearchitecture or an attempt to improve performance. The defaults being better, no aliasing that the compiler takes advantage, and automatic struct layout optimization all largely explain that it ends up being 5-20% faster having done nothing other than rewrite it.

But critics seem to often never engage with the actual data and just blindly get knee jerk defensive.


> Part of that may be second system syndrome

It may be that they've implemented it differently in a way that is more performant but has fewer features. A "rust port" is not automatically or apparently a 1:1 comparison.


It could be, but it's often just that the things you got in the box were higher quality and so your results are higher quality by default.

Better types like VecDeque<T>, better implementations of common ideas like sorting, even better fundamental concepts like providing the destructive move, or the owning Mutex by default.

Even the unassuming growable array type, Rust's Vec<T>, is just plain better than C++ std::vector<T>. It's not a huge difference and for many applications it won't matter, but that's the sort of pervasive quality difference I'm talking about and so I can well believe that in practice this ends up showing through.


There’s also compiler optimizations that aren’t available in c++ - noalias automatically applied everywhere + the compiler automatically optimally laying out structs is probably a non trivial perf add as well.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: