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

181–190 of 213 posts

Re: Rust is not a good C replacement

#181

Post by oconnor663 »

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.

A complete language description would need answers to all of the questions in, for example, this blog post: http://smallcultfollowing.com/babysteps/blog/2017/02/01/unsa...

Re: Rust is not a good C replacement

#182

Post by jhasse »

Rusky wrote: post #161
jhasse wrote: post #150

Earlier quoted context omitted.

Yes, I have used Eclipse and IntelliJ. Have you used cquery for example ( https://github.com/cquery-project/cquery )? In my experience performance is excellent and it can even be used with large code bases like Chromium. Accuracy is perfect since it uses the same information the compiler has.

Yes, as cquery's README states it has a huge memory overhead because it basically just builds the project and keeps the info around. This is rather like how Visual Studio's C++ IDE support used to work, and it was not fun to wait for re-indexing after making edits. Alternative Clang-based solutions reduce the memory overhead by doing more on-demand computation, more in line with how C# or Java IDEs work, at the cost…

My guess would be that in C# and Java, re-indexing is faster, because those languages have faster compile times in general. Therefore I would put this as a compile time problem.

> This also isn't a complete solution for accuracy, as it only really works if you're also building with Clang (or something close enough that Clang can emulate it).

Well that's a bit unfair, because we're talking about C++, not a GCC or MSVC extension to the language. And if there's some other compiler that isn't standard comformant, I wouldn't put this as a IDE support problem.

Of course there are cases were Clang fails to compile standard C++ code, but those are very rare.

Re: Rust is not a good C replacement

#183

Post by bb010g »

MuffinFlavored wrote: post #133
steveklabnik wrote: post #16

Earlier quoted context omitted.

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.

Rust has no particular built-in model for concurrency, but as soon as you want to do anything important with Rust (given the current ecosystem) you're going to run into Tokio, no? It seems to be the community-agreed-upon way to handle concurrency. Does Tokio use polling under the hood?

For the OP's microcontrollers, there's the excellent Real Time For The Masses: https://japaric.github.io/cortex-m-rtfm/book/en/

Re: Rust is not a good C replacement

#184

Post by bhaak »

bb88 wrote: post #177
bhaak wrote: post #98

Earlier quoted context omitted.

> It hasn’t completely replaced C The keyword here is completely . Rust doesn't need to completely replace C, it only needs to cover those usecases other languages haven't already covered. Or maybe just some and a completely different language takes what is left. You don't care that Rust is much more safe than C due to all the features it has that are unlike C. But the safety aspect is Rust's main raison d'être. If y…

> You don't care that Rust is much more safe than C due to all the features it has that are unlike C. But the safety aspect is Rust's main raison d'être. Rust is still young. I think it's a bit naive to proclaim the language of the future is here. Why? That was also the point of Ada until people realized that unhandled Constraint Errors could still crash missiles. https://itsfoss.com/a-floating-point-error-that-cause…

> Rust is still young. I think it's a bit naive to proclaim the language of the future is here.

I never claimed that Rust is the language of the future. I didn't say it directly but I think you can deduce it from my comments that I consider a multi language approach more sensible than using the same programming language for everything.

Using Rust is more safe than using C. That's valuable.

> So, what's the point of Rust again? To protect us from all these security holes? Wasn't that also the goal of other languages?

Are you saying that just because Rust doesn't solve all problems it isn't worth having? You're also conflating stuff.

The Ariane 5 explosion was not a programming error, it was a testing and specification error. The code worked exactly to the spec but the spec was for another piece of hardware. You can't use a fork and complain that it's not a good spoon.

How about quantifying the bugs in the JRE against all the buffer overflows in similar C code? 600 CVE worthy bugs in 10 years doesn't sound like that much if you put it that way.

https://www.cvedetails.com/product/19117/Oracle-JRE.html?ven...

> TIOBE says C is second most popular language after Java even with all the security holes. So there's a lot of "we" (though I don't code in C).

The TIOBE index has some issues. It is essentially counting hits for a search engine query for a specific language. I would rephrase it as "C has the second most webpages on the internet."

On PYPL it is only the 6th popular language, although coupled with C++.

