15 ms·

Rust is not a good C replacement

148 points by ddevault 8y ago

wyldfire 8y ago
Meta: feel free to flag or downvote this post. Please do not downvote Sir_Cmpwn just because you disagree with what they've written. Instead, please try to formulate a rebuttal comment here or your own blog post.
adamnemecek 8y ago
OK looking Just at the number of features seems disingenuous. Cpp features tend to idk, increase the level of complexity as there tends to be quite a bit of friction between them. Rust features definitely “work together”. This post seems to have started with a conclusion and worked backwards. Rust is such a breath of fresh air. Cargo is nuts. The community is nuts. I’ve been writing rust full time for a couple of months now and I’m not going back.
- xiphias2 8y ago
  The main problem with C++ are not the new features, but the old obsolate ones. It's too late to fix the language.
  - adamnemecek 8y ago
    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).
    - sseagull 8y ago
      But isn't this how you end up with a 'bloated' language? Everyone has their own corner case, own little way the language can be improved. Over time, these will inevitability burden a language. Adding features becomes necessarily bureaucratic as languages mature. You can't just add/change stuff without seeing how it interacts with everyone else, which gets difficult as languages grow and become popular.
      - adamnemecek 8y ago
        That depends on how these features are added. https://github.com/rust-lang/rust/blob/master/RELEASES.md https://github.com/rust-lang/rust/blob/master/RELEASES.md I would argue that cpp, despite being much older, is still adding features that are kinda backbreaking e.g. ranges.
    - glangdale 8y ago
      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. :-)
      - adamnemecek 8y ago
        There's nothing ironic about that. If they had a shorter feedback loop, things could be getting fixed faster.
  - xiphias2 8y ago
    I'm not sure why I'm being downvoted...I'd love to have an explanation from that person of how much diamond inheritance benefits our lives and makes it so much simpler to write maintainable code.
steveklabnik 8y ago
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't finished them up. But this is very much something that is cared about and desired by the team. It was literally on the 2017 roadmap: https://blog.rust-lang.org/2017/02/06/roadmap.html https://blog.rust-lang.org/2017/02/06/roadmap.html > Rust should integrate easily into large build systems. Plans include working with large companies incorporating Rust to understand how best to equip Cargo to smooth the process. I don't know how this is framed as "hostility". As one example of the work done here: https://github.com/rust-lang/cargo/issues/5579 https://github.com/rust-lang/cargo/issues/5579
- ddevault 8y ago
  Thanks for sharing your perspective. My comment was largely based on this discussion: https://github.com/mesonbuild/meson/issues/2173 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.
  - steveklabnik 8y ago
    I would suggest not taking comments on random github threads as the position of a completely different project.
    - Sir_Cmpwn 8y ago
      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.
deleted 8y ago
[deleted]
Symmetry 8y ago
Concurrency might be a dangerous thing but in microcontroller land, where I do my C programming, interrupts are a fact of life and just polling really isn't a practical solution.
- MuffinFlavored 8y ago
  Is that how Rust concurrency works under the hood? Polling?
  - steveklabnik 8y ago
    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.
    - MuffinFlavored 8y ago
      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?
      - steveklabnik 8y ago
        There are a number of different options. And today, yes, code is tied to one of them. But, and it’s not stable yet, futures and executors, the two traits, are being added to the standard library. This lets your code be generic over executors, and there are already more than just tokio. Including an embedded one, for example. Tokio wraps epoll/kqueue/iocp.
        MuffinFlavored 8y ago
        > But, and it’s not stable yet, futures and executors, the two traits, are being added to the standard library. Is this implementation going to wrap epoll/kqueue/iocp? Would you say Tokio has any drawbacks/flaws/design choices yo aren't a fan of? What are the popular choices other than Tokio?
jonathanstrange 8y ago
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.
- mjw1007 8y ago
  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.
  - kibwen 8y ago
    > 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.
    - mjw1007 8y ago
      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.)
  - steveklabnik 8y ago
    I wrote a comment about this over here: https://news.ycombinator.com/item?id=19483241 https://news.ycombinator.com/item?id=19483241 One of the goals of this year's roadmap is to significantly improve the reference, by the way.
crankylinuxuser 8y ago
The converse is what I've heard with people at REN-ISAC and whom write and coauthor RFCs. (I'm not one, but trust the comments they've made to me regarding this.) For a new dev to start writing internet-quality code, with C/C++ takes 10 years before they can make reliable code. The procedure takes what amounts to a journeyman style one-on-one until proficiency, 10k / 10 years later. With Rust, it takes 2 years for a new developer to attain proficiency. To me, those numbers are the ones that matter. Rust is stable and good, and gets out of the way of the developer... and gets in the way of the developer when coding anti-patterns.
clouddrover 8y ago
> 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-security-bugs-are-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 the roadmap for reducing the number of security flaws in C software?
- Thaxll 8y ago
  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 think Rust has a good vision for security but it's clearly not bullet proof as people seem to think, especially not on the low level fields like OS.
  - wyldfire 8y ago
    > 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.
    - Thaxll 8y ago
beders 8y ago
> 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 buffer to execute code... And: "going to introduce more bugs" - false. Empirically complete bollocks...
- jimmy1 8y ago
  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 to be a syndrome. This "rewrite" fear is exactly why our banks are stuck on 1970s and 80s code with an almost 60 year old programming language and no one left to take over maintenance. Eventually we need to get over this fear.
  - michaelt 8y ago
    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-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- deleted 8y ago
  [deleted]
- bluejekyll 8y ago
  I wish the article had started with “I don’t really care” about safety, and by extension, security issues. It’s putting your head in the sand to hold this perspective in modern computing. The funny thing is, I don’t disagree with the author’s contention that Rust derived from C++, but this completely ignores the fact that C++ directly derives from C! C++ wanted to make certain patterns in C easier, and to reduce certain foot guns. Rust is in essence, a reimagination if that same effort, but includes the next 30 years of language research in its design to overcome those same problems. So Rust does derive from C. But who cares? It’s a different language, if you like Go more because it’s closer to what you think of as C, then use that. But don’t kid yourself that C safety concerns don’t have practical implications in the real world.
