Hacker News Reader

To get that, sometimes you need -ffmast-math, sometimes said undefined behavior, or code patterns which translate to better code for the processor you target.

There isn't really any fundamental limitation of Rust for those situations. A better reason why C++ is better than Rust for compute is the support for OpenACC, OpenCL, OpenMP, CUDA, ROCm/HIP, etc.

Also, if you give half an effort, C++ is pretty secure and robust to begin with, esp. on the pointers department.

The problem is that even if a "Safe" C++ could be defined, it would need to interoperate with the rest of the "Unsafe" C++ world. Perhaps a programmer can write absolutely safe C++ themselves but all bets are off once you're working with other programmers.

Just be mindful, and run a couple of valgrind tests on your code, and you're set. Been there, done that.

Seriously? A "couple of valgrind tests" would be insufficient for catching all but the most trivial and/or blatant memory safety issues in C++, especially when dealing with malicious users. Although I agree that dynamic analysis like valgrind and sanitizers should be the default for C++ development, industrial grade static analysis tools are at least as important. And needless to say, if you find Rust complains about code too much then just wait for what static analysis tooling will complain about.

That kind of integration is another reason, yes, but this is a passable moat, so I'm not talking about it much (mind you, I live in HPC world).

If programming is a team sport, every team player should be up to the level your project needs. If they are not, they should raise their bars. Seriously.

Yes, seriously, be mindful. Implement allocation and destruction first, fill your code between these two steps.

A couple of Valgrind tests is actually a whole procedure. It's an unfortunate downplay by me [0], probably because I'm very used to use Valgrind as a second nature.

[0]: https://news.ycombinator.com/item?id=31218757

So what about multithreaded code with potential race conditions that result in memory errors sometimes. Valgrind already only able to test the actually ran code paths, let alone find race condition-y bugs.

Also, this elitist notion of raising the bar is an instant “turnoff” for me, with all due respect, I can only assume from that that the given person may not be as much an expert as they think of themselves. Not saying that it applies to you as well, but you don’t leave me much other choice.

Memory safe - I will give you that. All the guarantees you listed are fine for synchronous Rust. But race conditions and deadlocks are not unknown in async Rust. Lots of race condition issues in tokio - including issues where futures leak.

That’s true, and usually I am the one pointing this out, that Rust is only data race free :D thanks for the pointer!

> Rust doesn't have a "I know what I'm doing, let me be" switch.

Every piece of code you write is security-sensitive. IMO It is our professional responsibility to our users that we treat it that way.

For a vast majority of situations, even if you know what you are doing, you are human and therefore will make mistakes.

If the (probably) most heavily invested C++ codebase, Chrome, has memory use-after-free/overflow bugs, there is no way that truly safe C++ can be written at any product-scale.

> Every piece of code you write is security-sensitive.

No, not every application is CRUD, not every application is interactive and no, not every application serves users and communicate with outside world in a way allowing to be abused during its lifetime.

This doesn't mean it gives me the freedom to write reckless code all over, but the security model of an authentication module and a mathematical simulation is vastly different.

> there is no way that truly safe C++ can be written at any product-scale.

I agree to disagree here, because of my own experience.

Like every other job in the world has a concept of liability,that will eventually arrive on computing world at scale.

The assumptions you make are almost palpable at this point.

Simulation precision and accuracy already carries tons of liability.

Talking like I or we don’t care about consequences is disturbing, esp. with the experience you have.

Well your responses look like you don't care, as if you had any clue about my experience as well, unless the sightseeing from that high altitude cloud is giving mirages.

Any cybersecurity law that requires citzens votes for adoption, will certainly get my signature.

If running static analyzers, testing for memory leaks, running end to end tests which takes days, adding strong bounds checking, and failing fast and with great noise as soon as something does not look right is not caring, you’re right. I don’t care.

All this is done for a code which has no network access, no kernel level work, even doesn’t accept any input after parsing the input model and making sure that it’s well formed with no loose ends.

Imagine what I’d do if it does any kind of authentication or user affecting work.

Call me surprised. OK, fair enough.

During my PhD I wrote a lot of simulation code in Matlab. This code was only ever run by me on my personal machine for the purpose of generating plots for my thesis. How is that security-sensitive?

We all agree that security is important and a lot of code running in security-sensitive contexts is bad. That's very different from saying that all code is security-sensitive.

Matlab is memory-safe, though, which is the kind of safety issue we talk about.

> Matlab is memory-safe, though

Who sold you that notion?

Matlab is proprietary glue holding together modules written in Fortran, C, C++, Java that allows the adhoc inclusion of DLLS put together by graduate students on the fly.

In what universe is any of that "memory safe"?

AFAIK it used to be written/interpreted in Java (though it uses a JIT compiler nowadays, doesn’t it?), and in that sense the language itself is memory safe. Of course if you link to a dependency written in an unsafe language you can have memory issues, but that is not what people commonly mean by “a memory safe language”.

> Of course if you link to a dependency written in an unsafe language

Like the matrix handling, plotting, and other modules dragged in from the 1990s standard FORTRAN library era.

Don't get me wrong, I have placed a lot of trust in those kinds of numeric libraries since the 1980s - NIST and other national labs code and review to a high standard - but they weren't then and aren't now "memory safe" just very probably and mostly bug free.

Unless they were, say, rewritten in Java .. and that's a whole other big ball of issues .. translated code.

I'm happy to play along and agree that the JIT compiled 'Matlab language' parts of Matlab are memory safe - but to the best of my experience with past versions that's just the glue portions - the reason so many people use Matlab is for the chunks that get glued together.

