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

71–80 of 213 posts

Re: Rust is not a good C replacement

#71

Post by kibwen »

mjw1007 wrote: post #27
jonathanstrange wrote: post #6

Lack of a formal specification and/or an international standard is the real bummer. That's the biggest disadvantage in comparison to languages like Ada and C.

At this stage I'd settle for an informal language description, as long as it was a serious attempt to be basically complete and correct. It's nearly four years since Rust 1.0 and the reference manual is still calling itself a best-effort document. It's surprising that a project which generally holds itself to high engineering standards is so sloppy in this one area.

> It's nearly four years since Rust 1.0 and the reference manual is still calling itself a best-effort document.

I'm curious what standard this is holding Rust to; C was 17 years old when a comprehensive reference emerged, and C++ was 13 years old for the same. If Rust manages to have a reference by 2030 (and I certainly hope it does) then it will be on track.

Re: Rust is not a good C replacement

#72

Post by jhasse »

xiphias2 wrote: post #15

,,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, an…

> Rust has it's C++ style problems (compiling time, not good enough IDE support), [...]

Actually, since language servers like clangd, cquery and ccls, IDE support is not a C++ style problem anymore.

Re: Rust is not a good C replacement

#73

Post by steveklabnik »

epage wrote: post #20
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.…

build-plan is meant to be able to expose to an external build system the stuff that Cargo would want to build; it's not meant to talk about artifacts from other build systems. It's meant to help Rust fit in there, not to control other parts of the build.

> Speaking of, alternative crate indexes are something I think we need to do at some point for improved corporate support.

Absolutely! We accepted an RFC here, and there's an unstable implementation https://github.com/rust-lang/rfcs/blob/master/text/2141-alte...

Re: Rust is not a good C replacement

#74

Post by adrianN »

mediocrejoker wrote: post #56
clouddrover wrote: post #8

> But now you know why we are still writing C, and hopefully you’ll stop bloody bothering us about it. I don't think anyone will stop bothering them about it until C software security improves. Microsoft found that 70% of security bugs in their software were memory safety issues: https://www.zdnet.com/article/microsoft-70-percent-of-all-se... Languages like Rust are making an effort to address these issues. What's th…

I know the kernel is not the C language, but I think the efforts being undertaken to harden the kernel (use of syzkaller, etc) provide a good roadmap for C programs in general. https://lwn.net/Articles/763641/

The Chrome team is working really hard to secure their program. They're also really good engineers. Yet there are still lots of memory corruption bugs in Chrome. That makes me believe that it's impossible to write safe C++ once your code is sufficiently complicated. I don't think C fares any better on that front.

Re: Rust is not a good C replacement

#76

Post by jhasse »

marricks wrote: post #50

> 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. Are they advocating for never rewriting anything? Like, programming language advancement sho…

Most programming languages can call C code, so you don't have to rewrite something when switching to them.

Re: Rust is not a good C replacement

#77

Post by [deleted] »

beders wrote: post #11

> 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 buf…

[deleted]

Re: Rust is not a good C replacement

#78

Post by michaelt »

jimmy1 wrote: post #42
beders wrote: post #11

> 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 buf…

I would say if you rewrite it and have more bugs, you must have no understanding of the existing codebase, or understand so little of it you shouldn't be the one rewriting it regardless. All the rewrites I have done have resulted in leaner codebases with fewer potentials for bugs. I think people take some article one software developer wrote almost two decades ago as gospel, but "second system syndrome" doesn't have…

I guess you disagree with the likes of [1] then. Presumably it depends on the age and complexity of your project.

[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Re: Rust is not a good C replacement

#79

Post by empath75 »

bhaak wrote: post #30

The main fallacy of this blog post is that he wants it to be one single programming language that replaces C. C has actually been already replaced mostly. C++, Java, C#, Python, Ruby, Go, Rust, etc. have been chipping away for more than 20 years now at C's market share. What kind of project can you seriously start today in C because there are no better options available? My guess is embedded programming and kernel pr…

I like that go feels sort of quaint and outdated. It makes it easy for pretty much everyone to jump in and contribute to a code base without having to learn too much. Rust is great, but it is not a language you can just jump into.

Re: Rust is not a good C replacement

#80

Post by steveklabnik »

bluejekyll wrote: post #46
ddevault wrote: post #4

Earlier quoted context omitted.

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 didn’t read the entire thread, but if I understood the gist of it, it seems like an anti-pattern is being asked for, and it would be an anti-pattern when mixing any languages. What it seems they want is the ability to mix Rust and C in the same build chain, not treat each as a separate build artifact and link at the end. I’ve never had a problem modeling things with Makefiles, having the Rust artifact target be bui…

Yes, there's a ton of ways that you can do this. Most successful integrations thus far have done exactly that: you have a target for your Rust code, it calls out to Cargo and does its thing, and then links it in. I believe that you're right that the Meson folks want to use rustc like they use cc, and use Meson for all of the stuff that's not "compile this, please."

This can work well as long as you're writing all of your own code. The issue is that most people like Cargo, and like using Cargo, and so virtually all open-source projects are built around Cargo. This is not unlike if you're a Meson fan, but you want to use an open source project that uses CMake for its build, and so it's only really set up to use CMake. (At least, in my understanding.)

Post reply on HN