rwj 8y ago
The current pace of development of C++ is questionable, but Rust is still a fairly young language, so the comparison to C seems unfair. Presumably, the rate of change in Rust will slow down. Although, if you are looking for stability today, the point does stand.
gvx 8y ago
This reads like a rant about screwdrivers being terrible hammers. By the way, there is a lot of polyglot library code out there that is both valid C and C++, which is the reason for using "C/C++" much of the time.
xiphias2 8y ago
,,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, and hopefully improve them in the next years.
- jhasse 8y ago
  > 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.
  - Rusky 8y ago
    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.)
    - jhasse 8y ago
      Yes, I have used Eclipse and IntelliJ. Have you used cquery for example (https://github.com/cquery-project/cquery 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.
      - Rusky 8y ago
        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.
joshdover 8y ago
Most of the author's points here derive from the fact that C has been around for nearly 50 years and Rust a mere 8. This post should really be titled "Rust is not a good C replacement _right now_". Yes, Rust still has a long way to go to be the right tool for all the things you can do with C today, but that doesn't make it less. It clearly has benefits when writing concurrent and safe code. You pay for this with a learning curve, but the Rust team has been shaving this curve down through better tooling and documentation for the past few years. > 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 suspect that for the author's work, these things may not matter much. But to a programmer working on any software where security is paramount (many web infrastructure pieces), this feature is golden. I expect that as Rust matures, we'll see a solidified spec, competing implementations, and expanded build tooling. C has a long head-start, not to acknowledge that is just wrong.
- steveklabnik 8y ago
  8 is even stretching it, May will be four years since things have actually been stable. Even that was the minimum we could provide guarantees for.
- JoeAltmaier 8y ago
  Its not unreasonable to expect Rust to have looked at history, and improved upon it. To start out less than C means what? We don't want to wait 50 years for another language to 'mature'. Why can't it start out as good as, or even a step ahead of what came before? That may be the source of the disappointment surrounding deployment of Rust - why is it behind and not ahead of other tools?
  - Sharlin 8y ago
    That doesn't make any sense. What do you mean "less than C"? Rust definitely looked at history and improved upon it, that's the whole point of the language! The author's gripe was that they feel Rust is evolving quickly much beyond C (like C++), not that it's trying to catch up on C. And do you really expect a language to just appear one day, fully grown, like Venus from a seashell?
WallWextra 8y ago
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.
- notacoward 8y ago
  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.
estomagordo 8y ago
I keep trying to make up my mind whether this author is a C programmer. Hmmm.
fxfan 8y ago
If OP thinks Firefox is one of the largest C++ codebases in the world then OP has a very limited worldview.
- GhotVeren 8y ago
  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?
  - ben0x539 8y ago
    Closed source codebases, presumably.
  - wglb 8y ago
    Er, firefox is reported to have 12 million, while llvm has 2 million. gcc is 7 million.
- postalrat 8y ago
  How many thousands are larger? Now how many thousands are smaller?
  - chessturk 8y ago
    Taking a total shot in the dark, but I imagine AAA video games constitute a crap-ton of C++ codebases larger than Firefox, but I wouldn't know for sure.
    - village-idiot 8y ago
      Finance tends to write a lot of C++ too, but I couldn't possibly estimate their code base sizes.
- wglb 8y ago
  The telephone switching system ESS 5 has 100 million lines of code. Many enterprises, particularly software-focused ones, are likely to have 30 million lines of code or more.
kristaps 8y ago
Age of the langs absolutely needs to be taken into account if comparing stability and feature addition rate. According to Wikipedia it's 47 years for C vs 8 years for Rust (as of 2019) - it's not that surprising that a 6x older language is much more stable.
IshKebab 8y ago
> Concurrency is generally a bad thing Erm... > 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. Ok this is nonsense.
bhaak 8y ago
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 programming and for both of these usecases we feel the pain and would actually want something else. > 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. Old C programmer yelling at clouds? > Consider Go, which has had a lot of success in supplanting C for many problems. It does this by specializing on certain classes of programs and addressing them with the simplest solution possible. It hasn’t completely replaced C, but it has made a substantial dent in its problem space - more than I can really say for Rust Go is IMHO a nice language and I would have been delighted to have it in the 90s. But nowadays it already feels outdated on arrival. Lately I've been noticing more and more tools being developed with Rust. Some things take time, I wouldn't already write off Rust yet.
- Sir_Cmpwn 8y ago
  Author here. >The main fallacy of this blog post is that he wants it to be one single programming language that replaces C. That's not at all what I'm suggesting. In fact I thought this part of the article makes it clear that I feel the opposite way: >C is far from the perfect language - it has many flaws. However, its replacement will be simpler - not more complex. Consider Go, which has had a lot of success in supplanting C for many problems. It does this by specializing on certain classes of programs and addressing them with the simplest solution possible. It hasn’t completely replaced C, but it has made a substantial dent in its problem space - more than I can really say for Rust (which has made similar strides for C++, but definitely not for C).
  - bhaak 8y ago
    > 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 you dismiss this outright, you could have written a much shorter article or at least written a much more interesting article by starting with this admission and from that working your way through Rust's feature and explaining how this doesn't alleviate the warts of Rust. > But now you know why we are still writing C I wonder who this "we" is? I'm also still writing C but for quite different reasons. Mostly because of legacy code and to some degree even just to be able to claim that I'm working on 35 year old code.
StreamBright 8y ago
Totally agree with his observations but I disagree with the conclusion. C is a ok programming language. The first language that realises that simplicity above all is the most important feature of any language and uses the same safety measures like Rust is going to win over a huge user base.
- Kaveren 8y ago
  Simplicity is not the end all be all. Where is Rust, as a language, needlessly complex?
  - StreamBright 8y ago
    I regularly try to use Rust but get lost soon. The amount of magic observed in an average Rust code base is just too much for me.
- rhn_mk1 8y ago
  Low level programming in a safe way is a complicated endaevor. The assembly language with a few instructions can be the ultimately simple language, but it doesn't offer the same features that Rust does. While I am all for simplicity, I just don't think it's all that obvious that a language could possibly be simple, fast, and safe at the same time.
  - StreamBright 8y ago
    Sorry when I mean simplicity I do not mean it in the ASM sense but more like LISP. Very simple basics, very powerful concepts.
nicoburns 8y ago
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 prevent you doing stupid things, so you get the benefits without these costs. It's not perfect, but I've personally had zero issues with concurrent code in Rust. This is actually a benefit Rust provides even over other memory safe languages like Java. > C has a spec. Yes, C has a spec. But a ridiculous number of things (in a modern context) are left as undefined behaviour in that spec, meaning that it is very easy to accidentally violate the spec. Rust doesn't have a spec yet, but it has far more safeguards which make it much easier to avoid weird unexpected behaviours in practice. A full spec will come eventually.
- cogman10 8y ago
  > 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!
Tomte 8y ago
I've been waiting so much for a way to use rustup (and Cargo, but that's beyond the pull request a bit further down) behind a MITM proxy. And since Rust has always been Windows-friendly, I had high hopes when someone actually started to implement this support (basically pass "-k" to curl). Because I had fought with all kinds of git and curl configuration files, until I realized that those don't mean anything to rustup. The implementation was critiqued in a very civil way. The author fixed the issues. Everything was ready to merge and... in walk some busybodies who under the pretense of caring about security (having no clue about the issue or modern Windows workplaces, and despite clear refutations of their concerns) have seemingly been able to kill this patch: https://github.com/rust-lang/rustup.rs/pull/1624/ https://github.com/rust-lang/rustup.rs/pull/1624/ "We need to discuss this with experts". I don't know where, I briefly searched for any such discussion. I guess there was none. So a drive-by shooting killed a very useful feature. The saboteurs can revel in the knowledge that they drove away a new contributor (I haben't seen any more activity on that GitHub issue). And users suffer. Thanks a lot! Sabotaging corporate users must feel very good.
- steveklabnik 8y ago
  Part of the issue here is that rustup has not had a dedicated maintainer in a while; we’re working on it.
  - jolhoeft 8y ago
    Is there a link to the maintainer discussion?
    - steveklabnik 8y ago
      I am not 100% sure; I’m not on the tools team, but it’s undergoing a big re-org at the moment. I’d get in touch with them: https://www.rust-lang.org/governance/teams/dev-tools https://www.rust-lang.org/governance/teams/dev-tools
- perennialmind 8y ago
  I don't know why back-to-back SSL proxies were never afforded an officially sanctioned mechanism for explicitly delegating trust. The alternative is this "I know you're lying, but I love you too much to leave you" mentality. If you're asking package managers to facilitate such a morally compromised relationship, your best bet is to make user intent explicit and circumscribed. One way to signal that intent might be to adopt a trust-on-first-use approach: > rustup --detect-mitm MITM thumbprint: 567d3e4c... > rustup --permit-mitm=567d3e4c... Not that that would be easy to do, mind you.
m0meni 8y ago
This just reads like the author was told to rewrite his code in rust one too many times, and he felt compelled to justify his own choices by bashing rust. Just say you like the simplicity and subtle bugs of C more than having to deal with the upfront complexity of low-level code at all times
wyldfire 8y ago
> C is the most portable programming language. This is a function of popularity and time. > C has a spec. No spec means there’s nothing keeping rustc honest. Agreed, language specification is critical. The language reference [1] is very detailed, though. I'm not sure what it would take to promote this to a "specification." > That really cool feature $other_language has? Not interested. It’ll be more trouble than it’s worth Binding to "editions" is a reasonable way to get stability, IMO. It's a shame that this wasn't adopted earlier. > Concurrency is generally a bad thing. So don't leverage it. Don't use fork() or clone() either and we'll all agree to ignore this point. > 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. Here underlies the crux, you should have led with this. This is a sizable portion of rust's value proposition. If you don't value it then it's likely not to measure up well. > Rust will eventually fail to the “jack of all trades, master of none” problem that C++ has. 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. [1] https://doc.rust-lang.org/1.0.0/reference.html https://doc.rust-lang.org/1.0.0/reference.html
- ddevault 8y ago
  >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.
  - jhasse 8y ago
    > 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.
    - ddevault 8y ago
      I was measuring by number of projects. Consider that most web browsers also depend on a dozen or more C libraries.
bitwize 8y ago
Of course C programmers are going to think Rust is a poor C replacement. Rust wasn't made for C programmers -- it was made for their replacements.
- z3phyr 8y ago
  Zig is a better replacement for C and Rust. C programmers no this, but Rust programmers can't comprehend simplicity. They won't know
adrianN 8y ago
As long as you don't write software for computers that are connected to a network, it's fine not to care about security. For everybody else though, new software should probably be written in a safer language. That doesn't have to be Rust of course.
marricks 8y ago
> 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 should have stopped at C cause someone would have had to rewrite something and that would mean more bugs??
- jhasse 8y ago
  Most programming languages can call C code, so you don't have to rewrite something when switching to them.
  - steveklabnik 8y ago
    Rust can as well, and it can also expose the C ABI too, so it can work both ways.
iheartpotatoes 8y ago
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 life so much easier in the early 90's when they converged on Gnu. My favorite part of the article is the footnote. We really need to stop referring to C/C++ as "roughly the same" because they are so so so radically different.
- wglb 8y ago
  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.
deleted 8y ago
[deleted]
jszymborski 8y ago
I think a better title for this post would be "Rust is not C". I'm also not sure how stating the number of features recently added to a 47yo language is very small and the number of features added to a 8yo language is very large proves any point. That you don't care about safety or concurrency has nothing to do with the title, and frankly betrays that this article is more about Rust not being last decade's systems language as opposed to Rust being a good candidate for future projects that would otherwise have chosen C.
zaarn 8y ago
> "measured by the number of bullet points [...] on Wikipedia" > "measured by the number of headers in the release notes of major [...] versions" I don't think it's a fair comparison to pull from these two types of sources, compare the numbers and expect a reasonable result. The entire rest of this blog reads more like a rant about screws not being nails than an actual complain about the languages itself.
mjw1007 8y ago
I think there is a gap in the market for small language which is just a "better C", but developing a new language is a great deal of work, and it would be hard to compete against the alternative of using a small subset of {Ada, Rust, whatever}. Maybe the large languages should look at defining official subsets, to make life simpler both for programmers and validation. Ada used to have something of the sort (and still does for all I know).
- chessturk 8y ago
  I'm curious if you consider Nim or Golang to be a small language that is a "better C". If not, why?
  - mjw1007 8y ago
    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).
    - chessturk 8y ago
      Makes sense to me, thanks for answering.
    - nimmer 8y ago
      Regardless, I use Nim when I need the performance and memory footprint of C. GC is optional.
      - mjw1007 8y ago
        Right, that's exactly the « it would be hard to compete against the alternative of using a small subset of {whatever} » case.
      - jefftime 8y ago
        Can you use the standard library without GC?