Aren’t many of these Fortran libraries heavily used all throughout almost any kind of application, somewhere deep down their dependency tree?

Absolutely .. and generally written to a very high standard with a lot of checking, rechecking and running forwards and backwards across multiple architectures with extensive technical mailing lists.

They can still have bugs, memory issues, be called with parameters that cause resource blow outs and aren't "memory safe" in the sense that modern managed languages are.

Matlab is exactly as reliable as well written Fortran and C code can be.

> To get that, sometimes you need -ffmast-math, sometimes said undefined behavior, or code patterns which translate to better code for the processor you target.

> Rust doesn't allow any of that, moreover limits me the way I can write my programs, no thanks.

I'm willing to prove you wrong here. Can you give some concrete examples?

For -ffast-math you can most certainly enable it, but AFAIK for now only in a localized fashion through intrinsics, e.g.:

https://doc.rust-lang.org/std/intrinsics/fn.fadd_fast.html

https://doc.rust-lang.org/std/intrinsics/fn.fmul_fast.html

So instead of doing this the dumb way and enabling -ffast-math for the whole program (which most certainly won't need it) you can profile where you're spending the majority of your time, and only do this where it'll matter, and without the possibility of randomly breaking the rest of your numeric code.

Personally I find this to be a vastly better approach.

Thanks for the information, I'll look into that. There's another comment talking about an algorithm I have implemented, it should be around in this thread.

> So instead of doing this the dumb way and enabling -ffast-math for the whole program (which most certainly won't need it)...

When you write HPC enabled simulation code, you certainly need it, and this is where I use it.

Is HPC code magically immune to values containing infs or NaNs?

In what sense does rust not expose the full power of the processor to the user? Can you give a concrete example?

> Just be mindful, and run a couple of valgrind tests on your code, and you're set.

Thousands of severe CVEs every year attest to the effectiveness of that mindset. "Just git gud" is not a meaningful thing to say, as even experienced devs routinely make exploitable (and other) mistakes.

Rust probably won’t allow me to implement a couple of lockless parallel algorithms I have implemented in my Ph.D., which are working on small matrices (3K by 3K). These algorithms allow any number of CPUs do the required processing without waiting for each other, and with no possibility of stepping on each other, by design.

In the tests, it became evident that the speed of the code is limited by the memory bandwidth of the system, yet for the processors I work with that limit is also very near to practical performance limit of the FPUs, as well. I could have squeezed a bit more performance by reordering the matrices to abuse prefetcher better, but it was good enough (~30x faster than the naive implementation with better accuracy) and I had no time.

Well, the method I verify the said codebase is here [0]. Also, if BSD guys can write secure code with C, everybody can. I think their buffer overflow error count is still <10 after all these years.

[0]: https://news.ycombinator.com/item?id=31218757

> Rust probably won’t allow me to implement a couple of lockless parallel algorithms I have implemented in my Ph.D., which are working on small matrices (3K by 3K)

That’s a bold claim to make without evidence. Things like that totally seem doable in Rust without a lot of ceremony. You might have to launder some lifetimes through unsafe if you can’t convince the compiler statically, but that’s not that hard.

> Also, if BSD guys can write secure code with C, everybody can. I think their buffer overflow error count is still <10 after all these years.

As was the problem with Linux enthusiasts claiming Linux was safer bedside fewer CVEs, BSD similarly benefits from having almost no attention paid to it + very few core developers so the feature growth rate is minimal. I don’t but the claim that BSD’s qualities extrapolate anywhere rather than a more mundane explanation or that BSD is the exception that proves the role somehow given no other successful project seems to be able to do the same.

I would happily give it a try, when I have some time on the side. But that day is not today, unfortunately.

> I don’t but the claim that BSD’s qualities extrapolate anywhere rather than a more mundane explanation or that BSD is the exception that proves the role somehow given no other successful project seems to be able to do the same.

It's mostly about "it's done when it's done" mentality and always putting the discipline before writing code fast. It's a vastly different mentality when compared to modern, conventional software development. This mentality also makes what Debian is Debian.

On the other end of the spectrum, we have the stressed solo developer syndrome, which brings us OpenSSL with its all problems and grievances.

> Rust probably won’t allow me to implement a couple of lockless parallel algorithms I have implemented in my Ph.D.

Why? Can you be more specific? Rust has built-in support for atomics and essentially the same memory model as C++, e.g.:

https://doc.rust-lang.org/std/sync/atomic/struct.AtomicU32.h...

And you can sidestep essentially any requirements of normal Rust using an `UnsafeCell` (e.g. that's how mutexes are implemented, with an `UnsafeCell` holding the data and an atomic).

I've written my share of lockless algorithms and I haven't really noticed any deficiency compared to C++, but then, I'm not an expert in this area, so if there is a deficiency here I'd love to hear about it.

A lot of people who criticize c++ seem to still think it's 2008 and there aren't the crazy amount of compiler checks/linters/standard practices that have happened since c++11 was released.

I like rust and I dick around with it a bit on some small REST projects I have for home automation but for day-to-day work I stick with c++ until rust support picks up in the industry a lot more than it currently is.

Because many of us only know C++ best practices from conference slides, and our own side projects, while we cry in despair when looking at typical corporate code bases.

Why do you think Bjarne Stroustoup main subject on conferences is how to write C++ properly without C style coding, for several years now?

What does Rust doesn’t allow? There really are only very few hard limits I know of, e.g. tail call elimination.

Ad absurdum it has quite great inline asm support.