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 d…
Is it time to retire C and C++ for Rust in new programs?
11–20 of 29 posts
Re: Is it time to retire C and C++ for Rust in new programs?
#12Re: Is it time to retire C and C++ for Rust in new programs?
#13Rust feels like really good language in compare to those minefields
Re: Is it time to retire C and C++ for Rust in new programs?
#14It's time to retire the concept of creating new programming languages to "fix" old ones. 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.
Re: Is it time to retire C and C++ for Rust in new programs?
#15What 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…
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().
Re: Is it time to retire C and C++ for Rust in new programs?
#16Unfortunately 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.
Re: Is it time to retire C and C++ for Rust in new programs?
#17I 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,…
Re: Is it time to retire C and C++ for Rust in new programs?
#18What 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…
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…
Re: Is it time to retire C and C++ for Rust in new programs?
#19Re: Is it time to retire C and C++ for Rust in new programs?
#20Earlier quoted context omitted.
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…
Python is not a GC language, at least not primarily. It's reference-counted with a backup GC for reference cycles.