jdright 8y ago
"...I’ll take my segfaults and buffer overflows" Well, this speaks volumes. Nothing more need to be said.
solarkraft 8y ago
Sir_Cmpwn has lost a bit of credibility in my eyes after this article and their behavior in the comments.
KirinDave 8y ago
Personally, I think the C community is deeply infatuated with the idea that "we are in fact simple" mentality even though it's not well justified. C isn't simple. C isn't simple to use. On the implementation side, it has a complex calling convention. It relies on a memory management runtime without spec'd behavior. Tons of hardware implementation details leak up to the upper levels. C's error handling schemes are inconsistent, and thus complex to work with and to implement. Being a C programmer isn't much easier either! C's memory managers tend to blow up if misused, but they don't blow up WHEN they're misused. They always cause problems, but it's not clear how or why. You have a bomb in your code that will go off in a random place. Even good debuggers with great tools can find it challenging to find the source of a double free. And that's alongside managing the weakly typed (not to be confused with static/dynamic) world, the pointer arithmetic, the inconsistent library conventions. Oh yeah, the libraries... C's libraries aren't simple. They have to protect themselves from double inclusion, they can collide with each other, and have wildly different conventions depending on if they're loaded at runtime or compile time. Despite a constant derision of OO from the community, they often affect an "OO" discipline on methods. In reality this asks developers to create the impression of OO behavior by being very (very!) careful with call sequencing. And of course, the price of failure on most of these tasks is at runtime, on someone else's hardware, often with opportunities for remote execution. When a C programmer says, "C is far from the perfect language - it has many flaws. However, its replacement will be simpler - not more complex," we have to read it very carefully and ask, "What does simpler mean?" Because despite the complexities of being a C programmer and the unstated complexities of the C runtime (and the large portion of unspec'd behavior so glibly ignored in this article to dunk on Rust), they still say "C is simple." In this case, evidently it means: "Consider Go, which has had a lot of success in supplanting C for many problems. It does this by specializing on certain classes of programs and addressing them with the simplest solution possible." Go isn't simpler. Go actually aims for a rather broad category of programs (it goes way up into the world of abstraction Python covers, and stops short of the embedded world where C is firmly entrenched because it's well-understood). Go has a sophisticated (and arguably, hard-to-use) concurrency model (didn't the author just say, "Concurrency is generally a bad thing?") and implementation. It has real garbage collection. Its stdlib is expected to have full SSL and networking support builtin. But Golang is familiar to C programmers. I think that is why we see all the dunks on C++ and Rust in this artcile. C++ and Rust are weird. They're different. Go feels like C, so it's "simpler to learn" even if it requires a whole lot more core concepts and careful implementation than a C compiler. Maybe Rust isn't your solution. Okay. Maybe C++ isn't your solution. Okay. There's still lots of other good languages to try. Languages that don't ask users to wade among a field of charged rails that the slightest touch can result in catastrophe. Nim or D maybe? There are others, and you can find them. But continuing to use C with the attitude that, and I quote, "I don’t really care. In light of [the complaints leveled at Rust], I’ll take my segfaults and buffer overflows" is dangerous. It's unprofessional. It's reckless. It's also a false dichotomy. The answer to C's problems is to stop using C. Not to start using something else specifically. This article makes it clear that the actual goal of this sentiment in the C camp is to keep using C. There isn't even a candid ownership of the problems with that strategy.
monster2control 8y ago
Why do people up vote your flame war post? Ah, exploiting the human urge to argue about literally anything. Especially when your argument is full of flaws and straw men statements.
calibas 8y ago
>Rust will eventually fail to the “jack of all trades, master of none” problem that C++ has. He's talking about C++ like it's some kind of failure and not one of the most widely used languages in the world. Sounds like the author just doesn't like C++, so it's no surprise he doesn't like Rust either. >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 don't really care" isn't a good reason for ignoring one of Rust's strongest points. If you're not an expert in C like the author, then this would be one of the biggest reasons for choosing Rust over C. That being said, I agree than Rust isn't a good C replacement, mainly because it's more similar to C++.
notacoward 8y ago
> A program which uses poll effectively is going to be simpler, reasonably performant, Only for newbie values of "performant". I work on data-storage servers. It has been quite a few years since I've worked on one that didn't absolutely need to take advantage of multiple cores to get competitive performance, and I'm very far from being alone in this need. Splitting one server into many separate processes is not a solution in these cases, as it just moves complexity from the in-process domain to the between-process domain where it's even harder to maintain good performance (or even validate correctness). As soon as I read "concurrency is generally a bad thing" the author lost all credibility.
sevensor 8y ago
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.
chessturk 8y ago
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.
- steveklabnik 8y ago
  > How can folk say Rust guarantees safety when it doesn't guarantee an implementation? Just because there isn't a formal spec, doesn't mean that the underlying systems aren't built with some rules, grounded in computer science and math. We believe that the systems we've set up do guarantee those properties, even if they haven't yet been formally verified. And a subset of them have been formally verified, which also increases confidence. Adding to that confidence level is empirical results: while people have found implementation bugs, which will always exist in any implementation, nobody has managed to demonstrate that the model is fundamentally broken. That it's been years, and many people have tried, also leads us to suspect that our conclusions are correct here. Put another way: not all specs are equal. Some are formal, some are informal. Just having a spec doesn't actually guarantee anything either. Most languages don't have a specification at all.
  - chessturk 8y ago
    > Put another way: not all specs are equal. Some are formal, some are informal. So is the argument that the language reference is as good as many existing language specifications, and my complaint is only one of semantics?
    - steveklabnik 8y ago
      Yes, it's basically about what you mean by "guarantee". Very few things are formally guaranteed. People tend to use "guarantee" to mean "I believe this is true with a very high level of confidence."
    - deleted 8y ago
7e 8y ago
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.
- nickez 8y ago
  I thought you had to write "Show HN:" when you were publishing your own content..
  - grzm 8y ago
    > ”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 https://news.ycombinator.com/showhn.html
- kbenson 8y ago
  He's had some very high quality submissions of his own posts in the past, and contributes here regularly and to the benefit of most, I believe. I don't necessarily agree with his conclusions, nor the way in which he defended some of them here, but it's pretty clear this whole comment section went to hell pretty early, and I don't think he deserves most the blame for that. I don't think most the Rust contributors or well known advocates do either. There was a huge amount of drive-by commenting where people seemed to sense the way the wind was blowing and thought it would be a good idea to pile on. That didn't help anyone.
picacho 8y ago
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.
_nalply 8y ago
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.
- burntsushi 8y ago
  That's true, and personally, I hope it continues. However, there are some significant new features that have already been approved that are being worked on right now. e.g., Specialization, const generics and generic associated types. Each of these is somewhat significant in that they might alter how one might write some kinds of code today. But generally, they open new doors by adding more expressiveness to the type system.
phaazon_ 8y ago
I read through the article and I recognized the pattern of an old C cave bear that refuses to learn new things and understand why safety and type theory matters. Lots of arguments made in that post are either unfair (i.e. the Cargo team stuff) or completely wrong. Also, if you think Go is a replacement of C, I think you are not a real systems programmer. Go has a GC, in the first place: how can you seriously state it’s a replacement of C? Also, you didn’t mention it (voluntary I guess), but Rust does have a community-based mechanism to make the language evolve (RFCs). About the number of features, those are mostly non-breaking changes additions. Rust has editions now. Just… do your homework? C++ is mostly used as a OOPL. Rust has no concept of OOP. > 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. Sorry For Your Loss.
erotavlas 8y ago
From performance point of view, Rust is comparable to C++ https://benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are-fast.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

148 points by ddevault 8y ago

Meta: feel free to flag or downvote this post. Please do not downvote Sir_Cmpwn just because you disagree with what they've written. Instead, please try to formulate a rebuttal comment here or your own blog post.

adamnemecek 8y ago

OK looking Just at the number of features seems disingenuous. Cpp features tend to idk, increase the level of complexity as there tends to be quite a bit of friction between them. Rust features definitely “work together”. This post seems to have started with a conclusion and worked backwards. Rust is such a breath of fresh air. Cargo is nuts. The community is nuts. I’ve been writing rust full time for a couple of months now and I’m not going back.

xiphias2 8y ago
The main problem with C++ are not the new features, but the old obsolate ones. It's too late to fix the language.
- adamnemecek 8y ago
  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).
  - sseagull 8y ago
    But isn't this how you end up with a 'bloated' language? Everyone has their own corner case, own little way the language can be improved. Over time, these will inevitability burden a language. Adding features becomes necessarily bureaucratic as languages mature. You can't just add/change stuff without seeing how it interacts with everyone else, which gets difficult as languages grow and become popular.
    - adamnemecek 8y ago
      That depends on how these features are added. https://github.com/rust-lang/rust/blob/master/RELEASES.md https://github.com/rust-lang/rust/blob/master/RELEASES.md I would argue that cpp, despite being much older, is still adding features that are kinda backbreaking e.g. ranges.
  - glangdale 8y ago
    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. :-)
    - adamnemecek 8y ago
      There's nothing ironic about that. If they had a shorter feedback loop, things could be getting fixed faster.
