Live data from Hacker News

Why you should, actually, rewrite some of it in Rust

unhandledexpression.com

171–180 of 300 posts

Re: Why you should, actually, rewrite some of it in Rust

#171
post #106
post #77

Earlier quoted context omitted.

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…

Many clean forks of "C/C++" were made and they're all dead because apparently it's not so easy to do as you think.

Is not about being easy to do. Is that developers not accept them if not recreate all the same things that C/C++ have with the same good & bad, defeating the whole purpose.

Plus, this need a serious marketing push, and more than the work a few on them. Is each year harder and harder, similar to Cobol (where each year on drugs make you less likely to quit).

Now, the best hope is a painfully and too long gradual switch to rust or something else...

Re: Why you should, actually, rewrite some of it in Rust

#172

Earlier quoted context omitted.

That doesn't convert C to Rust. It compiles C into Rust as a target language, bugs and all. Raw pointers in C become raw pointers in Rust.

It doesn't provide any additional safety by itself, but it does provide a good starting point. Once you've Corroded your existing C code, you can then replace the unsafe Rust abstractions (like raw pointers) with equivalent safe ones (like references), one at a time. This way the manual part of the conversion doesn't have to be done all at once.

Is there anything that prevents this conversion of raw pointers to references from being automatable as well?

Re: Why you should, actually, rewrite some of it in Rust

#173

Sigh. 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…

Heartbleed came from allowing reads of uninitialized/out of bounds memory. Rust doesn't absolutely prohibit that, but it is an out of bounds memory access error. Python, Javascript, etc. catch that.

Re: Why you should, actually, rewrite some of it in Rust

#174

Earlier quoted context omitted.

https://github.com/jameysharp/corrode/

That doesn't convert C to Rust. It compiles C into Rust as a target language, bugs and all. Raw pointers in C become raw pointers in Rust.

Yeah I mean, compilers don't fix bugs. I don't know what you want. This is taking the "sufficiently smart compiler" idea to absurdity.

As part of an incremental re-write or port, this is still useful. It is extremely close to being able to straight-up cross compile CVS, for example.

Re: Why you should, actually, rewrite some of it in Rust

#175

Earlier quoted context omitted.

It doesn't provide any additional safety by itself, but it does provide a good starting point. Once you've Corroded your existing C code, you can then replace the unsafe Rust abstractions (like raw pointers) with equivalent safe ones (like references), one at a time. This way the manual part of the conversion doesn't have to be done all at once.

Is there anything that prevents this conversion of raw pointers to references from being automatable as well?

If C was able to encode Rust's semantics around references, you wouldn't need Rust in the first place.

You might be able to get it to work sometimes for a very simple subset. I'd be extremely skeptical that it'd be very useful, though.

Re: Why you should, actually, rewrite some of it in Rust

#176
post #148
post #139

As someone who really likes C and C++ I feel like the biggest reason for me not even thinking of Rust as a viable language right now is the community attitude. It seems so damn hostile to C and C++. Anyone who thinks C and C++ is viable is a misguided idiot, bad programmer, writing unsafe software, etc. to these people. Some badass below even just said that "writing C++ code longer than a few lines without UB is huma…

Show me the programming language community that's a fan of the language it's intending to supplant and we'll talk. :)

I've never seen Python or Lua community do that so far. But Python is its own animal (which IMO is only highlighting how good it is), it's not supplanting anything. Rust meanwhile both hates C and piggybacks on it (using LLVM, similar syntax, cited compatibility and coexistence with C). Lua is similar, no hate, its own animal, custom syntax, good in its niche (Python's niche seems to be literally everything not super performance critical BTW). Same for Erlang and Elixir, custom, different languages that are masters of their niche (and go see people gushing over these two on HN, they don't shit on other languages but say how good these are, no "Pfsshh, it's 2017, only idiot would write a reliable service in C, you can't program C ever, it's broken").

Re: Why you should, actually, rewrite some of it in Rust

#177

Sigh. 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…

I mainly agree that Rust is more than about safety. I just wish these other features had a tenth of the vocal support as Safety.

It's even worse here on HN, where the a certain group seem to thrive on blasting not-Rust, especially if that not-Rust is C or C++. I've seen comments to the effect that anyone writing in C or C++ today is literally acting with reckless indifference to life and safety. It's terrible.

Re: Why you should, actually, rewrite some of it in Rust

#178

Well Rust seems like a nice enough language if blog posts are anything to go by. But I really cannot unless we something like RustPython and Rython to replace CPython and Cython. (If anybody does write a new Python distribution on rust I named if first)

Someone has already done the honors:

    https://github.com/shinglyu/RustPython

Re: Why you should, actually, rewrite some of it in Rust

#179

Earlier quoted context omitted.

It doesn't provide any additional safety by itself, but it does provide a good starting point. Once you've Corroded your existing C code, you can then replace the unsafe Rust abstractions (like raw pointers) with equivalent safe ones (like references), one at a time. This way the manual part of the conversion doesn't have to be done all at once.

Is there anything that prevents this conversion of raw pointers to references from being automatable as well?

Rice's theorem.

That's an overly glib answer. The fully general form of this problem is undecidable, but it would be theoretically possible to build a "reverse borrow checker" that analyzes a Rust program, detects raw pointers that are provably used exclusively in ways compatible with Rust's lifetime semantics, and converts them to references. But it would probably be a fairly major project requiring lots of specialized knowledge, because lifetime semantics are complicated. Nobody has attempted it yet as far as I know, although the author of Corrode has expressed interest.

Re: Why you should, actually, rewrite some of it in Rust

#180
post #139

As someone who really likes C and C++ I feel like the biggest reason for me not even thinking of Rust as a viable language right now is the community attitude. It seems so damn hostile to C and C++. Anyone who thinks C and C++ is viable is a misguided idiot, bad programmer, writing unsafe software, etc. to these people. Some badass below even just said that "writing C++ code longer than a few lines without UB is huma…

In official Rust spaces, attacks like that are not allowed. We don't directly reference other languages in any official docs and such, to not promote this kind of attitude. It is true that we built Rust to address shortcomings of C and C++, some some form of crtitique has to happen. But many Rust programmers, and especially Rust leadership, will gladly say there's still some good reasons to write C and/or C++ today.…

There's critique (and I have lots towards both C and C++ but nothing fits my hobby better and all libs I like are in it and I know them the best so..) and there's just being downright stupid and insulting("stars aligning to write C", "humanly impossible to write C++", etc.).

In any case Rust is still solidly on my list of things to learn to become a T-shaped person with lots of insight from different angles but it's annoying to even be unable to skim through comments without seeing garbage, this doesn't happen that often, even the Java, C#, C, C++ quartet stopped going at each other's throats online a long long time ago and it's just skirmishes now and not a constant onslaught.

Post reply on HN