Earlier quoted context omitted.
Oh no, no, no! Some people may reasonably, with some extreme care and diligence, maybe try to claim they can write safe and UB-free C code. If stars align properly. (See maybe SQLite. Seen as one of the pinnacles of crazy pedantism in C. Also, see the article about errors found recently in SQLite with fuzzing!) But with C++, it's just impossible for a human. It's too big, too quirky, too big, too wide, too deep, too…
Basically exception safety is a solved problem in Modern C++. If you use RAIIike it was meant to be used, exception safety is not that big a deal.
Why you should, actually, rewrite some of it in Rust
101–110 of 300 posts
Re: Why you should, actually, rewrite some of it in Rust
#102Sigh. This again. Not all security vulnerabilities are due to pointer arithmetic or out of bounds execution or pick-your-rust-is-better-idiom. Heartbleed is a great example. It wasn't caused by an error with how C handles memory or strings or anything else. It was caused by failing to validate untrusted input. Rust isn't going to help you with that. Could the affected parts be re-written in a way where the boundary c…
Sigh. This again. The Rust language is more than just memory safety. Memory safety is certainly the most prominent and unique feature of Rust, but the language also includes a lot of features that make writing good, bug-free code easier. For example: `Result`, when returned, forces all callees to check for errors. It's all too easy to throw away error codes in C/C++. This is probably one of the most important feature…
Warning is produced by nearly every good compiler. They aren't forced because sometimes I don't really want to check for return values.
> In C/C++ it's easy to build a switch for an enum, and then later when a new member is added to the enum and you forget to update all your switches.
why would you update all other enum values in accordance to addition to a new one? I understand you could possibly be skipping one switch case because you just added it in enum definition but didn't update switch case, but why would you update rest? Is this a forced requirement in Rust? This is bad if it is.
> Support for multiple return values (through tuples) means being able to avoid the nightmare of output pointer arguments to functions.
std::tuple?
> No NULL pointers.
but what if you need them? Lets say a type safe, non-zero nullptr? I understand some people want to bring up whole NULL is bad mistake argument but remember some of us work with maintaining large code where such changes are non-trivial.
> Unit testing built into the canonical tooling. Documentation testing built into the canonical tooling.
This is good argument :)
> The `Option` type, which lets you return "nothing". In C/C++ you'd have to return a bool, and again use a nightmarish output pointer argument.
std::optional? Or many other implementations of optional type? I've been using them since ages(before rust was even born) and writing them is no NP problem. Don't credit rust as if it brought the `Option` type.
> `OsRng` in the rand crate (go ahead, try to write a function that safely reads urandom in C).
Is this intended to be sarcasm? try header and see if it fulfills your requirement, otherwise there are tons of libraries. But wait, what? This is another already solved problem unless I'm missing something.
> No undefined behavior.
Lol do you even unsafe bro?
> C++ would require a whole set of classes, and require instantiating a new class every time I want to add a new cryptographic type. Rust only requires 3 lines per type.
Depends on your cpp skills and judging by this post, they're certainly less than expected from a beginner. I hope you learn about certain languages (even the ones you are defending) before writing things on internet, since 90% of what you wrote won't even come near acceptable so I suggest doing your research properly.
Re: Why you should, actually, rewrite some of it in Rust
#103Earlier quoted context omitted.
> As far as I can tell there's no major package manager accepting or even ready to accept programs written in Rust yet. Am I misinformed? At least Debian, Fedora, Arch, and Gentoo have rustc and cargo in their repositories. Oh and Alpine, recently. FreeBSD (IIRC) has it in ports. In the not-too-distant future, there's a pretty important package that will require Rust: Firefox. HEAD already does today.
For Debian at least, cargo isn't even in stable yet AFAIK. And even then, having the compiler and package manager available is a step along the way, but insufficient. Anything non-trivial depends on libraries, which with C programs are typically also packages... which for my project means I need to create 73 Debian packages to distribute my software. That's a big hurdle.
Debian has made a tool, "debcargo", to automatically turn crates from crates.io into Debian packages, so it should be "just run this tool." I have not used it myself though.
Re: Why you should, actually, rewrite some of it in Rust
#104Sigh. This again. Not all security vulnerabilities are due to pointer arithmetic or out of bounds execution or pick-your-rust-is-better-idiom. Heartbleed is a great example. It wasn't caused by an error with how C handles memory or strings or anything else. It was caused by failing to validate untrusted input. Rust isn't going to help you with that. Could the affected parts be re-written in a way where the boundary c…
Sigh. This again. The Rust language is more than just memory safety. Memory safety is certainly the most prominent and unique feature of Rust, but the language also includes a lot of features that make writing good, bug-free code easier. For example: `Result`, when returned, forces all callees to check for errors. It's all too easy to throw away error codes in C/C++. This is probably one of the most important feature…
* option and result are also available in C++, the former is even standardised.
* random numbers support is quite good.
* C++ compilers will warn if not all members of an enum have been handled in a switch. It's also easy to assert/throw in the default case as a safety measure.
* tuples are likewise supported
* I believe something like your opaque types could be done with templates and tag classes in a similar amount of LOC.
But yes, in Rust it's generally easier to do the right thing. This is the big benefit of learning from others' mistakes and not having to maintain backwards compatibility with ancient decisions.
Re: Why you should, actually, rewrite some of it in Rust
#105Earlier quoted context omitted.
For Debian at least, cargo isn't even in stable yet AFAIK. And even then, having the compiler and package manager available is a step along the way, but insufficient. Anything non-trivial depends on libraries, which with C programs are typically also packages... which for my project means I need to create 73 Debian packages to distribute my software. That's a big hurdle.
I thought it made the cutoff. I could be wrong. I was more worried about 1.15, which did get missed, ugh. Debian has made a tool, "debcargo", to automatically turn crates from crates.io into Debian packages, so it should be "just run this tool." I have not used it myself though.
Re: Why you should, actually, rewrite some of it in Rust
#106Why Rust? Why not Idris? Why not Haskell? Or you know, why rewrite it at all? You could instead try and use a safe C implementation (such as gcc/clang with the sanitisers or something like https://staff.aist.go.jp/y.oiwa/FailSafeC/index-en.html ), but to be frank if I was to rewrite my programs I would use a truly modern language like the ones that I mentioned above.
Or better, why not pascal? The HONEST question is because developers hate progress. We could have left in the past C/C++ by now, but not, is better to move forward with the same problems as DECADES ago. Rust is a potential contender because is not that far from C/C++, and have {}, and the last point is not even a joke. ----- Is weird to me why a clean fork of C/C++ was not made, if the prospect to move to something e…
Re: Why you should, actually, rewrite some of it in Rust
#107If you are really worried about the security of old C code, then the safest, most portable thing to do is re-write in modern C++. This is sane and doable in a short period of time. Rust is not.
Oh no, no, no! Some people may reasonably, with some extreme care and diligence, maybe try to claim they can write safe and UB-free C code. If stars align properly. (See maybe SQLite. Seen as one of the pinnacles of crazy pedantism in C. Also, see the article about errors found recently in SQLite with fuzzing!) But with C++, it's just impossible for a human. It's too big, too quirky, too big, too wide, too deep, too…
> Writing C++ code longer than a few lines without UB is humanly impossible.
Do you want me to provide one for you? Because that will definitely change your definition of 'humanly impossible' tasks and might also bring you back from realms of using comically bad phrases..
Re: Why you should, actually, rewrite some of it in Rust
#108If you are really worried about the security of old C code, then the safest, most portable thing to do is re-write in modern C++. This is sane and doable in a short period of time. Rust is not.
Oh no, no, no! Some people may reasonably, with some extreme care and diligence, maybe try to claim they can write safe and UB-free C code. If stars align properly. (See maybe SQLite. Seen as one of the pinnacles of crazy pedantism in C. Also, see the article about errors found recently in SQLite with fuzzing!) But with C++, it's just impossible for a human. It's too big, too quirky, too big, too wide, too deep, too…
Anybody who has the faintest clue about both languages should know that.
Re: Why you should, actually, rewrite some of it in Rust
#109Earlier quoted context omitted.
D? GC is optional so don't even :D
How much of the standard library works without GC enabled? How many community libraries do? D has a lot of great things (I am incredibly jealous of their metaprogramming facilities sometimes), but it doesn't seem like many people are successfully using it in the "fast and SAFE" sense as GP defined it.
Enough to be usable on virtually all platforms that rust is going to target in next 2 years. I hope I'll get proven wrong but that's it for now. And maybe along the time we'll see some decoupling of stdlib from GC too.
OTOH some people like GC too :)
Re: Why you should, actually, rewrite some of it in Rust
#110Earlier quoted context omitted.
I thought it made the cutoff. I could be wrong. I was more worried about 1.15, which did get missed, ugh. Debian has made a tool, "debcargo", to automatically turn crates from crates.io into Debian packages, so it should be "just run this tool." I have not used it myself though.
I think it's fair to say that anyone releasing software written in Rust on Debian right now has extra work to do, and is likely to be treading new ground.
Oh, I thought of something better than just the compiler: https://github.com/burntsushi/ripgrep#installation
* homebrew
* chocolatey
* arch
* gentoo
* fedora
* RHEL/CentOS
* Nix
All have at least one Rust program packaged :)