- xiphias2 8y ago
  I'm not sure why I'm being downvoted...I'd love to have an explanation from that person of how much diamond inheritance benefits our lives and makes it so much simpler to write maintainable code.

steveklabnik 8y ago

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't finished them up. But this is very much something that is cared about and desired by the team. It was literally on the 2017 roadmap: https://blog.rust-lang.org/2017/02/06/roadmap.html https://blog.rust-lang.org/2017/02/06/roadmap.html > Rust should integrate easily into large build systems. Plans include working with large companies incorporating Rust to understand how best to equip Cargo to smooth the process. I don't know how this is framed as "hostility". As one example of the work done here: https://github.com/rust-lang/cargo/issues/5579 https://github.com/rust-lang/cargo/issues/5579

ddevault 8y ago
Thanks for sharing your perspective. My comment was largely based on this discussion: https://github.com/mesonbuild/meson/issues/2173 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.
- steveklabnik 8y ago
  I would suggest not taking comments on random github threads as the position of a completely different project.
  - Sir_Cmpwn 8y ago
    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.

deleted 8y ago

[deleted]

Symmetry 8y ago

Concurrency might be a dangerous thing but in microcontroller land, where I do my C programming, interrupts are a fact of life and just polling really isn't a practical solution.

MuffinFlavored 8y ago
Is that how Rust concurrency works under the hood? Polling?
- steveklabnik 8y ago
  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.
  - MuffinFlavored 8y ago
    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?
    - steveklabnik 8y ago
      There are a number of different options. And today, yes, code is tied to one of them. But, and it’s not stable yet, futures and executors, the two traits, are being added to the standard library. This lets your code be generic over executors, and there are already more than just tokio. Including an embedded one, for example. Tokio wraps epoll/kqueue/iocp.
      - MuffinFlavored 8y ago
        > But, and it’s not stable yet, futures and executors, the two traits, are being added to the standard library. Is this implementation going to wrap epoll/kqueue/iocp? Would you say Tokio has any drawbacks/flaws/design choices yo aren't a fan of? What are the popular choices other than Tokio?

