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

161–170 of 213 posts

Re: Rust is not a good C replacement

#161

Post by Rusky »

jhasse wrote: post #150
Rusky wrote: post #137

Earlier quoted context omitted.

There have been improvements for sure, but have you used a good Java or C# IDE? C++ support is still far behind in terms of performance and accuracy. (I work on a C++ IDE.)

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 of much higher latency because Clang is not designed for anything but batch compilation.

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

Like I said, things have improved for C++, but it's nowhere near what other, more IDE-friendly, languages can do.

Re: Rust is not a good C replacement

#162

Post by taco_emoji »

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.

Why is it someone else's responsibility to correct your article? You based your accusation of hostility on hearsay, it's on you to correct that error.

Re: Rust is not a good C replacement

#163

Post by Manishearth »

sseagull wrote: post #92
jabl wrote: post #39

Earlier quoted context omitted.

> What's the roadmap for reducing the number of security flaws in C software? Thoughts and prayers.

A little controversial, but I would have liked the larger programming community to address this rather than write completely new languages. Think of all the effort that has gone into rust. Compilers, package managers, libraries, etc. What would have happened if that same effort went into better analyzers, linters, compilers, etc, for C/C++? Rather than rewriting everything to be made "perfect" (which will never happe…

As someone who has dabbled in the C++ program analysis space before: A _ton_ of effort has gone into this already. There's also a lot of promising stuff there already.

There's active research on how to best do aliasing/pointer analyses, both for optimizers and for linters.

I've often said that the holy grail of C++ program analysis is aliasing info that is perfect, local, and can be computed in a reasonable time. The current situation on this is basically "pick one", _sometimes_ "pick two" if you're good. Rust's design gets you all three by picking different defaults and asking for some extra annotations from the user. The kicker is: it's all based on existing research!

Firefox has its own static analysis and IIRC has looked into other static analysis stuff (the GC analyses are pretty awesome). C++ static analysis is good, but not good enough, in this case at least.

Re: Rust is not a good C replacement

#164

Post by cogman10 »

nicoburns wrote: post #33

I agree with the overall conclusion. Zig is aiming at being a C replacement. Rust is very much more in the C++ space. But a lot of the individual points seem off the mark. > Concurrency is generally a bad thing. A program which uses poll effectively is going to be simpler, reasonably performant, and have orders of magnitude fewer bugs. One of the benefits of Rust is that provides a lot of checks on concurrent code to…

> One of the benefits of Rust is that provides a lot of checks on concurrent code to prevent you doing stupid things

Well, here's the kicker. Nothing about rust forces you to use concurrency. Saying "Concurrency is bad, therefore rust is bad" makes no sense. There is nothing that forces you to spin off new threads in rust, just as there is nothing that forces you to spin off new threads in C.

In fact, it is pretty rich complaining about Rust's concurrency story while praising Go. A HUGE selling point to go was/is goroutines! The language was even given keywords for making concurrent actions!

Re: Rust is not a good C replacement

#165

Post by nimmer »

mjw1007 wrote: post #151
chessturk wrote: post #128

Earlier quoted context omitted.

I'm curious if you consider Nim or Golang to be a small language that is a "better C". If not, why?

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.

Re: Rust is not a good C replacement

#166

Post by cogman10 »

edflsafoiewq wrote: post #148
TheCoelacanth wrote: post #119

Earlier quoted context omitted.

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

Borrow checking rules.

I don't know what the current state of affairs is, but this is something they have rightly delayed specing. The original borrow checking rules were quite byzantine compared to what we have today.

I don't know if there is active work going towards making them more relaxed (NLL landed I believe). However, a ton of work has happened to get them out of the way as much as possible.

Re: Rust is not a good C replacement

#167

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

#168

Post by nickez »

7e wrote: post #127

Should the HN rules be amended to discourage self-authored submissions? They seem to circumvent the natural filter that comes with peer-nomination, and suggests they were written with promotion in mind.

I thought you had to write "Show HN:" when you were publishing your own content..

Re: Rust is not a good C replacement

#169

Post by rhn_mk1 »

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…

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

Re: Rust is not a good C replacement

#170

Post by grzm »

nickez wrote: post #168
7e wrote: post #127

Should the HN rules be amended to discourage self-authored submissions? They seem to circumvent the natural filter that comes with peer-nomination, and suggests they were written with promotion in mind.

I thought you had to write "Show HN:" when you were publishing your own content..

> ”Blog posts, sign-up pages, and fundraisers can't be tried out, so they can't be Show HNs.”

https://news.ycombinator.com/showhn.html

Post reply on HN