7 ms·
I think it has a fair chance (Go is a "systems" language and grew very quickly). I also believe you'll see it pop up in unikernels as well. Why, you ask? Becaus
by stmfd 10y ago
I think it has a fair chance (Go is a "systems" language and grew very quickly). I also believe you'll see it pop up in unikernels as well. Why, you ask? Because there's always 1 person that starts a project that gets traction.
I don't see it growing and replacing C++ though. I don't think there's much incentive post C++11 to really consider porting anything (even small things) over. Most of the features Rust gets praised for are either: (1) Ridiculous - if you need segfault protection, you're a bad programmer (CLARIFICATION: if you act like segfault protection is some majorly useful feature, you're an imbecile who must also think writing C/C++ is like disarming a bomb - nonsense; give me a real argument for Rust that isn't: insignificant, badly contrived, already in C++, etc. - you can't convince a generation of systems programmers to drop everything to move to Rust without this). Let's be honest, you don't segfault unless you're doing something idiotic. I've not segfaulted in the past 8 years in anything but assembly. Or, (2), things I've been using in C++ for the past 4 years.
Rust will definitely end up in these areas I believe but I just hope that it's not some horrible binding to a C/C++ library or something. I think backwards compatibility and current dependencies is a big thing.
- eropple 10y ago> Ridiculous - if you need segfault protection, you're a bad programmer. Let's be honest, you don't segfault unless you're doing something idiotic. I've caused segfaults in the runtimes of three major languages in the last year by running code that, from a user perspective, is completely fine. I don't think the developers of those runtimes are "bad programmers".
- stmfd 10y agoI think the bad programmers are ones who state "segfault protection" as a feature of Rust because they read it on Rust's site. I genuinely don't think these features of Rust are really all that useful (they're being disingenuous; acting like C++ is some primitive language where you segfault every 5 minutes). Even Bjarne would probably agree. He talks about the same issue at his "The Essence of C++" talk. Someone asks if he shares the blame, alongside Ritchie, for all of today's major security issues (Heartbleed is the given example). He says something similar to what I've said. Segfaults are not a major issue at all unless you're consciously doing something idiotic.
- eropple 10y agoI don't disagree with you in that well-written code should make invalid memory accesses rare. And I don't disagree that, if you write good C++ (and I've stumped around here for C++ because I really didn't learn it until C++11 and have never had an environment where I didn't have the tools to write good C++), they are. But I feel, and pretty strongly, that Rust makes it a lot harder to write bad code in general. Memory protection is just one of the ways this is true. I replied to you mostly because "you're a bad programmer if you need protection against invalid memory accesses" is rampant nonsense. Everyone needs that protection. It is at best a question of whether you need other things more. (Few people do.)
- stmfd 10y agoI agree, that was rather brash. They're not bad programmers. I tried to clarify that in my previous comment. I think C++'s biggest failing is how large and convoluted it is but, in relation to the thread's question, how many beginner C++ programmers are gonna jump straight into systems programming? I sure hope the answer is 0. I just see too many people quoting the list on Rust's homepage verbatim when I ask them about why a skilled C++ developer should pick up Rust.
- to3m 10y agoBut they're good features, mftb. I have to say that as an experienced (some might even say skilled) C++ developer I would go for pretty much all of them.
- pcwalton 10y ago> I genuinely don't think these features of Rust are really all that useful (they're being disingenuous; acting like C++ is some primitive language where you segfault every 5 minutes). Nobody said that C++ code segfaults every 5 minutes, and accusing people of being disingenuous for saying things they never said is, well, disingenuous. The claim is that memory safety problems are serious problems in C++ code. It's been found that memory safety problems are the leading overall cause of software security vulnerabilities [1]. [1]: https://insights.sei.cmu.edu/sei_blog/2014/08/performance-of-compiler-assisted-memory-safety-checking.html https://insights.sei.cmu.edu/sei_blog/2014/08/performance-of...
- makmanalp 10y ago> if you need segfault protection, you're a bad programmer. Let's be honest, you don't segfault unless you're doing something idiotic. I've not segfaulted in the past 8 years in anything but assembly sigh Please look at the "trophy case" here: http://lcamtuf.coredump.cx/afl/ http://lcamtuf.coredump.cx/afl/
- stmfd 10y agoMy views are the responses you'll probably get from the people who've been doing systems programming in C for the past 20 years. I don't doubt lots of common applications have memory issues. Maybe not a definite segfault but it's incredibly disingenuous to act like it's a major issue (as if writing C and C++ are similar to disarming a bomb or something). It's nonsense and the same reason I have been learning C++17's stuff rather than bothering with Rust. I want a better argument for: 1) A C++ developer who's been writing C++ for a long time and is skilled in modern C++ who is wondering why he'd pick up Rust for user application development? I await more superfluous bindings like "Rust-Qt". 2) Porting C/C++ to Rust code (with a rather large codebase). Every argument I've seen for Rust is: out of context, disingenuous when they compare it to other languages, or just incredibly biased. I don't think it's ironic that the majority of people I've met who have started doing Rust are bad at C and C++ and have bought into the list of features on Rust's homepage without any knowledge of anything related to them.
- makmanalp 10y agoYou're being so rude and inflammatory, for no reason. What's so frustrating is how you're convinced that everyone else is an idiot. > it's incredibly disingenuous to act like it's a major issue I gave you a trove of real world examples of serious security issues in widely used software developed by competent teams. Quite a few of these would have not existed in a language with the kind of guarantees that Rust provides. How is this disingenuous? Take a look at the OpenBSD bug - any user can kernel panic the whole host, a massive security issue. Are the OpenBSD maintainers, in your opinion, "idiotic"? Or that Xen bug - privilege escalation. Are the Xen developers, in your opinion "imbeciles"? What about all the OpenSSL / OpenSSH ones? Perhaps they're "bad at C"? The truth is that as code gets more complex, writing safe code becomes harder. The above is evidence that even smart and experienced people regularly cause colossal bugs that have real life implications.
- ivanbakel 10y ago>Let's be honest, you don't segfault unless you're doing something idiotic. I disagree, segfaults can arise out of simple mistakes in rare cases that aren't always immediately obvious - let alone a segfault in a complex system. A sign of a good language is to as much as possible make invalid states illegal by design. Why, if you can reliably check for bad memory use with the compiler, would you not do so? Toughness is no measure of coder talent, otherwise the best of us would only be using assembly for everything.
- pmarreck 10y ago> A sign of a good language is to as much as possible make invalid states illegal by design This is exactly the insight that will probably (if I can help it) keep me from leaving the functional language space ever again.
- bogomipz 10y ago>"I don't think there's much incentive post C++11 to really consider porting anything (even small things) over" I am curious why specifically C++ 11? Could you elaborate?
- stmfd 10y agoLet's look at Rust's homepage: - Zero-cost abstractions - C++, in my opinion, is the founding father of zero-cost abstractions. - Move semantics - we've had this since C++11. - Threads without data races - C++11 introduced a threading library as part of the language. We can avoid a lot of data races, deadlocks, etc. if you actually look deeper into how to implement the modern threading library well. - Efficient C bindings - this had to be listed because we all know the world relies too much on C at the moment for this not to be a feature. C++ is almost a perfect superset of C, fantastic. Modern C++ has made great strides in the direction of making writing good code a lot simpler. I don't think you're gonna convince C++ (and C developers, of course) programmers who've been doing systems programming for a long time to stop everything and jump to Rust. It's just not viable.
- 46Bit 10y agoFor an experienced C++ dev it might not seem sensible. I can appreciate your viewpoint here. But it can become a hot place for higher-level people to do lower-level things and rapidly learn a lot, as it has for me and some other Rubyists.
- jdormit 10y ago> - Threads without data races - C++11 introduced a threading library as part of the language. We can avoid a lot of data races, deadlocks, etc. if you actually look deeper into how to implement the modern threading library well. So - we can implement threads without data races if we implement threads without data races? The reason people cite memory safety as a feature of Rust over C++ is because you get it for free, without having to do any additional work to achieve it.
- soulbadguy 10y ago
- a_t48 10y agoEven if only "bad programmers" segfault (debatable - especially depending on the type of code you are writing), most of the software written in the world is not made by amazing programmers who never segfault. It doesn't matter your opinion of the developer in question when a buffer overrun happens and your data gets stolen. Encourage people to write code with less safety at your own peril.
- mtkd 10y agowhen I think of all the segfaults I've seen in last few years - it's usually been in some horrible bindings to unsafe C/C++ "if you need segfault protection, you're a bad programmer" is a ridiculous statement - your personal data is one unchecked buffer away from being very public
- pcwalton 10y ago> (1) Ridiculous - if you need segfault protection, you're a bad programmer. Let's be honest, you don't segfault unless you're doing something idiotic. I've not segfaulted in the past 8 years in anything but assembly. So let me get this straight. Is your position that Google's Chrome developers (just to name one project) are idiots? You can't hold your opinion without believing that Google, and in fact pretty much every other company that develops C++ developers, hires mostly idiots.
- lfairy 10y agoFor the uninitiated: Google dedicates a whole cluster of machines to finding memory safety bugs in Chrome. Finding segfaults is part of their work flow. https://dev.chromium.org/Home/chromium-security/bugs/using-clusterfuzz https://dev.chromium.org/Home/chromium-security/bugs/using-c...
- pmarreck 10y agoLook up the longest list of security advisories you can find, and then tally what percentage of them are based on "buffer overflow" bugs. And those are merely the cases where such a bug caused a security hole. Eliminating that entire class of bug suddenly sounds like a big win, doesn't it?