jonathanstrange 8y ago

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.

mjw1007 8y ago
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.
- kibwen 8y ago
  > 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.
  - mjw1007 8y ago
    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.)
- steveklabnik 8y ago
  I wrote a comment about this over here: https://news.ycombinator.com/item?id=19483241 https://news.ycombinator.com/item?id=19483241 One of the goals of this year's roadmap is to significantly improve the reference, by the way.

crankylinuxuser 8y ago

The converse is what I've heard with people at REN-ISAC and whom write and coauthor RFCs. (I'm not one, but trust the comments they've made to me regarding this.) For a new dev to start writing internet-quality code, with C/C++ takes 10 years before they can make reliable code. The procedure takes what amounts to a journeyman style one-on-one until proficiency, 10k / 10 years later. With Rust, it takes 2 years for a new developer to attain proficiency. To me, those numbers are the ones that matter. Rust is stable and good, and gets out of the way of the developer... and gets in the way of the developer when coding anti-patterns.

clouddrover 8y ago

> 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-security-bugs-are-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 the roadmap for reducing the number of security flaws in C software?

Thaxll 8y ago
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 think Rust has a good vision for security but it's clearly not bullet proof as people seem to think, especially not on the low level fields like OS.
- wyldfire 8y ago
  > 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.
  - Thaxll 8y ago

beders 8y ago

> 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 buffer to execute code... And: "going to introduce more bugs" - false. Empirically complete bollocks...

jimmy1 8y ago
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 to be a syndrome. This "rewrite" fear is exactly why our banks are stuck on 1970s and 80s code with an almost 60 year old programming language and no one left to take over maintenance. Eventually we need to get over this fear.
- michaelt 8y ago
  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-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
deleted 8y ago
[deleted]
bluejekyll 8y ago
I wish the article had started with “I don’t really care” about safety, and by extension, security issues. It’s putting your head in the sand to hold this perspective in modern computing. The funny thing is, I don’t disagree with the author’s contention that Rust derived from C++, but this completely ignores the fact that C++ directly derives from C! C++ wanted to make certain patterns in C easier, and to reduce certain foot guns. Rust is in essence, a reimagination if that same effort, but includes the next 30 years of language research in its design to overcome those same problems. So Rust does derive from C. But who cares? It’s a different language, if you like Go more because it’s closer to what you think of as C, then use that. But don’t kid yourself that C safety concerns don’t have practical implications in the real world.

rwj 8y ago

The current pace of development of C++ is questionable, but Rust is still a fairly young language, so the comparison to C seems unfair. Presumably, the rate of change in Rust will slow down. Although, if you are looking for stability today, the point does stand.

gvx 8y ago

This reads like a rant about screwdrivers being terrible hammers. By the way, there is a lot of polyglot library code out there that is both valid C and C++, which is the reason for using "C/C++" much of the time.

xiphias2 8y ago

