I want to preface this by saying these are my two primary languages. I have a healthy respect for both and plan to focus on both regardless. I know this is a provocative question, and I am a beginner in both languages.
I'm not talking about stuff where you're supposed to use JavaScript or C# or something - even though Rust is actually kinda okay at those too and improving all the time. I'm not even talking about C, even though I think eventually we might be able to have that conversation too. I'm specifically asserting that Rust could conceivably compete head-to head with C++.
That said, as I learn more about C++, I learn more about how much I don't know about both C++ and programming in general. From my perspective, the Hindley-Milner-inspired type system is a perfect match paired with the granular control over memory for the kind of data manipulation Rust is targeting. I am more than willing to be shown why I am wrong.
I recently posted about a Rust tree I implemented with a workaround for how Rust is restrictive, but the very first alternative I mentioned was unsafe. Of course, there is always the need to directly manipulate memory. Many standard library tools are by nature implemented in unsafe Rust, with a safe API written that's been vetted by the talented Rust team and the OSS community at large. There are many lib*-sys crates that are essentially the same thing. Any FFI with C will include unsafe raw pointers.
That's how any tool, OSS or proprietary, is deemed "safe", though, right? Smart people look at it?
I see talk of templates with a reverence, but to me they're a clunkier Rust trait. What can you do with templates that Rust traits + macros can't? Speaking of which, Functors in OCaml? Jane Street is making a solid case for that tool even over Haskell or C++. OCaml itself is an amazing language for UNIX/Linux programming. C++ is cemented, but new code is written all the time. Am I off the mark with where C++'s power lies?
Why not, all memes aside, write all brand new applicable-domain software in Rust, and write Rust interfaces where needed?
I understand that C++ imposes fewer restrictions by default, allowing people to override the machine where people know better. I don't know that I'm sold on why that precludes a new foundational language that's an improvement over what we have, and why Rust isn't it.
Photo by Edvin Johansson on Unsplash
Top comments (80)
As soon as I saw your question, I thought I'd bring up this Quora answer from Mario Queralt. He describes how just moving on from C++ is essentially impossible, and it is Rust that is the dead language.
quora.com/Why-is-the-Rust-programm...
Interesting take. I was going to say something quite similar: Rust will always lack the precedence of C++! Between C and C++, there are stable, reliable implementations of nearly every algorithm, data structure, and design pattern known to computer science. Countless libraries offer reliable means of working with hardware, graphics, sound, GUI, system...the list is practically endless.
Could Rust have that in 20 years? Sure, maybe. But until then, C++ is utterly irreplaceable. I have bigger problems to code for than to reinvent everything that exists.
Unfortunately I think you're right to some extent, at least in the sense that this is what most people do think, and that it always takes time to make big shifts anyway.
There might be good algorithms for C & C++, but at the same time they are known to repeatedly fail in creating stable and safe programs .. it's not an insignificant amount of serious security flaws out there caused basically by the fact that the software was written in C/C++.
One of the biggest hurdles for languages tends to be the fact that the library ecosystem takes a long time to grow, but Rust seems to provide reasonably easy ways to use C APIs, and make libraries that can be called from C, so that's less of an issue for sure. Also Rust does bring something significantly better to the table for that safety.
Also many decisions about programming language choice are made either by executives who can just see Java and C/C++ are popular among enterprises, or by people starting their own hobby project and picking something they know.
My personal hunch is that it's just two things:
I've been personally very excited to see several viable C/C++ killer options grow lately, and I'd like to see them learning from each other and finally take down one of the bigger class of problems the IT industry has - C/C++ programs & programmers π
Btw. Personally I see Zig being a more likely option as a winner in the end since it doesn't introduce radically new syntax and hurdles for developers, instead it's basically "a better C that even compiles C better". Incredibly interesting project and cool guy behind it.
The Zig page is a phenomenal read. Might be time to install the compiler.
The security flaws you refer to are not a failure of C or C++. They are a failure of idiots using well made tools.
So what's the remedy for idiots?
Code reviews.
Sure, OpenSSL for example has idiots writing code for them without review or any kind of controls in place. There's no issue with the fact that the code is obscure, the behavior unexpected, and that the language provides no easy tooling to ensure correctness, etc.
Nothing wrong with C/C++ π
Even if the language was easy to understand, without any gotchas anywhere, without any obscure syntax, undefined behavior, and so on, relying on code reviews is a bad idea.
Code review is performed by .. people. People are flawed. People wrote the original broken code, and people will review it and nod thinking it looks good.
When a language is well designed it can help people notice things that they should pay more careful attention to, or specifically signal "this bit is going to break the safety rules a bit" so you can focus triple effort on reviewing those 2 lines or something.
With C/C++ you're always guessing where the next gotcha comes from.
A lot of people complain about C and C++ being inherently "unsafe", but they forget all too often that their own favorite languages have gotchas too...they're just harder to spot, and far more unexpected to encounter. C and C++ don't pretend to be error-free. Given a proper understanding of the language, one can write production-quality code that has the stability of those "safer" languages, especially if one uses the newer memory safety features of C++14, C++17, and C++20.
Remember Linus's Law: "Given enough eyeballs, all bugs are shallow."
Writing code is an inherently human process. If you're looking for something fool-proof, it doesn't exist, since every language, tool, and algorithm was created by a human.
There are bad ways to do code reviews, but it's a poor workman who blames his tools. The greater danger is in not having code reviews at all.
To some degree, you are right. There are "sharp edges" in C and C++ that are mitigated in some languages.
Of course, any serious C or C++ development team is going to have a slew of static and dynamic analyzers at their disposal that do exactly that.
Again, that "safety" that other languages promise is an illusion. C++ doesn't pretend not to have gotchas. In contrast, Python and Java developers (for example) love to proclaim that their language doesn't have any "undefined behavior", yet that is altogether untrue. UB may show up less often in those languages, and is usually billed under another name, but it is there.
Every language has undefined and unexpected behavior because machine code has undefined and unexpected behavior. And the less "UB" a language has, the nastier the remaining instances tend to be.
So if you like Rust, or whatever "safe" language you prefer, by all means, use it. But don't buy into the fallacy that it's somehow impossible to write deeply flaws code in
$LANGUAGE.I'm not sure that was the assertion - heck I'm writing Rust, you'd better believe there will be some deeply flawed code out there. The benefit of Rust specifically here is that it tags code sections known to be problematic, so you can punt some of that static analysis work currently necessary in a C++ codebase to the basic compiler, and then know where to focus your human-review efforts. To me this allows you to re-focus people time on jobs for people, and better leverage computer time for jobs computers couldn't previously do. While this won't prevent bad code, to me it does seem like it would isolate it somewhat. Wouldn't this property lead to a generally more focused development workflow over time?
Sounds like you have a fundamental misunderstanding of the argument and a knee-jerk reaction to someone not liking the languages you like.
It's possible to write bad code and bugs in every language
Not RELYING on code reviews to spot all your bugs is not the same as not having code review - there's a certain class of problems for which code reviews are the best tool available, spotting obscure bugs in your code is not really one of those
The issue here is that while you might find other additional tools that do some additional static checks, and there's warnings you can enable - since they are obviously possible they should be a part of the language, enabled by default, and not easy to bypass to create obviously broken code .. they shouldn't be optional warnings, they should be compiler errors that may occasionally be explicitly and individually suppressed.
Other languages have their own issues, but quite a few have evolved to say "hey, maybe we should try to stop the programmer from doing anything stupid at least without clearly acknowledging that they know it's probably stupid".
There is no such thing as a perfect language out there, I like writing Go a fair bit, but I still need external tools to check that I'm not ignoring errors and other things regularly. I think most of them should just be a part of the compiler. But hey, at least there's no
#includeand other such massively outdated bad concepts from C/C++ to worry about.Elm's
Maybeandcaseare amazingly helpful tools to avoid bugs where you, a human being, just forgot something, and a typical static analyzer sees nothing obviously wrong with the code. Elm forces you to at least clearly acknowledge that in this bit, you're ignoring some potential states. Zig has a similar concept toMaybewith their optional types.Overall we should be using languages that are better designed, that come with "batteries included" in terms of the tools that try to ensure that you're writing good quality code, that try to help you avoid significant mistakes, that help your code review to focus on those bits where it's likely that you'll have critical errors in, and so on.
Another small point on this:
Maybe that team just got started and they don't know of these tools, and maybe their project gets published and included in another project that just sees lots of GitHub stars and doesn't have the time to verify every line of code themselves. Maybe they just have one new team member, and their CI system had a bad day and just let all the bad code pass without any complaint.
Yes, it's possible to write good code in C/C++, it's possible to write decent (I wouldn't go as far as saying good) software in PHP. Just because it's possible with enough effort or luck, doesn't make the languages any good, or in any way invalidate the complaints about the languages.
On a small tangent - Python is one of my most favorite things to write in nowadays. It's the best performance enhancing drug a programmer can have in my view, as most things you need to accomplish are significantly easier to accomplish in it.
Unfortunately while Python has a lot of great things going for it, there's still a lot where it's failing. One such things is that I need to depend on a large number of external tools to make it possible for me to write good code.
I need
poetryorpipenvto manage my dependencies, I needblackto format my code properly, I needbanditto tell me about common security issues, I needpytestto help me write decent unit tests, and so on.It'd be nice to see these also become a part of the official Python, but in case of Python, I'm quite hopeful vs. C/C++, as there's a long and clear history of pretty significant improvements having been made in the language without excessive fear about breaking things: python.org/dev/peps/
And see, that shows the attitude I have a concern with. Just because you dislike C and C++ doesn't mean it "isn't any good." It just means, at best, that it isn't right for your projects. Every language is right for some type of use case. As someone who does a significant amount of work in C and C++, specializing in memory management and debugging undefined behavior, I probably know more about the inherent flaws and drawbacks of the languages than three quarters of the people on DEV.
But, truth is, only one of us is throwing about arguments devaluing the inherent usefulness of major programming languages, and as you'll note, that person is not me. Hand-waving dismissal of the validity or merit of tools that hundreds or thousands of other developers successfully use shows an overvaluing of one's own biases and opinions. It's often a sign of immaturity.
Case-in-point, just because I personally detest Javascript does not mean that Javascript has no value. I'm not going to write a long rant on why someone shouldn't use it, just because I personally dislike it! In fact, if someone were to launch a railing attack on the viability of Javascript, I'll be one of the first in line to remind everyone: every language has its use case, and none are without significant flaws.
So really, the one with the knee-jerk reaction here is you.
JavaScript is a terrible language and it should be replaced. So is PHP, so is C, and so is C++. They only have a "use" because decisions have been made that force those languages on us: JavaScript because it's the only one supported by browsers (this is changing with WASM at least and some languages compiling into JavaScript give some hope), PHP because people who started programming with it started some projects with it and executives keep hearing PHP programmers are cheap to hire, C/C++ because of history and lack of competition in the relevant area - this has also changed now and they will hopefully start fading away.
Yes, C/C++ has a use TODAY, because they're the only languages it's possible to do certain things in yet, for example Zig and Rust don't have a mature toolchain to build code for Arduinos. I'm just going to be glad when the day comes and there is no longer a single case where you need C/C++ other than the maintenance of old software, like COBOL today. I also know JavaScript pretty well because I need it, that doesn't mean I need to like it.
You're the one turning an argument about languages to a personal attack, and thus you lose. π
This really isn't moving anywhere, goodbye, merry christmas, and all that.
I think you've both made good points, and both made personal attacks and talked passed each other somewhat. I agree, this thread is pretty thoroughly explored, thanks for the discussion!
I'll just leave this here.
yourlogicalfallacyis.com/ad-hominem
Do you mean like this?
I apologize that I don't share your viewpoint, but this really needs to stop here. This could have stayed as a constructive discussion, and I tried to keep it that way. I expressed concern over your shift in tone, wherein you stepped over the line of the Code of Conduct (see above quote):
As I said repeatedly, there is a tremendous difference between disliking a language and devaluing it altogether: declaring a language as being absolutely 'no good' (which you did multiple times) is a slap in the face of everyone who uses it. You know first hand what this is like, when you became angry at someone a few months back because they said Python was "poorly designed". It's not a "knee-jerk reaction," as you accused me of β rather, it is offense at having your professional knowledge and skill denigrated to irrelevance. Such denigration is rude, inappropriate, and below the bar of conduct for DEV.
In case you're concerned about my own statement earlier:
Whether it's a sign of your immaturity is something you will have to decide for yourself; that's why I stated it as a correlation, but not a declaration about you. I want you to be aware of how you come across to others when you post railing declarations such as you did. Your knowledge, like mine, is a mere drop in the ocean, far too insufficient to declare something like C or Rust or Python or PHP as "no good". For one to believe they can, therefore, does require one to overvalue their own bias. Take it as a constructive criticism and move on.
We don't have to agree on whether C or C++ are great languages. You don't have to like them. You can even describe what you dislike about them, and where you believe other languages shine. But you do need to have enough respect for others not to denigrate the tools they successfully use as absolutely "no good" because of your own bias. Your words do matter.
Please let this be the last post in this thread, learn from it, and let's move on.
You really have a funny way of thinking. I say that you seem to have misunderstood my argument, you take it as a personal attack and call me immature. You assert your superior knowledge, and declare your opinion thus supreme and everyone else's point of view invalid, post memes to make fun of me, and then continue to complain about how I'm not respectful of your viewpoints π
It's a pretty poor attempt to compare my comments here to someone saying
Pythonβs actual coding structure relies on white spaces in itself is "poor design". Also not really sure how any other discussion anywhere else proves your point regarding this one.There's a difference between actively offending people, and saying things people find offensive. You might not like that I don't like C/C++, and I really don't care if you do or not, I also don't really care about "how I come off to others". That doesn't mean I'm "slapping" anyone, I'm just explaining my point of view.
If you don't like me calling something "no good", well that's a you -problem. Deal with it how you wish. I will continue to call things I dislike "no good" when I feel it's appropriate.
No minds are being changed, nobody will get a satisfying "last word", this is not productive and has little to do with the original post.
You are very right.
Yeah, probably. That said, LLVM Clang has many of that same sort of static analysis baked into the compiler, if you just turn the flags on for it. (
-Wall -Wextra -Werror).It's also pretty trivial to hook
cppcheckinto your automatic workflow and/or IDE to handle all the stuff the compiler doesn't complain about.TIL, thanks! I don't know that I've ever compiled C++ without that set of flags, I'm a little scared to.
Just in case I wasn't clear,
cppcheckis an external static analyser, but it's quite a good one!Yeah, I never work without
-Wall -Wextra -Werror. I ususally throw-Wpedanticin there too, for good measure.Also, Qt Creator IDE has an amazing static analyzer working out-of-the box.
"utterly irreplaceable" in some cases; in mine, I'm not interested in spend 10+ years to start confidently program concurrency and deal with memory drama. In many cases is irreplaceable but I'm not buying that those are all cases, ever, always, for any reason. The Mozilla team are not newbies nor Microsoft devs, and they are activelly working on Rust, I guess for them C++ is not utterly irreplaceable. That every line of C/C++ will be Rust or that C/C++ are soon to be dead is nonsense, not even COBOL is dead yet. But Python and even Ruby are alive in web dev when PHP exists. And many languages slowly started replacing Perl when everything was Perl; even Bash have lost some ground with Python. And we even have NO-SQL nowdays, who knew...
You misunderstand me. By "utterly irreplaceable", I'm referring to the entire programming landscape, not specifically to each conceivable case. C and C++ cannot be completely replaced across the entire industry.
My bad, I totally agree with that, as a side note: someone asked Linus Torvalds (the Linux kernel god) if he had plans to migrate the kernel to Rust, he answered something in the lines of "Rust seems interesting but nope, I like C", so there it is, not even C is soon to be dead.
In Rust, bindings for existing C and C++ libraries can be leveraged for that use case. People are doing such things in production.
Yes, but bindings are not the same as precedence. Your techniques may need to change with the language. It's like trying to use a StackOverflow question about the Qt5 library for C++ to answer a question about PySide2 for Python; same framework, different (official) bindings, differing techniques.
You are correct in observation. But does the change in technique make a language inferior than other? Rust comes with some totally new paradigms which may seem uncoventional but that's the same experience developers in 1980s and 90s must have gone through when they had first taste of C++, Java or Python. Over time these dialects established themselves as solid and reliable tools.
Rust has got same mettle, it just needs consolidated organisational backing and continued professional interest which has already begun. Microsoft, Facebook and others are already founding their research efforts on Rust or have production systems running on Rust's shoulders.
I suppose that's really my question.
It just depends on whether there are enough experienced people more interested in The Futureβ’ instead of writing stable production code right now, and only time will tell us that.
And those absolute decaration absolutely never are wrong, also those who calim that Rust is a C/C++ killer are the same that claim C/C++ are obsolete and dead languages i.e. frontend devs, webdevs, etc. I've never heard those claims from Rust dev teams or someone seriously working in Rust; in fact I've heard more about how to integrate C/C++ existing code, which by the way was the main goal from the start with Firefox, project that is now adding Rust to their existing codebase. I don't think anyone serious thinks that Rust is gonna replace them, who thinks the entire Linux kernel will be rewritten anytime soon is crazy, maybe never will, but new modules may be written in Rust in the future. Ruby and Python didn't born dead even when PHP and Perl had almost 100% of the web market; the fact that all the C/C++ codebase won't be replaced by Rust means nothing, is like saying that laptops born dead because we already had desktops or smartphones borne dead because of laptops, or electric cars are dead because of gas. To me the quora answers comes from a frustrated C/C++ programmer somehow envious of the Rust popularity and takes too serious and personal unfounded claims of the "dead of C"
I would say the question isn't really whether something will "kill" c++ in the near term. The question is whether there are alternatives that can become viable ways to do certain kinds of programming. If so, then some of these alternatives may at some point replace c++. In the meantime, it's sufficient if a community can grow around something like rust that keeps it going and evolving into the future.
An interesting footnote to his mention of how C/C++ "killed" Fortran: the startup I work for still depends on software written in it (wgrib2, for the curious). We're hoping to replace that dependency in the new year, but "dead" is very much a relative term for programming languages.
That is an opinion not a fact. You may like to consider this unbiased view from the architect of D programming language. qr.ae/pN212s
This was expressed in 2015, things have changed since then and Rust is much more powerful and capable now.
Or we just all stick to C++40! Very fair point.
Of course, any sufficiently complicated task will require a rich set of different tools fitted to different parts of the problem, but to me the C++ needs are also met by Rust.
Oof. Altogether too fair :)
Yep, more or less. The benefit to me is in using them. If you were to write a binary search tree, your
Nodemight look like this:Now you can build a
Node<int>orNode<double>or whatever, but in yourinsert()method you will assume thatToverloads both==/<. Is there a way in C++ to tell the compiler about this? In Rust, you constrain it:Now this code won't compile unless your
Tis an appropriate type. It serves as both documentation and stronger static analysis. As far as I'm aware, all you get is the failiure to build when your code attempts to use a method likeoperator==that doesn't exist for your currentTclass.This is precisely the behavior I feel is inferior to Rust, which will fail to compile with a friendly message telling you to implement it specifically instead of guessing and failing.
I think this does cut to the core of my question. From my (completely novice) perspective, that seems to me like what we are working with. General consensus, though, is clearly that that's not the case. I understand the arguments for C++'s proliferation - it's of course not going anywhere, but I want to understand more about why Rust isn't actually as cracked up as it seems.
Thanks, this is a great response, but I do think we've mismatched on a few points. First:
That's not at all the spirit of this post, though I see how it could be taken as such. These are my two favorite languages. I do very much like Rust, and I very much like C++, and will continue to work with both for years to come. This question is more a thought experiment about inherent technical merit and domain fitness than about changing the landscape of software development.
They do, yes, but what I'm drilling for is whether there is something inherent in C/C++ that Rust could never possibly replace, or whether this ubiquity is historical. The redox experiment is doing a solid PoC already, imagine what it'd look like with another 20 years of ecosystem development.
I also agree it's a bit confusing how I wrote it up, but I do think I understand what templates are and how to use them - they're a core mechanism for building abstractions. I brought up Rust macros and OCaml Functors for the same reason, they're how to build toolkits for programmers and grow in a sane way. The equivalent in Rust is just the fact that you are able parameterize a type, you don't need to write
template <typename T>first. Classes and structs drive OOP C++ programming, but when comparing to how code is crafted in Rust the generic programming properties of C++ are a more direct fit. For that the core mechanism is templates.Rust traits go a little further. For instance, when you use that type, as far as I know there is no way to specify that you expect the type to overload
operator==. In Rust, you constrainTto types that implementPartialEq, and that alone feels worthwhile to me. I don't know of the equivalent for C++ beyond just using it correctly. I don't fully understand them, but I think C++20 concepts may address this, but I'm not sure what the answer is in C++11 (or earlier).All in all, I agree. Languages are preferences, and at the end of the day it doesn't matter what you use as long as it gets your job done well.
Ridiculously late reply, but I just came across this now. C++ 20 now has formalised concepts that can apply constraints to generic types, so this gap has been addressed.
Rust AFAIK is still missing fold expressions and variadic templates. Once you get used to these features, you wonder how did you live without them. Also, I like exceptions and method overloading. C++ also has std::error_code for those who wish to have exception less functions. The C++ FS library provides both throwing and non-throwing variants of their API.
As a polyglot programmer (forced to be one thanks to several projects), I found Rust to be the MOST complicated language - yes, even more complicated than modern C++ to learn. I learned C++ seriously only after C++ 17 and frankly all the hoopla about it being difficult was overhyped. I am actually a bit faster in C++ than in Java.
The Rust borrow checker twists my head and my code and I don't appear to focus on the problem I am attempting to solve anymore. I prefer the clean, easy, automatic memory management of modern C++ and simply following recommended safe programming practices via Core Guidelines. I can run static analysers independently of my main programming flow to avoid breaking my immersion and they catch all my bugs without interrupting me. Coding Rust gives you anxiety sometimes - you need to please the Emperor. Also, Rust compiles slower than C++.
Also Rust ecosystem is perennially in Churn - what compiled some months ago no longer compiles today. Libraries keep breaking. Stuff keeps changing all the time. C++ is well-specified and standardised language with a stable and well-defined standard library with multiple implementors. And you have a stable ecosystem with well documented libraries. And admittedly cargo is quite good but, I only started using C++ after CMake/Conan/Vcpkg won the build/packager tools war, so I never faced the old autotools+make headache that folks used to complain about.
Rust doesn't have a spec and still has only one implementation and is backed by a foundation that kicked out many of the engineers working on rust.
Frankly, Rust sounds like a lot of hype and fluff to me. But I am just an average programmer joe who is likely bad at predictions.
Interesting takes in both the post and the comments. To me Rust was about having enough control of memory without worrying too much about runtime errors that are hard to debug compared to C++. I don't think one thing will 'kill' the other. Most languages evolve into a language that has a great ecosystem for doing 'x'. Rust doesn't have that yet in my opinion but I do believe that it will. I guess we'll see in a few years :)
Python 2 EOL is in 10 days - Jan 1, 2020 :) Great example.
The code examples are much appreciated, this is indeed what I was missing:
However, that still kinda feels like, well, a "clunkier Rust trait". Which I absolutely concede is a matter of opinion. My concrete criticism is that C++ will still happily instantiate your template with whatever you ask for, and then fail at the first offending method call. Your type has been existing fine in your running program until then. Rust is able to prevent nonsensical types from being instantiated in the first place, so you never get to a runtime condition where you're looking up these template operators at all.
Yep, 100%. The difference is conceptual, not practical. The Rust
Node<T>is not generic over any typeT, it is only generic over typesTthat implement==. Any attempt to instantiate it with a type that does not is actually a type error. Traits further qualify and constrain types. In C++ it's not a type error, it's a method resolution error. As a programmer, when building this object, I do really mean to say "generic over types that can be compared for equality", not "generic in general and I promise later I'll tell you how to do it", even though where we get in the end is functionally equivalent. As it's being used, an inadequateTclass is actually not part of the "type" of this object.That feels to me "more correct", or at least more expressive. Practically, though, yeah, maybe it doesn't make a difference.
Rust strives for this as well, the difference here being that any type used in this object will use it, and the compiler is capable of making sure everything is in order before even starting down that road.
I don't think this is completely true. It is at least simpler to constrain generic types more strictly than the current implementation requires in Rust. You may wish to add extra constraints on the type to give yourself implementation flexibility without needing to break callers. For example, if the current implementation only requires equality but I only want to accept types that implement ordering, that's pretty trivial in Rust. I would guess you could use some
if 0trick in C++ to use the operator but not impact the implementation, but that obscures intent at a minimum.Conversely, (stable) Rust does not have the equivalent of SFINAE. Specialization is available in nightly, which is pretty similar. I've seen this come up comparing Abseil Swiss Map and Hashbrown maps. The former will usually do the most efficient thing by default, but the latter requires the subtle
RawEntryAPI to do things like lookup or insert without copying unless I'm actually inserting.That's not necessarily what I'm getting at in terms of programmer ergonomics, but it is an interesting observation, thanks for pointing that out. I think it will take me a little longer to find an example to illustrate the mismatch here in functionality.
My turn to pull the half-asleep card - definitely didn't mean runtime, just successful instantiation. Control flow advances to the offending method call with an object that will not succeed, and the equivalent Rust kicked out the error at object creation itself.
If really have to let me complain Rust, then that would be the feature: lifetime, unless
'a > 'balready be introduced into Rust. Except that, I think C++ allows we have full control of memory management(so we have several ways to do that, but I think this against with safe guarantee of Rust) which is very important in a very very special case, and of course not really matter for most users; I think that's why I use Rust most of time XD.Features with safety built in are a bit like railings around the Grand Canyon rim. They keep you safe, but you can't rappel down to study the cliff face. For that, you'd have to climb over the railing...at which point, if you don't do it right, the safety feature kinda adds to the ways you can hurt yourself.
Or you just can't get over the railing, and there goes the geologic survey.
It's always a tradeoff, innit? XD
Nice post, I think Rust cannot really replace C++ because it's there for many years but Microsoft is forking Rust to make a new programming language so I think Microsoft is/will ditching C++ which uses a lot of things from C++. Like most Windows Applications are written in it.
In my opinion it will be C++ that'll evolve and replace itself. Microsoft and Google have created tons of "cool" programming languages that they always ditch even themselves after a while. What's the point?
It's like saying that we don't and shouldn't use C but it is needed to run on all hardware.
Agreed, replacement is not likely or even probably warranted, but symbiosis could be.
I think Microsoft is trying to combine Rust and C++ into one which would be amazing.
Javascript and Web ASM is going to kill this debate of what language to use in the near future as the JS Engine will move out of the browser and become native with cross-platform support and access to native OS APIs.
When in doubt, always bet on Javascript!
I coded in C++ for 10+ years, I don't miss it, it's too low-level and suffer from having to write tons of your own code. Rust, I've been told is not a simple language to learn for most web programmers. So forget adoption from web developers.
I personally wouldn't waste my time learning Rust as much as I don't care for C++ and how unproductive that language is. I'll just wait it out and be super productive in JS writing native cross-platform code compiled to Web ASM.
Here is a nice talk about what's coming: youtube.com/watch?v=Qn_4F3foB3Q
Interesting take.
Nor is C++, but lots and lots of people have anyway.
Perhaps, but I don't think web developers make or break the issue here. AssemblyScript and such projects do seem interesting, but I am curious if they will be adequate to completely replace lower-level languages used to produce WASM today. WASM is a low-level concept, and having a more granular level of control in the source language is often a good thing here. Writing all your WASM in a language that lacks facilities for this might work for some domains, but I'm not convinced you can blanket-replace C++/Rust here with something like JS. I could very easily be wrong, but while JS can product WASM, can it actually produce highly optimized, tightly controlled WASM?
I don't think every developer will need this, most applications will be perfectly happy without it, but I do think some of us will.
All that said, too, while I agree WASM is game-changing tech, it still only addresses a subset of where C++ proliferates today. I think this is only addressing one part of the tool.
Yes WASM bytecode will be highly optimize, both using static analysis and dynamic branch-prediction as done in V8 Engine and SpiderMonkey JS Engine. Even right now execution time for hot-optimize JS is close to C++ code.
Here is a talk from Google JS vs C++: youtube.com/watch?v=aC_QLLilwso
The Moz technical committee along with other peoples are working on defining low-level system APIs that will be uniform and standardize. We will get true cross-platform support.
The main point is, we will finally have cross language interoperability. I will be able to use Python modules, or C/C++ libs with my JS code and likewise other language will be able to use NPM module. Basically everything will be compiled down to a WASM package, module or whatever they end up calling it.
JS with WASM will never replace something like C/C++/Rust for low-latency system coding, but how many people code drivers? or ultra low-latency systems? The typical developer will want to code some application or server most of the time. Most all will go with the easier dominant programming language to code in. Even the hype train at Mozilla for Rust has died and they stop pushing Rust as the language for the web.
WASM is going to be game changer, both in and out of the browser. Most likely you won't notice any changes, as new build tool and do the compiling for you.
Points all well taken, but I want to code drivers! And compilers, and kernels. If I could do so in Rust, I'd be much happier than in C or C++.
There are many, many types of programming.
Right with you there. WASM is a game changer. I'm just not sure that makes Rust a waste of time...maybe even the opposite.
Let me take that back What I meant to say is, knowing what's coming, there is no reason to switch to different programing language. They will all run at "almost" the same speed as WASM bytecode.
Sure if you want to re-write the OS in Rust, then that might be a project you want to take on. It won't be any safer or bug free.
Whatever you do, never ask Linus why Linux is coded in C and not C++ :-D
harmful.cat-v.org/software/c++/linus
Some comments may only be visible to logged-in visitors. Sign in to view all comments.