Rust is not a good C replacement • Hacker News Board

Re: Rust is not a good C replacement

#141

Post by KirinDave » Mon, Mar 25, 2019, 5:20 PM UTC

wyldfire wrote: post #53

Sir_Cmpwn wrote: post #28

Earlier quoted context omitted.

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.

It does sound a little snarky but at the same time it's a real good point -- the article says "... met with hostility from the Rust & Cargo teams" and yet you cite "largely based on this discussion [of some other team using Rust to develop their project]." So if this is an error on your part, maybe you could issue a correction without a specific comment or rebuttal from anyone. EDIT: your edit makes you seem a little…

It's a pretty wild world where someone makes a claim about an entire project charter based entirely off of a single random comment on github, and then the folks who claim that's wrong and cite project documentation are "the Rust Evangelism Strike Force," even in jest.

Re: Rust is not a good C replacement

#142

Post by picacho » Mon, Mar 25, 2019, 5:21 PM UTC

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…

in 90's single core golang probably won't be invented the way it is today :-p

Re: Rust is not a good C replacement

#143

Post by wyldfire » Mon, Mar 25, 2019, 5:22 PM UTC

KirinDave wrote: post #141

wyldfire wrote: post #53

Earlier quoted context omitted.

It does sound a little snarky but at the same time it's a real good point -- the article says "... met with hostility from the Rust & Cargo teams" and yet you cite "largely based on this discussion [of some other team using Rust to develop their project]." So if this is an error on your part, maybe you could issue a correction without a specific comment or rebuttal from anyone. EDIT: your edit makes you seem a little…

It's a pretty wild world where someone makes a claim about an entire project charter based entirely off of a single random comment on github, and then the folks who claim that's wrong and cite project documentation are "the Rust Evangelism Strike Force," even in jest.

I meant the HN comments section for this article as a whole. It went from very few comments to very many comments in a short amount of time.

Re: Rust is not a good C replacement

#144

Post by picacho » Mon, Mar 25, 2019, 5:33 PM UTC

from compiler's point of view, C++ doesn't really added that much features, and quite stable. imho i believe the C++ ISO committee does consider the possibilities compiler writers are able to implement these features. e.g lambda expression, there's always operator() overloaded available in C++98; Variable template, only allowed in namespace, aka. static member data member in template type; CTAD, take template function argument deduce mechanism and wrap-up for ya; auto, same as template argument, and C++'s template argument is the same as C's typedef, etc. that is to say, to some extend, C++'s features are also written in C++. The new idea could think of is the r-value type, which invented to trigger move constructor, again, using the existing function overloading mechanism to do the job. This maybe not engineering friendly which the writer has to manually nullify the moved object's internal pointers as for Rust just using type system to prevent you from using it.

Re: Rust is not a good C replacement

#145

Post by apta » Mon, Mar 25, 2019, 5:36 PM UTC

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…

Not to mention that segfaulting is if you're lucky. Otherwise, you run into undefined behavior and the code keeps running.

Re: Rust is not a good C replacement

#146

Post by apta » Mon, Mar 25, 2019, 5:39 PM UTC

jhasse wrote: post #81

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.

> 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. Aren't web browsers one of the most used consumer software today? I wouldn't call them niche.

The fact that GCC is now in C++ has to account for something :-)

Re: Rust is not a good C replacement

#147

Post by mjw1007 » Mon, Mar 25, 2019, 5:47 PM UTC

kibwen wrote: post #71

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.

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

I think Go and Swift are natural languages to compare Rust to in this respect. Both of them seem to be doing a much better job of reference-level documentation.

In other circumstances the Rust people generally aim for higher standards than "no worse than C or C++", let alone "no worse than C or C++ in the 1980s".

(I mean, you don't see Rust people saying "It took 30 years for C++ to get any form of type inference, so as long as we have something by 2040 we'll be on track.)

Re: Rust is not a good C replacement

#148

Post by edflsafoiewq » Mon, Mar 25, 2019, 5:51 PM UTC

TheCoelacanth wrote: post #119

skybrian wrote: post #110

Earlier quoted context omitted.

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

Borrow checking rules.

Re: Rust is not a good C replacement

#149

Post by _nalply » Mon, Mar 25, 2019, 5:57 PM UTC

It seems that the Rust community is already slowing down with new features. Have a look at "This Week in Rust" updates: the section "Approved RFCs" has the text "No RFCs were approved this week" almost every week now. There also was a discussion of designing 2019 as the fallow year and going more slow than before.

Re: Rust is not a good C replacement

#150

Post by jhasse » Mon, Mar 25, 2019, 5:59 PM UTC

Rusky wrote: post #137

jhasse wrote: post #72

Earlier quoted context omitted.

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

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.