,,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, and hopefully improve them in the next years.

jhasse 8y ago
> 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.
- Rusky 8y ago
  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.)
  - jhasse 8y ago
    Yes, I have used Eclipse and IntelliJ. Have you used cquery for example (https://github.com/cquery-project/cquery 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.
    - Rusky 8y ago
      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.

joshdover 8y ago

Most of the author's points here derive from the fact that C has been around for nearly 50 years and Rust a mere 8. This post should really be titled "Rust is not a good C replacement _right now_". Yes, Rust still has a long way to go to be the right tool for all the things you can do with C today, but that doesn't make it less. It clearly has benefits when writing concurrent and safe code. You pay for this with a learning curve, but the Rust team has been shaving this curve down through better tooling and documentation for the past few years. > 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 suspect that for the author's work, these things may not matter much. But to a programmer working on any software where security is paramount (many web infrastructure pieces), this feature is golden. I expect that as Rust matures, we'll see a solidified spec, competing implementations, and expanded build tooling. C has a long head-start, not to acknowledge that is just wrong.

steveklabnik 8y ago
8 is even stretching it, May will be four years since things have actually been stable. Even that was the minimum we could provide guarantees for.
JoeAltmaier 8y ago
Its not unreasonable to expect Rust to have looked at history, and improved upon it. To start out less than C means what? We don't want to wait 50 years for another language to 'mature'. Why can't it start out as good as, or even a step ahead of what came before? That may be the source of the disappointment surrounding deployment of Rust - why is it behind and not ahead of other tools?
- Sharlin 8y ago
  That doesn't make any sense. What do you mean "less than C"? Rust definitely looked at history and improved upon it, that's the whole point of the language! The author's gripe was that they feel Rust is evolving quickly much beyond C (like C++), not that it's trying to catch up on C. And do you really expect a language to just appear one day, fully grown, like Venus from a seashell?

WallWextra 8y ago

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.

notacoward 8y ago
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.

estomagordo 8y ago

I keep trying to make up my mind whether this author is a C programmer. Hmmm.

fxfan 8y ago

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

GhotVeren 8y ago
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?
- ben0x539 8y ago
  Closed source codebases, presumably.
- wglb 8y ago
  Er, firefox is reported to have 12 million, while llvm has 2 million. gcc is 7 million.
postalrat 8y ago
How many thousands are larger? Now how many thousands are smaller?
- chessturk 8y ago
  Taking a total shot in the dark, but I imagine AAA video games constitute a crap-ton of C++ codebases larger than Firefox, but I wouldn't know for sure.
  - village-idiot 8y ago
    Finance tends to write a lot of C++ too, but I couldn't possibly estimate their code base sizes.
wglb 8y ago
The telephone switching system ESS 5 has 100 million lines of code. Many enterprises, particularly software-focused ones, are likely to have 30 million lines of code or more.

kristaps 8y ago

Age of the langs absolutely needs to be taken into account if comparing stability and feature addition rate. According to Wikipedia it's 47 years for C vs 8 years for Rust (as of 2019) - it's not that surprising that a 6x older language is much more stable.

IshKebab 8y ago

> Concurrency is generally a bad thing Erm... > 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. Ok this is nonsense.

bhaak 8y ago

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 programming and for both of these usecases we feel the pain and would actually want something else. > 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. Old C programmer yelling at clouds? > Consider Go, which has had a lot of success in supplanting C for many problems. It does this by specializing on certain classes of programs and addressing them with the simplest solution possible. It hasn’t completely replaced C, but it has made a substantial dent in its problem space - more than I can really say for Rust Go is IMHO a nice language and I would have been delighted to have it in the 90s. But nowadays it already feels outdated on arrival. Lately I've been noticing more and more tools being developed with Rust. Some things take time, I wouldn't already write off Rust yet.

Sir_Cmpwn 8y ago
Author here. >The main fallacy of this blog post is that he wants it to be one single programming language that replaces C. That's not at all what I'm suggesting. In fact I thought this part of the article makes it clear that I feel the opposite way: >C is far from the perfect language - it has many flaws. However, its replacement will be simpler - not more complex. Consider Go, which has had a lot of success in supplanting C for many problems. It does this by specializing on certain classes of programs and addressing them with the simplest solution possible. It hasn’t completely replaced C, but it has made a substantial dent in its problem space - more than I can really say for Rust (which has made similar strides for C++, but definitely not for C).
- bhaak 8y ago
  > 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 you dismiss this outright, you could have written a much shorter article or at least written a much more interesting article by starting with this admission and from that working your way through Rust's feature and explaining how this doesn't alleviate the warts of Rust. > But now you know why we are still writing C I wonder who this "we" is? I'm also still writing C but for quite different reasons. Mostly because of legacy code and to some degree even just to be able to claim that I'm working on 35 year old code.

StreamBright 8y ago

Totally agree with his observations but I disagree with the conclusion. C is a ok programming language. The first language that realises that simplicity above all is the most important feature of any language and uses the same safety measures like Rust is going to win over a huge user base.

Kaveren 8y ago
Simplicity is not the end all be all. Where is Rust, as a language, needlessly complex?
- StreamBright 8y ago
  I regularly try to use Rust but get lost soon. The amount of magic observed in an average Rust code base is just too much for me.
rhn_mk1 8y ago
Low level programming in a safe way is a complicated endaevor. The assembly language with a few instructions can be the ultimately simple language, but it doesn't offer the same features that Rust does. While I am all for simplicity, I just don't think it's all that obvious that a language could possibly be simple, fast, and safe at the same time.
- StreamBright 8y ago
  Sorry when I mean simplicity I do not mean it in the ASM sense but more like LISP. Very simple basics, very powerful concepts.

nicoburns 8y ago

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 prevent you doing stupid things, so you get the benefits without these costs. It's not perfect, but I've personally had zero issues with concurrent code in Rust. This is actually a benefit Rust provides even over other memory safe languages like Java. > C has a spec. Yes, C has a spec. But a ridiculous number of things (in a modern context) are left as undefined behaviour in that spec, meaning that it is very easy to accidentally violate the spec. Rust doesn't have a spec yet, but it has far more safeguards which make it much easier to avoid weird unexpected behaviours in practice. A full spec will come eventually.

cogman10 8y ago
> 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!

Tomte 8y ago

I've been waiting so much for a way to use rustup (and Cargo, but that's beyond the pull request a bit further down) behind a MITM proxy. And since Rust has always been Windows-friendly, I had high hopes when someone actually started to implement this support (basically pass "-k" to curl). Because I had fought with all kinds of git and curl configuration files, until I realized that those don't mean anything to rustup. The implementation was critiqued in a very civil way. The author fixed the issues. Everything was ready to merge and... in walk some busybodies who under the pretense of caring about security (having no clue about the issue or modern Windows workplaces, and despite clear refutations of their concerns) have seemingly been able to kill this patch: https://github.com/rust-lang/rustup.rs/pull/1624/ https://github.com/rust-lang/rustup.rs/pull/1624/ "We need to discuss this with experts". I don't know where, I briefly searched for any such discussion. I guess there was none. So a drive-by shooting killed a very useful feature. The saboteurs can revel in the knowledge that they drove away a new contributor (I haben't seen any more activity on that GitHub issue). And users suffer. Thanks a lot! Sabotaging corporate users must feel very good.

steveklabnik 8y ago
Part of the issue here is that rustup has not had a dedicated maintainer in a while; we’re working on it.
- jolhoeft 8y ago
  Is there a link to the maintainer discussion?
  - steveklabnik 8y ago
    I am not 100% sure; I’m not on the tools team, but it’s undergoing a big re-org at the moment. I’d get in touch with them: https://www.rust-lang.org/governance/teams/dev-tools https://www.rust-lang.org/governance/teams/dev-tools
perennialmind 8y ago
I don't know why back-to-back SSL proxies were never afforded an officially sanctioned mechanism for explicitly delegating trust. The alternative is this "I know you're lying, but I love you too much to leave you" mentality. If you're asking package managers to facilitate such a morally compromised relationship, your best bet is to make user intent explicit and circumscribed. One way to signal that intent might be to adopt a trust-on-first-use approach: > rustup --detect-mitm MITM thumbprint: 567d3e4c... > rustup --permit-mitm=567d3e4c... Not that that would be easy to do, mind you.

m0meni 8y ago

This just reads like the author was told to rewrite his code in rust one too many times, and he felt compelled to justify his own choices by bashing rust. Just say you like the simplicity and subtle bugs of C more than having to deal with the upfront complexity of low-level code at all times

wyldfire 8y ago

> C is the most portable programming language. This is a function of popularity and time. > C has a spec. No spec means there’s nothing keeping rustc honest. Agreed, language specification is critical. The language reference [1] is very detailed, though. I'm not sure what it would take to promote this to a "specification." > That really cool feature $other_language has? Not interested. It’ll be more trouble than it’s worth Binding to "editions" is a reasonable way to get stability, IMO. It's a shame that this wasn't adopted earlier. > Concurrency is generally a bad thing. So don't leverage it. Don't use fork() or clone() either and we'll all agree to ignore this point. > 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. Here underlies the crux, you should have led with this. This is a sizable portion of rust's value proposition. If you don't value it then it's likely not to measure up well. > Rust will eventually fail to the “jack of all trades, master of none” problem that C++ has. 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. [1] https://doc.rust-lang.org/1.0.0/reference.html https://doc.rust-lang.org/1.0.0/reference.html

ddevault 8y ago
>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.
- jhasse 8y ago
  > 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.
  - ddevault 8y ago
    I was measuring by number of projects. Consider that most web browsers also depend on a dozen or more C libraries.

bitwize 8y ago

Of course C programmers are going to think Rust is a poor C replacement. Rust wasn't made for C programmers -- it was made for their replacements.

z3phyr 8y ago
Zig is a better replacement for C and Rust. C programmers no this, but Rust programmers can't comprehend simplicity. They won't know

adrianN 8y ago

As long as you don't write software for computers that are connected to a network, it's fine not to care about security. For everybody else though, new software should probably be written in a safer language. That doesn't have to be Rust of course.

marricks 8y ago

> 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 should have stopped at C cause someone would have had to rewrite something and that would mean more bugs??

jhasse 8y ago
Most programming languages can call C code, so you don't have to rewrite something when switching to them.
- steveklabnik 8y ago
  Rust can as well, and it can also expose the C ABI too, so it can work both ways.

iheartpotatoes 8y ago

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 life so much easier in the early 90's when they converged on Gnu. My favorite part of the article is the footnote. We really need to stop referring to C/C++ as "roughly the same" because they are so so so radically different.

wglb 8y ago
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.

deleted 8y ago

[deleted]

jszymborski 8y ago

I think a better title for this post would be "Rust is not C". I'm also not sure how stating the number of features recently added to a 47yo language is very small and the number of features added to a 8yo language is very large proves any point. That you don't care about safety or concurrency has nothing to do with the title, and frankly betrays that this article is more about Rust not being last decade's systems language as opposed to Rust being a good candidate for future projects that would otherwise have chosen C.

zaarn 8y ago

> "measured by the number of bullet points [...] on Wikipedia" > "measured by the number of headers in the release notes of major [...] versions" I don't think it's a fair comparison to pull from these two types of sources, compare the numbers and expect a reasonable result. The entire rest of this blog reads more like a rant about screws not being nails than an actual complain about the languages itself.

mjw1007 8y ago

I think there is a gap in the market for small language which is just a "better C", but developing a new language is a great deal of work, and it would be hard to compete against the alternative of using a small subset of {Ada, Rust, whatever}. Maybe the large languages should look at defining official subsets, to make life simpler both for programmers and validation. Ada used to have something of the sort (and still does for all I know).

chessturk 8y ago
I'm curious if you consider Nim or Golang to be a small language that is a "better C". If not, why?
- mjw1007 8y ago
  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).
  - chessturk 8y ago
    Makes sense to me, thanks for answering.
  - nimmer 8y ago
    Regardless, I use Nim when I need the performance and memory footprint of C. GC is optional.
    - mjw1007 8y ago
      Right, that's exactly the « it would be hard to compete against the alternative of using a small subset of {whatever} » case.
    - jefftime 8y ago
      Can you use the standard library without GC?

