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

111–120 of 213 posts

Re: Rust is not a good C replacement

#111

Post by bhaak »

solarkraft wrote: post #69
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…

> But nowadays it already feels outdated on arrival Why? What do you prefer?

That's certainly an opinionated opinion but Go feels like dragging C half-way to the 21st century. But unfortunately not all the way.

Besides the very good concurrency support it doesn't feel much different than a polished and somewhat modernized C.

Of course, depending on what you want that will be considered a feature not a bug. There's a reason so many C programmers jumped on it because even hardcore C programmers couldn't really ignore the language anymore.

Also look at the project management. The drama about the package manager was hilarious bad PR. I wouldn't want to invest too much time into a programming language that can't even agree on a package manager and needs 4 different tries to arrive at a solution with potential security implications.

Re: Rust is not a good C replacement

#112

Post by sevensor »

My biggest quibble with the article is the idea that C will have a replacement. Many languages have already replaced C, in many domains. And yet C is still with us. I suspect it will remain indefinitely, shrinking in relative popularity but growing in the absolute sense. If for no other reason than that every language benefits from having a way of talking to libraries written in other languages, and the lingua franca is C. Rather than writing N^2 foreign function interfaces for N languages, each language can have one FFI library targeting C interoperability.

Re: Rust is not a good C replacement

#113

Post by steveklabnik »

bluejekyll wrote: post #94
steveklabnik wrote: post #80

Earlier quoted context omitted.

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…

Well, then the comment they made about essentially rewriting Cargo is probably accurate. Doesn’t seem like it’s a valuable contribution to their end goal though. I do want to point out (for others, you know this) that Cargo has a lot of environment variables that can be used to improve its usage inside other build systems, e.g. using a shared target directory for reusing compilation of dependencies: https://doc.rust-…

Right, that's why we introduced the build plan feature, so that you don't have to re-implement Cargo, you can use Cargo to spit out the stuff you need instead. :)

Re: Rust is not a good C replacement

#114

Post by wyldfire »

Thaxll wrote: post #103
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…

This is an OS problem, Rust won't save you there because you're going to use unsafe anyway, in Rust you would create wrappers for the unsafe part, they probably do the same in C/C++ for OS, you don't use unsafe / low level things for higher part of the OS. Redox is an OS written in Rust and had kernel panic with bad arguments passed to a user space program so ... ( it was a community challenge from 2 years ago ) I th…

> you're going to use unsafe anyway ... you don't use unsafe / low level things for higher part of the OS

It seems as if you contradict yourself here. Or are you trying to suggest that Microsoft's bugs were confined to the "lower part of the OS"?

> so ...

So, what, exactly? Your point is not clear. Redox used Rust and held a challenge to find bugs in Redox -- which was succesful at uncovering bugs in Redox. Ergo, what? "memory bugs still exist when programming in Rust"? Or "We haven't completely extinguished this kind of bug, therefore we haven't improved over C." It sounds bogus when I try to guess at what you're implying, so please clarify.

The whole unsafe escape hatch was designed to imbue the flexibility required to cover the design scope required for system software. Don't fault Rust for adding it. Credit Rust for Redox's stability after they did this challenge.

Re: Rust is not a good C replacement

#115

Post by steveklabnik »

skybrian wrote: post #110
steveklabnik wrote: post #83

Earlier quoted context omitted.

> Why couldn't the Rust team maintain a spec and keep it up to date by changing it in the same pull request that changes a language feature in the compiler? This seems like mostly a matter of discipline. It's not that, it's that we take the idea of a spec very seriously. We want to have a spec that's extremely solid, and so there's a lot of foundational work that needs to be done first. That work has been ongoing. No…

Okay, but this seems like letting the perfect get in the way of the good? A maintained, readable, informal spec should be quite useful as a starting point for writing a more formal spec later. It need not be definitive. It would be quite reasonable to point out areas that aren't nailed down yet - this is also useful for the reader.

That's what the reference is, and it's there for exactly that purpose.

Re: Rust is not a good C replacement

#116

Post by wglb »

iheartpotatoes wrote: post #54

