Rust vs C++
its cyclic.
like an atomic clock, on a 5 year cycle, someone copies the c++ language, hacks on it a bit, and bam 'the bestest greatest newest thing since the wheel' that everyone must now use is now storming the internet. This gives us gems like java, that forgot to provide unsigned integers and is incapable of having the function y=f(x) in code, as 'improvements'.
Rust isnt bad, but it adds a layer of slow. You can't have extra safety without checking things, and checking things costs cpu clocks. Its that simple. That may be desirable for many things, but we already have a dozen slower languages that do this, so its nothing new (and rust isnt new either).
My take on it is pretty simple. Copying c++ and taking away its power is a failure to me out of the gate. I have no use for a language that does less than what I already know (or just does it slower). And what we NEVER GET is a language that takes c++ and *adds more to it without adding overhead* and *is actually better*. It NEVER happens. We do have some potent side-grade languages that can do some things easily that C++ requires a lot of junk to accomplish, like database connectivity can be annoying in c++ and 2 lines in python, but python is 2 orders of magnitude slower for simple integer math (basic py, not extensions).
like an atomic clock, on a 5 year cycle, someone copies the c++ language, hacks on it a bit, and bam 'the bestest greatest newest thing since the wheel' that everyone must now use is now storming the internet. This gives us gems like java, that forgot to provide unsigned integers and is incapable of having the function y=f(x) in code, as 'improvements'.
Rust isnt bad, but it adds a layer of slow. You can't have extra safety without checking things, and checking things costs cpu clocks. Its that simple. That may be desirable for many things, but we already have a dozen slower languages that do this, so its nothing new (and rust isnt new either).
My take on it is pretty simple. Copying c++ and taking away its power is a failure to me out of the gate. I have no use for a language that does less than what I already know (or just does it slower). And what we NEVER GET is a language that takes c++ and *adds more to it without adding overhead* and *is actually better*. It NEVER happens. We do have some potent side-grade languages that can do some things easily that C++ requires a lot of junk to accomplish, like database connectivity can be annoying in c++ and 2 lines in python, but python is 2 orders of magnitude slower for simple integer math (basic py, not extensions).
Last edited on
Hmmmmmm, I remember reading "the experts" were kvetching about C "losing it" when Saint Bjarne first introduced C++ (C With Classes) to the world.
Never happened.
Never happened.
It's not.
Rust almost strikes me as a single-issue language, where there was only one problem that they were highly invested in solving, and that's memory safety guaranteed at compile-time without using garbage collection. To their credit, they did a better job of it than I expected them to, but it's inherently restrictive in cases where the lifetime+ownership model starts getting more complex than what could be handled by religious std::unique_ptr use in C++.
Don't believe me? Here an anecdote from an actual Rust developer, who was writing two major projects in Rust, but gave up because the ownership model used by an underlying C library was to complex for Rust to handle cleanly: http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-in-c.html
And sure, you can use "unsafe", but at that point, you are opting out of using one of the main reasons to use Rust.
I do like some of Rust's syntax more than C++'s (even though much of it is fairly arcane). Pattern matching is always nice to have. Having a single dependency management+build system that most people will use is one of the few things I miss from Javaland. Philosophically, I prefer Rust's structs+traits system, and I'll gladly take Rust's error handling model over C++'s exceptions.
However, it doesn't come close to having C++'s immensely powerful compile-time programming, it sacrifices power for safety in a way that makes it difficult to port to, it's not even complete on the safety front if you're going to use it in safety-critical environments (seriously, compare it to Ada), and it doesn't even have a formal language spec (that I could find on their website).
-Albatross
Rust almost strikes me as a single-issue language, where there was only one problem that they were highly invested in solving, and that's memory safety guaranteed at compile-time without using garbage collection. To their credit, they did a better job of it than I expected them to, but it's inherently restrictive in cases where the lifetime+ownership model starts getting more complex than what could be handled by religious std::unique_ptr use in C++.
Don't believe me? Here an anecdote from an actual Rust developer, who was writing two major projects in Rust, but gave up because the ownership model used by an underlying C library was to complex for Rust to handle cleanly: http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-in-c.html
And sure, you can use "unsafe", but at that point, you are opting out of using one of the main reasons to use Rust.
I do like some of Rust's syntax more than C++'s (even though much of it is fairly arcane). Pattern matching is always nice to have. Having a single dependency management+build system that most people will use is one of the few things I miss from Javaland. Philosophically, I prefer Rust's structs+traits system, and I'll gladly take Rust's error handling model over C++'s exceptions.
However, it doesn't come close to having C++'s immensely powerful compile-time programming, it sacrifices power for safety in a way that makes it difficult to port to, it's not even complete on the safety front if you're going to use it in safety-critical environments (seriously, compare it to Ada), and it doesn't even have a formal language spec (that I could find on their website).
-Albatross
@jonnin and @Furry Guy nailed my own reactions to the question, almost without considering the language being compared, as it has been with Java (for years), C#, D, Haskell...
...and kudos to @Furry Guy for pointing out that C is still "there".
As long as there are operating systems, there will be C.
Part of that is inertia, typically considered a derogatory force against change. In this case, though, the roots of all modern operating systems is still UNIX. Even though Linux may well be superior, UNIX DNA is still its core, and even Windows (from NT forward) is based on concepts brought forward decades earlier by UNIX.
C was purpose built to write UNIX for portability to new processors over time.
The inertia anchoring C in that context is a positive force, lest we lose that continuity these operating systems demonstrated for decades. I'd still prefer to use C++ if writing for an operating system, but for Linux that won't happen as long as Torvalds helms that chair. The API interfaces for these operating system is based on C functions.
At this point every important, formal product relied upon is written, at least largely, in C++. From Photoshop to AutoCAD, 3DS Max to various SQL/NoSQL engines, from web servers to word processors. Everywhere we've seen products written in other languages as their primary core, we are left wanting.
Java was supposed to destroy not only C/C++, but Windows, Linux, UNIX and all other operating systems, by making operating systems irrelevant while making other languages irrelevant. I know professors teaching Java in the late 90's who declared Java was the best language ever developed.
Then, Microsoft went to war against all things Java and essentially won.
C# and Java do have a place, but not where C++ is important.
Rust is late in the process compared to D, and D is quite superior on many counts, but still will not take a place against C++.
Inertia is again at the root of why.
D can consume C++ libraries, as can Rust, given technical prerequisites. So can C# and Java, Python and Visual Basic.
There is weak or no motivation to prefer another language, like D or Rust, where the largest volume of important libraries are still in C and C++ for consumption. There's no motivation to build product cores in multiple languages. Where multiple languages appear, it is usually for script and extension authorship, and then usually for convenience of language preference of certain limited target audiences.
Language preference for such things are associated with safety and rapid development by lesser qualified (and therefore less expensive) personnel.
Ultimately we've seen this history repeat enough to know why.
Java was "wonderful" to those that "loved" it. It was going to eliminate all that nasty stuff experienced as C and C++ programmers.
Until Java was incrementally upgraded. After layer upon layer, the same kind of issues Java promised to eliminate re-appeared in new flavors.
C# was better at this, I have to admit, but other issues of performance and resource consumption relegate the products made with it to a lesser competitive status when compared to native output.
While C++ can be nasty, with the multiple ways of doing the same thing, layered epochs of conventions, by the time a "new" language comes to public attention, C++ advances with something similar.
What's left are languages which protect programmers from themselves, which is a bit insulting if liberating, but usually at a cost ultimately not worth a complete transfer out of C++.
It's "good" to know multiple languages, and one may say a requirement, but expertise can only genuinely develop with experience. By definition that requires a language of some continuity over time which no "new" language can provide.
New programmers may find such languages enticing. If you limited such a question to young, emerging professionals you'd likely have a very different "survey" from a more generalized accounting of the industry at large. Ultimately these young developers must have jobs, or at least projects to participate in which bring enough recognition to get one, and that brings them against the inertia of an industry already steeped in C++ as a core, with C as the OS origins, and all else are recent outgrowths.
If C++ is ever to fade out of such favor it will take decades, and inattention against trends which genuinely could no longer benefit from C++. It isn't just whether or not an emerging language is good, with desirable characteristics, but if C++ ever becomes unsuitable for the computers built in the decades ahead.
I can't successfully posit a path where that happens. The computers of that future are too far away to imagine, and likely require major theoretical advancements like those foundations which gave us the present technologies.
...and kudos to @Furry Guy for pointing out that C is still "there".
As long as there are operating systems, there will be C.
Part of that is inertia, typically considered a derogatory force against change. In this case, though, the roots of all modern operating systems is still UNIX. Even though Linux may well be superior, UNIX DNA is still its core, and even Windows (from NT forward) is based on concepts brought forward decades earlier by UNIX.
C was purpose built to write UNIX for portability to new processors over time.
The inertia anchoring C in that context is a positive force, lest we lose that continuity these operating systems demonstrated for decades. I'd still prefer to use C++ if writing for an operating system, but for Linux that won't happen as long as Torvalds helms that chair. The API interfaces for these operating system is based on C functions.
At this point every important, formal product relied upon is written, at least largely, in C++. From Photoshop to AutoCAD, 3DS Max to various SQL/NoSQL engines, from web servers to word processors. Everywhere we've seen products written in other languages as their primary core, we are left wanting.
Java was supposed to destroy not only C/C++, but Windows, Linux, UNIX and all other operating systems, by making operating systems irrelevant while making other languages irrelevant. I know professors teaching Java in the late 90's who declared Java was the best language ever developed.
Then, Microsoft went to war against all things Java and essentially won.
C# and Java do have a place, but not where C++ is important.
Rust is late in the process compared to D, and D is quite superior on many counts, but still will not take a place against C++.
Inertia is again at the root of why.
D can consume C++ libraries, as can Rust, given technical prerequisites. So can C# and Java, Python and Visual Basic.
There is weak or no motivation to prefer another language, like D or Rust, where the largest volume of important libraries are still in C and C++ for consumption. There's no motivation to build product cores in multiple languages. Where multiple languages appear, it is usually for script and extension authorship, and then usually for convenience of language preference of certain limited target audiences.
Language preference for such things are associated with safety and rapid development by lesser qualified (and therefore less expensive) personnel.
Ultimately we've seen this history repeat enough to know why.
Java was "wonderful" to those that "loved" it. It was going to eliminate all that nasty stuff experienced as C and C++ programmers.
Until Java was incrementally upgraded. After layer upon layer, the same kind of issues Java promised to eliminate re-appeared in new flavors.
C# was better at this, I have to admit, but other issues of performance and resource consumption relegate the products made with it to a lesser competitive status when compared to native output.
While C++ can be nasty, with the multiple ways of doing the same thing, layered epochs of conventions, by the time a "new" language comes to public attention, C++ advances with something similar.
What's left are languages which protect programmers from themselves, which is a bit insulting if liberating, but usually at a cost ultimately not worth a complete transfer out of C++.
It's "good" to know multiple languages, and one may say a requirement, but expertise can only genuinely develop with experience. By definition that requires a language of some continuity over time which no "new" language can provide.
New programmers may find such languages enticing. If you limited such a question to young, emerging professionals you'd likely have a very different "survey" from a more generalized accounting of the industry at large. Ultimately these young developers must have jobs, or at least projects to participate in which bring enough recognition to get one, and that brings them against the inertia of an industry already steeped in C++ as a core, with C as the OS origins, and all else are recent outgrowths.
If C++ is ever to fade out of such favor it will take decades, and inattention against trends which genuinely could no longer benefit from C++. It isn't just whether or not an emerging language is good, with desirable characteristics, but if C++ ever becomes unsuitable for the computers built in the decades ahead.
I can't successfully posit a path where that happens. The computers of that future are too far away to imagine, and likely require major theoretical advancements like those foundations which gave us the present technologies.
inertial is only part of it. It is a critical part, but again, every new language is either slower, reduced in power, or both vs c++ and even C. I think that inertia would be overcome (if slowly) if/when something genuinely better appeared (esp if c++ did not grow to do the new things, which it currently does at a pretty good pace).
I was half kidding, but its true just the same... this week I told a younger guy at work who is a fan of the easy to use languages that once moore's law ends and we can't make a better machine we can still double our computing capacity at least twice by just rewriting everything in a real language and trimming the fat :)
As for the future, the non binary computer ideas may need something different. But time will tell. That is likely the next big step, is some sort of inexpensive, useful, quantum device.
I was half kidding, but its true just the same... this week I told a younger guy at work who is a fan of the easy to use languages that once moore's law ends and we can't make a better machine we can still double our computing capacity at least twice by just rewriting everything in a real language and trimming the fat :)
As for the future, the non binary computer ideas may need something different. But time will tell. That is likely the next big step, is some sort of inexpensive, useful, quantum device.
Last edited on
| Rust vs C++ - is C++ losing it? |
The current programming languages are designed to operate on sequential digital computers. Designed to abstract the CPU/GPU instruction codes into an easily understandable format for us humans.
If/When Quantum computers become mainstream, or at least outside the realm of scientific laboratory curiosities, the need for abstracting the quantum instruction sets will be tackled.
Is that already happening? I honestly don't know because I haven't delved into the field of Quantum Computing other than reading a book and a few online articles about it.
My 2 cents: (please pardon the bump)
Support for a language is not just about the technicalities of that language.
It's as much or even more about the things around it.
The amount of documentation (or literature in general) in various human languages.
The size of the community that uses the language.
The availability of development tools for various operating systems and environments.
The stability and scope of libraries (whithout counting wrappers).
The level of compatibility for older versions of the same language.
It's so many things that weigh more than just the specs.
Looking at Rust with those things in mind doesn't give me high hopes for it's future.
Support for a language is not just about the technicalities of that language.
It's as much or even more about the things around it.
The amount of documentation (or literature in general) in various human languages.
The size of the community that uses the language.
The availability of development tools for various operating systems and environments.
The stability and scope of libraries (whithout counting wrappers).
The level of compatibility for older versions of the same language.
It's so many things that weigh more than just the specs.
Looking at Rust with those things in mind doesn't give me high hopes for it's future.
Topic archived. No new replies allowed.