jdright 8y ago

"...I’ll take my segfaults and buffer overflows" Well, this speaks volumes. Nothing more need to be said.

solarkraft 8y ago

Sir_Cmpwn has lost a bit of credibility in my eyes after this article and their behavior in the comments.

KirinDave 8y ago

Personally, I think the C community is deeply infatuated with the idea that "we are in fact simple" mentality even though it's not well justified. C isn't simple. C isn't simple to use. On the implementation side, it has a complex calling convention. It relies on a memory management runtime without spec'd behavior. Tons of hardware implementation details leak up to the upper levels. C's error handling schemes are inconsistent, and thus complex to work with and to implement. Being a C programmer isn't much easier either! C's memory managers tend to blow up if misused, but they don't blow up WHEN they're misused. They always cause problems, but it's not clear how or why. You have a bomb in your code that will go off in a random place. Even good debuggers with great tools can find it challenging to find the source of a double free. And that's alongside managing the weakly typed (not to be confused with static/dynamic) world, the pointer arithmetic, the inconsistent library conventions. Oh yeah, the libraries... C's libraries aren't simple. They have to protect themselves from double inclusion, they can collide with each other, and have wildly different conventions depending on if they're loaded at runtime or compile time. Despite a constant derision of OO from the community, they often affect an "OO" discipline on methods. In reality this asks developers to create the impression of OO behavior by being very (very!) careful with call sequencing. And of course, the price of failure on most of these tasks is at runtime, on someone else's hardware, often with opportunities for remote execution. When a C programmer says, "C is far from the perfect language - it has many flaws. However, its replacement will be simpler - not more complex," we have to read it very carefully and ask, "What does simpler mean?" Because despite the complexities of being a C programmer and the unstated complexities of the C runtime (and the large portion of unspec'd behavior so glibly ignored in this article to dunk on Rust), they still say "C is simple." In this case, evidently it means: "Consider Go, which has had a lot of success in supplanting C for many problems. It does this by specializing on certain classes of programs and addressing them with the simplest solution possible." Go isn't simpler. Go actually aims for a rather broad category of programs (it goes way up into the world of abstraction Python covers, and stops short of the embedded world where C is firmly entrenched because it's well-understood). Go has a sophisticated (and arguably, hard-to-use) concurrency model (didn't the author just say, "Concurrency is generally a bad thing?") and implementation. It has real garbage collection. Its stdlib is expected to have full SSL and networking support builtin. But Golang is familiar to C programmers. I think that is why we see all the dunks on C++ and Rust in this artcile. C++ and Rust are weird. They're different. Go feels like C, so it's "simpler to learn" even if it requires a whole lot more core concepts and careful implementation than a C compiler. Maybe Rust isn't your solution. Okay. Maybe C++ isn't your solution. Okay. There's still lots of other good languages to try. Languages that don't ask users to wade among a field of charged rails that the slightest touch can result in catastrophe. Nim or D maybe? There are others, and you can find them. But continuing to use C with the attitude that, and I quote, "I don’t really care. In light of [the complaints leveled at Rust], I’ll take my segfaults and buffer overflows" is dangerous. It's unprofessional. It's reckless. It's also a false dichotomy. The answer to C's problems is to stop using C. Not to start using something else specifically. This article makes it clear that the actual goal of this sentiment in the C camp is to keep using C. There isn't even a candid ownership of the problems with that strategy.

monster2control 8y ago

Why do people up vote your flame war post? Ah, exploiting the human urge to argue about literally anything. Especially when your argument is full of flaws and straw men statements.

calibas 8y ago

>Rust will eventually fail to the “jack of all trades, master of none” problem that C++ has. He's talking about C++ like it's some kind of failure and not one of the most widely used languages in the world. Sounds like the author just doesn't like C++, so it's no surprise he doesn't like Rust either. >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 don't really care" isn't a good reason for ignoring one of Rust's strongest points. If you're not an expert in C like the author, then this would be one of the biggest reasons for choosing Rust over C. That being said, I agree than Rust isn't a good C replacement, mainly because it's more similar to C++.

notacoward 8y ago

> A program which uses poll effectively is going to be simpler, reasonably performant, Only for newbie values of "performant". I work on data-storage servers. It has been quite a few years since I've worked on one that didn't absolutely need to take advantage of multiple cores to get competitive performance, and I'm very far from being alone in this need. Splitting one server into many separate processes is not a solution in these cases, as it just moves complexity from the in-process domain to the between-process domain where it's even harder to maintain good performance (or even validate correctness). As soon as I read "concurrency is generally a bad thing" the author lost all credibility.

sevensor 8y ago

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.

chessturk 8y ago

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.

steveklabnik 8y ago
> How can folk say Rust guarantees safety when it doesn't guarantee an implementation? Just because there isn't a formal spec, doesn't mean that the underlying systems aren't built with some rules, grounded in computer science and math. We believe that the systems we've set up do guarantee those properties, even if they haven't yet been formally verified. And a subset of them have been formally verified, which also increases confidence. Adding to that confidence level is empirical results: while people have found implementation bugs, which will always exist in any implementation, nobody has managed to demonstrate that the model is fundamentally broken. That it's been years, and many people have tried, also leads us to suspect that our conclusions are correct here. Put another way: not all specs are equal. Some are formal, some are informal. Just having a spec doesn't actually guarantee anything either. Most languages don't have a specification at all.
- chessturk 8y ago
  > Put another way: not all specs are equal. Some are formal, some are informal. So is the argument that the language reference is as good as many existing language specifications, and my complaint is only one of semantics?
  - steveklabnik 8y ago
    Yes, it's basically about what you mean by "guarantee". Very few things are formally guaranteed. People tend to use "guarantee" to mean "I believe this is true with a very high level of confidence."
  - deleted 8y ago

7e 8y ago

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.

nickez 8y ago
I thought you had to write "Show HN:" when you were publishing your own content..
- grzm 8y ago
  > ”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 https://news.ycombinator.com/showhn.html
kbenson 8y ago
He's had some very high quality submissions of his own posts in the past, and contributes here regularly and to the benefit of most, I believe. I don't necessarily agree with his conclusions, nor the way in which he defended some of them here, but it's pretty clear this whole comment section went to hell pretty early, and I don't think he deserves most the blame for that. I don't think most the Rust contributors or well known advocates do either. There was a huge amount of drive-by commenting where people seemed to sense the way the wind was blowing and thought it would be a good idea to pile on. That didn't help anyone.

picacho 8y ago

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.

_nalply 8y ago

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.

burntsushi 8y ago
That's true, and personally, I hope it continues. However, there are some significant new features that have already been approved that are being worked on right now. e.g., Specialization, const generics and generic associated types. Each of these is somewhat significant in that they might alter how one might write some kinds of code today. But generally, they open new doors by adding more expressiveness to the type system.

phaazon_ 8y ago

I read through the article and I recognized the pattern of an old C cave bear that refuses to learn new things and understand why safety and type theory matters. Lots of arguments made in that post are either unfair (i.e. the Cargo team stuff) or completely wrong. Also, if you think Go is a replacement of C, I think you are not a real systems programmer. Go has a GC, in the first place: how can you seriously state it’s a replacement of C? Also, you didn’t mention it (voluntary I guess), but Rust does have a community-based mechanism to make the language evolve (RFCs). About the number of features, those are mostly non-breaking changes additions. Rust has editions now. Just… do your homework? C++ is mostly used as a OOPL. Rust has no concept of OOP. > 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. Sorry For Your Loss.

erotavlas 8y ago

From performance point of view, Rust is comparable to C++ https://benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are-fast.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...