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

Rust is not a good C replacement

drewdevault.com

Post reply on HN
Print view View original

11–20 of 213 posts

Re: Rust is not a good C replacement

#11

Post by beders »

> Safety. Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows. I especially refuse to “rewrite it in Rust” - because no matter what, rewriting an entire program from scratch is always going to introduce more bugs than maintaining the C program ever would.

And that is why we can't have nice things.

"I don't really care" if someone overflows my buffer to execute code...

And: "going to introduce more bugs" - false. Empirically complete bollocks...

Re: Rust is not a good C replacement

#12

Post by rwj »

The current pace of development of C++ is questionable, but Rust is still a fairly young language, so the comparison to C seems unfair. Presumably, the rate of change in Rust will slow down. Although, if you are looking for stability today, the point does stand.

Re: Rust is not a good C replacement

#13

Post by steveklabnik »

ddevault wrote: post #4
steveklabnik wrote: post #2

There's a lot of stuff I could say here, but I'll stick to > Attempts to integrate it with other build systems have been met with hostility from the Rust & Cargo teams. This is very much not true. We've put in a ton of work to support this. Arguably, we've put in too much design work and not enough implementation work; we've had a few different attempts at making this work even better than it does today, and we haven…

Thanks for sharing your perspective. My comment was largely based on this discussion: https://github.com/mesonbuild/meson/issues/2173 If you'd like to share a short summary of your thoughts, I'll update the article with your commentary.

I would suggest not taking comments on random github threads as the position of a completely different project.

Re: Rust is not a good C replacement

#14

Post by gvx »

This reads like a rant about screwdrivers being terrible hammers.

By the way, there is a lot of polyglot library code out there that is both valid C and C++, which is the reason for using "C/C++" much of the time.

Re: Rust is not a good C replacement

#15

Post by xiphias2 »

,,Concurrency is generally a bad thing''

Easy speedup of processors ended. Not using system resources efficiently is not sustainable long term. Mozilla created Rust to be able to use the multi-core hardware (especially on mobile phones), thereby improving battery usage as well for rendering web pages.

Rust has it's C++ style problems (compiling time, not good enough IDE support), but the dev team knows about them, and hopefully improve them in the next years.

Re: Rust is not a good C replacement

#16

Post by steveklabnik »

MuffinFlavored wrote: post #10
Symmetry wrote: post #5

Concurrency might be a dangerous thing but in microcontroller land, where I do my C programming, interrupts are a fact of life and just polling really isn't a practical solution.

Is that how Rust concurrency works under the hood? Polling?

Rust has no particular built-in model for concurrency or threading. The standard library currently exposes system threads, and we’re working on providing an API for pluggable concurrency models. The most popular of which is a wrapper around epoll/kqueue/iocp.

Re: Rust is not a good C replacement

#17

Post by joshdover »

Most of the author's points here derive from the fact that C has been around for nearly 50 years and Rust a mere 8. This post should really be titled "Rust is not a good C replacement _right now_".

Yes, Rust still has a long way to go to be the right tool for all the things you can do with C today, but that doesn't make it less. It clearly has benefits when writing concurrent and safe code. You pay for this with a learning curve, but the Rust team has been shaving this curve down through better tooling and documentation for the past few years.

> Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows.

I suspect that for the author's work, these things may not matter much. But to a programmer working on any software where security is paramount (many web infrastructure pieces), this feature is golden.

I expect that as Rust matures, we'll see a solidified spec, competing implementations, and expanded build tooling. C has a long head-start, not to acknowledge that is just wrong.

Re: Rust is not a good C replacement

#20

Post by epage »

steveklabnik wrote: post #2

There's a lot of stuff I could say here, but I'll stick to > Attempts to integrate it with other build systems have been met with hostility from the Rust & Cargo teams. This is very much not true. We've put in a ton of work to support this. Arguably, we've put in too much design work and not enough implementation work; we've had a few different attempts at making this work even better than it does today, and we haven…

Does build-plan help with the case of including an artifact from another build system (e.g. data file for code-generation like SVD or libs to link against)? What about someone not using build-plan but publishing crates, whether external or internal?

Speaking of, alternative crate indexes are something I think we need to do at some point for improved corporate support. It'll be interesting to explore the requirements. Some I can think of include

- Publish internal-only crates - Some companies might want purely internal mirroring (for secured systems) - Some companies might want a read-through cache to self-host what they use (for life-cycle management) - Some companies might want to exclude crates (for extra-cautious licensing validation) which could make it hard to use anything unless we can also transitively exclude things

Post reply on HN