You can't overstate the importance of a specification. It is the most loathed thing to write, like unit tests, but in the end is essential. I think the OP romanticizes a bit: K&R C had a spec, a very very very loose spec. It took ANSI a decade to put some meat on it. Early C compilers weren't much help: Sparc had SystemV and AIX had POSIX which are OS specs but still defined C behavior in their compilers, and it made…

K&R C had no formal spec. It wasn't until 10 years after its invention that it did, and that was after a lot of real-world experience.

I would argue that early specifications don't work out very well. In fact, they are often problematic. One example is that standard ANSI C had a proposal for a while that included an Alias keyword. This was such a bad idea, that Dennis Ritchie showed up to the meeting personally to help kill it.

Standards committees are not usually staffed with practitioners, who are busy developing the language and are quite expert in nuance, feasibility, and utility. Attendees to standards committee meetings are almost always not.

And reality does meet the standardization expectations quite frequently. Look at the number of "undefined" or "implementation choices" in C alone. Therein lie careers for security folks.

Re: Rust is not a good C replacement

#117

Post by chessturk »

Sincere question, I didn't realize that Rust didn't have a specification. How can folk say Rust guarantees safety when it doesn't guarantee an implementation? I don't see how you could have one without the other.

Now, admittedly, the lowest level language I've used is Go!, so fairly abstracted (and no memory management), so I might be mistaken, but it doesn't seem like you can have safety without a specification.

Re: Rust is not a good C replacement

#118

Post by orwin »

timw4mail wrote: post #91
ddevault wrote: post #64

Earlier quoted context omitted.

>This is a function of popularity and time. Correct, both of which you have to take into account when picking a programming language today . >We have to take the good with the bad in everything, right? If Rust's future is "spectacular failure like C++" then it's probably going to be a wild success. I wouldn't call C++ a wild success. It's failed to supplant C for its entire life, and thrives only in a few niches.

A few niches? Every major GUI application and video game is niche?

i disagree with the main article, but he is right. C++ was supposed to be more than just browsers, GUI and video games: it shuold have been a better C. It failed. It was supposed to be more secure than C. It failed.

Mostly the OOP failed part, because it wasn't that good of an idea (usefull in some case, to do geometry and grapic stuff, and for other, specific cases). And Java's "everything is an object" did not help C++, with countless students trained on Java then writing software with C++ and doing awfull things everywhere. C++15 is really fun to work with in new, clean projects, with either new or very ancient C++ devs, but i would get away from any proposition including a pre-2013 C++ codebase and any "rockstar"/"genius" C++ dev with 2-10 years of C++ experience as a lead.

And by the way, nowadays python and Js replaced C++ in the GUI usecase (yes, electron is written with C++, this is not my point).

Re: Rust is not a good C replacement

#119

Post by TheCoelacanth »

skybrian wrote: post #110
steveklabnik wrote: post #83

Earlier quoted context omitted.

> Why couldn't the Rust team maintain a spec and keep it up to date by changing it in the same pull request that changes a language feature in the compiler? This seems like mostly a matter of discipline. It's not that, it's that we take the idea of a spec very seriously. We want to have a spec that's extremely solid, and so there's a lot of foundational work that needs to be done first. That work has been ongoing. No…

Okay, but this seems like letting the perfect get in the way of the good? A maintained, readable, informal spec should be quite useful as a starting point for writing a more formal spec later. It need not be definitive. It would be quite reasonable to point out areas that aren't nailed down yet - this is also useful for the reader.

What do you want out of an informal spec that isn't provided by "The Rust Reference"[1]?

[1] https://doc.rust-lang.org/reference/index.html

Re: Rust is not a good C replacement

#120

Post by wglb »

GhotVeren wrote: post #36
fxfan wrote: post #21

If OP thinks Firefox is one of the largest C++ codebases in the world then OP has a very limited worldview.

That's true though, as far as the open source projects go. Only bigger C++ open source codebase I can think of is LLVM. What else did you have in mind?

Er, firefox is reported to have 12 million, while llvm has 2 million. gcc is 7 million.
Post reply on HN