[pdimitar]

It's important, yes. If it was written in C/C++ I'll fully expect to have my servers pwned due to a memory safety bug that these (and many other) languages don't protect against.

There's a number of technical people with decision-making powers that pay attention. And a part of them prioritize Rust-written projects.

It's a sound (literally) and safe investment.

I don't get the people getting ticked off by the "written in Rust" clarification. Can we finally stop pretending that all programming languages are equal? They absolutely are not.

[rockwotj]

Milli uses unsafe for what it's worth so it's not as safe as you may think.

I do assume any post with "written in rust" does better on hacker news.

[pdimitar]

Question is: do you realize that Rust's `unsafe` is still not as unsafe as C without bound checks, double `free`-s, and others?

Point is, it's still an improvement. I am regularly amazed as to why that factually correct and (more and more) time-proven argument is always skipped when criticizing Rust.

[megous]

Yes, but do you realize you don't have to write C code without bounds checks? You can add your own.

[pdimitar]

No, I never would have imagined. /s

Point is, many don't do it. And they don't tell anyone. And they deploy important software. And then we get unpleasantly surprised years (or decades) later.

Same argument as with C++: proponents say that the modern C++ is almost like Rust which is cool and I am happy for them, but there are literal hundreds of millions of C++ coding lines out there that will never get upgraded. Having a cop-out like "yeah but the modern version is better" doesn't help legacy code.

Rust on the other hand is super strict for a long time now. They did the right thing.

[megous]

Sorry, I don't know any important C codebase that omits necessary bounds checks casually. Often times it would not even make any sense. (If you want to iterate over an array, you don't just iterate until infinity, lol.) String manipulation is often wrapped in functions that handle length/storage size/reallocation/etc in the background.

[pdimitar]

Nobody is saying they do it casually. People genuinely believe they are without fault, which leads to stuff like Heartbleed (and many others; from 2017 to 2020 there was a number of HN submissions about various well-known pieces of software having buffer under/over-flows).

I heard the ideal theory you cite, many many times. Yet many people still do mistakes. How does that fit in your world-view?

[Yoric]

Out of curiosity, do you know projects with C code and bounds checks?

[tialaramex]

Actually Unsafe Rust is arguably more fraught than C because the rules in Unsafe Rust are just as tough as they are in Safe Rust - much tougher than C - but in Safe Rust the language and libraries promise to take care of that, whereas in Unsafe that's on you. So choices which are in fact harmless in C will result in UB in Unsafe Rust.

The benefit is that unsafe passages of Rust are rarer and should be safely abstracted from APIs for use by Safe Rust. Mellisearch seems to often (but not always) provide safety rationales for unsafe code, explaining why whatever is done is OK. I don't understand this domain in enough detail to comment on the quality of the rationales.

[pdimitar]

Yes and no, unsafe Rust still holds a number of invariants, wherever if you just go on your own writing C you have zero.

I prefer the number of guarantees / invariants that's above zero.

[rockwotj]

I'm not criticizing Rust, I really like Rust and think it's great, along with the trend of more things written in it.

At the same time assuming you'll never get a memory issue is over the top.

[pdimitar]

Dunno, I think it should be clear for all experienced devs that the "never" part is still not achieved.

Personally though -- and in my work -- I'll take any improvement that I can. I am sick of reading about yet another important piece of software having yet another memory safety zero day pwnage bug.

[serverholic]

A little unsafe is better than all unsafe.