As a full time C++ dev I think the biggest argument is missing in this article: The consistent build and package management ecosystem.
With rust/cargo _it_ _just_ _works_. So many hours each month are wasted because of weird linker errors between linker targets, that cannot find a definition of a struct, dealing with broken external dependencies (yes I use vcpkg for that, still happens) and different build tools. I did get better the last few years, but still miles away from what Rust offers.
"Minor" semver updates to crates breaking things via e.g. unexpected MSRV bumps is pretty common too, with some resulting bitrot. That said, I agree with you that things in Rust are at least better. Imperfect, but better.
What the article completely glosses over is the second part of Russinovich's sentence: "it's time to halt starting any new projects in C/C++ and use Rust for those scenarios where a non-GC language is required." - now, I know that there are lots of programmers who think that of course, their project needs every last drop of performance the CPU can give them, and are willing to saddle themselves with the complexities of Rust memory management (or the dangers of C/C++ memory management) to get it, but still, it's a good idea to consider if a GC language wouldn't be a better fit.
And also a well implemented GC (ie probably not python) is more efficient than malloc/free by miles (the way they do it is that they just increment the pointer to the end of the slab without any check ; the MMU will trigger if it's unhappy).
So either you manage your memory by slabs yourself without a GC, but you still don't have access to some code styles (like creating a ton of short lived objects), or you pay your malloc/free dues.
Sometimes, like if you are messing with graphs pointers and malloc (because it's not yet time to refactor to introduce a memory slab system), you can get the worst of both world: you allocate slowly with malloc, but you don't know when to exactly deallocate, so you still have to retain everything until you can nuke the entire graph at once, and each element will require a slow free().
Maybe it's close but the ecosystem of libraries needs to mature a lot more from my recent experience working with it.
I found open source stuff is just wrong, or maintained by people who don't have the proper expertise to be writing these libraries. I'm not about to blast anyone specifically but it was tiresome to dig into libraries I would need and find fundamental things I don't think we're right.
A common attitude around performance and handing edge cases. I often hear things like oh well most people don't care about that or your doing it wrong.
It feels like there was a rush of people to try to fill the void that shouldn't have been rushing to write libraries with generic names
> It's time to retire the concept of creating new programming languages to "fix" old ones.
Is LITERALLY the ONLY way to fix a language. No amount of lipstick can fix C/C++, precisely because is an established language (that amounts for any lang in the moment is settled AND widespread).
But C/C++ is unique in a particular way: Their users are the MOST stubborns of all!
And Rust is the first time the arguments for start new things on C/C++ because reasons are not very very small...
This feels like how the emergence of Modula / Pascal / Delphi must have felt like. There really was a lot to say for Pascal like languages in the C era.
However, time has not been kind to the early adopters back then.
So I'm inclined to hold out just a little while longer. Let's see if Rust can maintain its momentum.
I doing a lot of C++ and I tried to use Rust for some projects and it was really painful. I like the language and cargo is just so much better than cmake.
Unfortunately I working mostly on cross platform desktop applications and for that Rust doesn't really have any good libraries. The pure rust library are missing too much features that I consider essential (accessibility, property bindings, declarative ui language, ...). I then looked at bindings for Qt are also missing important stuff like models. I also looked at the GTK bindings and those are a lot more polished but the code example I found where still not really nice read in comparison with the Vala code example I saw.
I'm still hoping that this will at some point changes.l, because yeah sometimes C++ can also be painful, particularly the C bits.
> Unfortunately I working mostly on cross platform desktop applications and for that Rust doesn't really have any good libraries.
This can be said about most alternatives to C/C++, though. I tried doing the same in D, Nim, even Golang - and every time I tried to create a decent multi-platform GUI I hit a wall. There were multiple projects, some outdated, some abandoned, and the rest was just incomplete.
I am currently programming a processor using C with 64 bytes of RAM. I use and reuse global variables because I can't risk the stack eating that up. Do I need Rust?
28 comments
[ 3.0 ms ] story [ 64.9 ms ] threadWith rust/cargo _it_ _just_ _works_. So many hours each month are wasted because of weird linker errors between linker targets, that cannot find a definition of a struct, dealing with broken external dependencies (yes I use vcpkg for that, still happens) and different build tools. I did get better the last few years, but still miles away from what Rust offers.
https://github.com/microsoft/win32metadata/issues/1274
"Minor" semver updates to crates breaking things via e.g. unexpected MSRV bumps is pretty common too, with some resulting bitrot. That said, I agree with you that things in Rust are at least better. Imperfect, but better.
Sometimes, like if you are messing with graphs pointers and malloc (because it's not yet time to refactor to introduce a memory slab system), you can get the worst of both world: you allocate slowly with malloc, but you don't know when to exactly deallocate, so you still have to retain everything until you can nuke the entire graph at once, and each element will require a slow free().
Perhaps it would be healthier for Rust to have competition?
https://www.linux.com/audience/developers/hacking-the-linux-...
https://github.com/alkhimey/Ada_Kernel_Module_Framework
https://alire.ada.dev/
Nvidia also chose Spark; a built in subset of Ada as being more cost effective for secure code than C++.
https://youtu.be/2YoPoNx3L5E
Assembly is also supported by Ada and I found it far easier to add than with C even.
C interface support is also excellent.
I found open source stuff is just wrong, or maintained by people who don't have the proper expertise to be writing these libraries. I'm not about to blast anyone specifically but it was tiresome to dig into libraries I would need and find fundamental things I don't think we're right.
A common attitude around performance and handing edge cases. I often hear things like oh well most people don't care about that or your doing it wrong.
It feels like there was a rush of people to try to fill the void that shouldn't have been rushing to write libraries with generic names
So, microcontrollers basically.
Eventually kids will stop learning C/C++ and the talent pool will dry up.
This is software, and it is updateable. We need to stop thinking in discrete terms and start thinking in continuous terms.
If you do not think C and C++ are good, propose solutions to their committees instead of clogging up the digital space with flamebait.
Sorry, I cannot do that due to backwards compatibility, closing request.
Is LITERALLY the ONLY way to fix a language. No amount of lipstick can fix C/C++, precisely because is an established language (that amounts for any lang in the moment is settled AND widespread).
But C/C++ is unique in a particular way: Their users are the MOST stubborns of all!
And Rust is the first time the arguments for start new things on C/C++ because reasons are not very very small...
However, time has not been kind to the early adopters back then.
So I'm inclined to hold out just a little while longer. Let's see if Rust can maintain its momentum.
Rust feels like really good language in compare to those minefields
Unfortunately I working mostly on cross platform desktop applications and for that Rust doesn't really have any good libraries. The pure rust library are missing too much features that I consider essential (accessibility, property bindings, declarative ui language, ...). I then looked at bindings for Qt are also missing important stuff like models. I also looked at the GTK bindings and those are a lot more polished but the code example I found where still not really nice read in comparison with the Vala code example I saw.
I'm still hoping that this will at some point changes.l, because yeah sometimes C++ can also be painful, particularly the C bits.
This can be said about most alternatives to C/C++, though. I tried doing the same in D, Nim, even Golang - and every time I tried to create a decent multi-platform GUI I hit a wall. There were multiple projects, some outdated, some abandoned, and the rest was just incomplete.