Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

unhandledexpression.com

Post reply on HN
Print view View original

141–150 of 300 posts

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

#141

Post by CalChris »

pornel wrote: post #116

I've been programming in C for 17 years. Now I'm writing (and rewriting) image processing and encoders in Rust and I love it. It's not just memory safety. Rust has sweet error handling — the syntax is almost as noise-free as exceptions, but code flow is as predictable as error codes. In Rust I handle rare error cases that I wouldn't have bothered with in C (and thus my Rust programs fail in orderly fashion instead of…

> the syntax is almost as noise-free as exceptions

No.

const USAGE: &'static str = "usage string";

I did rewrite it in Rust. I rewrote a small low level command line app in Rust. I really wanted to like Rust going in but I freaking hated it going out. They had a few good ideas but they never knew how to say no. The part I hated the most was the Rust macro language. And for real low level to the metal systems programming, everything is unsafe; so you may as well be writing in C.

Go is pretty minimal. They knew how to say no. I like modern C (C99 and C11). It has most of the good ideas from C++.

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

#142

Post by Animats »

The trouble with mixing Rust and C/C++ is that you tend to get Rust with C/C++ unsafe pointers. Most of the examples of this pass C raw pointers into rust, Rather than passing a Rust Vec into C. Or even passing STL strings and vectors into Rust. So, instead of passing Rust's array size information into C, they propagate C's lack of size information into Rust. Typical example: [1]

    pub extern "C" fn count_substrings(value: *const c_char, substr: *const c_char) -> i32
If you incrementally convert from C/C++ to Rust, you end up with those constructs in the final Rust program. Not good.

[1] http://siciarz.net/24-days-of-rust-calling-rust-from-other-l...

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

#143

Post by vvanders »

_dcwr wrote: 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…

I think you see some of that since quite a few people have spent decades in C/C++(myself included) and have had exposure to experiencing these exact problems.

I'm still a huge fan of C++ but Rust gets me to where I want to go with C++ with much less fuss and a lot more confidence.

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

#144

Post by dsacco »

_dcwr wrote: 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…

For what it's worth, while I agree that there is a vocal minority within the Rust community that can be militant this way, it's not an official position, and it's explicitly not endorsed by the Rust core dev team.

Personally, I'm considering C++ for a new software project despite my extensive background in security. I think Rust is a great language, I just don't have much interest in it.

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

#145

Post by steveklabnik »

_dcwr wrote: 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. Many of those reasons will still be around for a very long time.

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

#146

Post by fuwafuwa »

bandook_raja wrote: post #102
fpgaminer wrote: post #75

Earlier quoted context omitted.

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…

> It's all too easy to throw away error codes in C/C++. 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…

Your comment indicates that you don't really understand the value of ADTs as the switch, option type and NULL pointer comments overlap: in your new code(and it would be be new code since it's rewritten in Rust) you define it to have Some(pointer) or None. Then to access the value you have to switch on and evaluate the None case at any dereference site. NULL cannot happen but you can still pass around a None type.

Regarding safely reading urandom, you don't seem to be aware that concurrency issues occur when accessing it from multiple processes. This is something that the borrow system can aid with by formalizing access to a resource like urandom and not allowing contention for it to occur at runtime.

Also, nobody appreciates aggro kid language.

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

#147

Post by steveklabnik »

CalChris wrote: post #141
pornel wrote: post #116

I've been programming in C for 17 years. Now I'm writing (and rewriting) image processing and encoders in Rust and I love it. It's not just memory safety. Rust has sweet error handling — the syntax is almost as noise-free as exceptions, but code flow is as predictable as error codes. In Rust I handle rare error cases that I wouldn't have bothered with in C (and thus my Rust programs fail in orderly fashion instead of…

> the syntax is almost as noise-free as exceptions No. const USAGE: &'static str = "usage string"; I did rewrite it in Rust. I rewrote a small low level command line app in Rust. I really wanted to like Rust going in but I freaking hated it going out. They had a few good ideas but they never knew how to say no. The part I hated the most was the Rust macro language. And for real low level to the metal systems programm…

As of the most recent release, that's now

    const USAGE: &str = "usage string";
and there's talk of maybe making it

    const USAGE = "usage string";
> The part I hated the most was the Rust macro language.

We don't like it either; there's a replacement coming. We reserved the "macro" keyword before 1.0 and made the current one use the less-good "macro_rules" to help ease the eventual transition.

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

#148

Post by moomin »

_dcwr wrote: 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. :)

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

#149

Post by stusmall »

_dcwr wrote: 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…

I see attitude like that a lot on hacker news, but never see it on the rust user forums or IRC and rarely in rust related twitter. I can only speak for what I've seen personally but it seems to have more to say about hacker news comment sections than the rust community itself.

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

#150

Post by _ph_ »

w8rbt wrote: post #5

If 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.

As long as it possible to run the same old C code inside your "modern C++" rewrite, you might have ported the security holes to C++. The problem is, C++ is far to compatible to C here. The idea of all "safe" modern languages is, that unsafe constructs are simply not allowed by the compiler. Why not let the compiler do the checking work vs. hoping that the human programmer didn't miss a check?
Post reply on HN