Nevertheless there is still demand for C. Otherwise we wouldn't even have this discussion at all. But most people would rather see this demand decrease as we haven't been able to fix the language in the last 30 years.

Re: Rust is not a good C replacement

#185

Post by mjw1007 »

oconnor663 wrote: post #181
mjw1007 wrote: post #27

Earlier quoted context omitted.

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.

A complete language description would need answers to all of the questions in, for example, this blog post: http://smallcultfollowing.com/babysteps/blog/2017/02/01/unsa...

(That's about the underlying pointer-aliasing model visible to unsafe code; the sort of questions that come up with C's "restrict".)

I don't think coming up with answers to those questions need have blocked writing that part of the reference manual.

One alternative would be to document what aliasing guarantees rustc currently does and doesn't pass down to LLVM, along with what (if any) promises Rust is making about which things that therefore currently have defined behaviour at the LLVM level will also do so in the final language model.

The point is that the current reference manual should document the compiler-writers' current understanding of what is allowed.

Re: Rust is not a good C replacement

#186

Post by rhn_mk1 »

bluejekyll wrote: post #180
rhn_mk1 wrote: post #169

Earlier quoted context omitted.

There's a blog post diving more into the details of language cooperation from Meson's perspective here: http://nibblestew.blogspot.com/2019/02/why-is-cross-language...

Thanks for posting that. I understand what they’re getting at, but they didn’t quite convince me in the opening that this isn’t a build structure problem vs. a build tool issue. There’s a lot of work to do what they’re trying to achieve, and at best you’ll possibly get a faster build? Maybe it’s easier to configure? Though that also wasn’t obvious to me that there would be a large gain there.

There's another post explaining why Meson is trying to do what it is trying to do. My takeaway was that having a single universal build system is easier to deal with than multiple splintered ones, full of duplicated effort:

http://nibblestew.blogspot.com/2019/02/on-possible-futures-o...

Re: Rust is not a good C replacement

#187

Post by mjw1007 »

nimmer wrote: post #165
mjw1007 wrote: post #151

Earlier quoted context omitted.

I don't think they count as a "better C" for this purpose. I'm thinking of something aiming at the niche that C currently fills. Having a garbage collector doesn't fit that, and Nim doesn't look small (anything with both destructors and exceptions is getting into complications rather beyond C).

Regardless, I use Nim when I need the performance and memory footprint of C. GC is optional.

Right, that's exactly the « it would be hard to compete against the alternative of using a small subset of {whatever} » case.

Re: Rust is not a good C replacement

#188

Post by notacoward »

WallWextra wrote: post #18

You don't have to care about memory safety, but if you don't you probably shouldn't speak for "systems programmers" as a whole. Systems need to be safe.

Thank you for that. Now that you've stated it so concisely, I can see how this is the thing that bothered me about the post. The author is implicitly trying to represent the C user base but doesn't seem to share that user base's concerns, priorities, or practices.

Re: Rust is not a good C replacement

#189

Post by glangdale »

adamnemecek wrote: post #35
xiphias2 wrote: post #25

Earlier quoted context omitted.

The main problem with C++ are not the new features, but the old obsolate ones. It's too late to fix the language.

Also their development process is too slow. Like it would be impossible for me to pitch a new feature to cpp. I can imagine adding a new feature to rust (not that I would but I like that there’s the option).

I'm appreciating the irony of you complaining that "C++ features don't work together" but also saying that the process of putting new features into C++ should be faster. :-)

Re: Rust is not a good C replacement

#190

Post by village-idiot »

Sir_Cmpwn wrote: post #28
steveklabnik wrote: post #13

Earlier quoted context omitted.

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

I'm offering you an olive branch here. You can pile on the snark, or you can take my offer to issue a correction to my article. Edit: found the hostility. Fine, I won't issue a correction. I didn't find Steve's arguments entirely correct and I was willing to add a note to the page letting him share his perspective so the reader could make up their mind. Now I'm less open to that.

This is a very bad look, actively looking to punish others because they didn’t “accept your olive branch” after pointing out a mistake. I’d recommend you rethink your approach here.
Post reply on HN