Is it time to retire C and C++ for Rust in new programs? | Hacker News Reader

Is it time to retire C and C++ for Rust in new programs?

theregister.com

18 pointsrntn28 comments

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().

Python is not a GC language, at least not primarily. It's reference-counted with a backup GC for reference cycles.

Reference counting itself is often considered a for of garbage collection. It's not consistent but it is common.

Ada offers security and simplicity and is already part of GCC but also has llvm now. Linux kernel drivers have also been demonstrated.

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 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.

Yeah I would say GUIs are the biggest missing feature of Rust. Qt is probably the one thing that would make me stick with C++.

> 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.

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.

There is still the occasional incredibly subtle link time fuckery in Rust.

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.

Yeah I still prefer writing C++, but Cargo is so incredibly smooth

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

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?

Sir, you need not a better language, but a better processor.

I can power mine off a coin cell.

What's the processor called?

ATtiny13A

64 bytes of RAM? Wouldn't ASM be easier at that point? Or is your code separate from that 64 bytes?

Yes, I have a whole 1K for program, bliss!

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.

Huge related discussion last week: https://news.ycombinator.com/item?id=32905885

I hope

Rust feels like really good language in compare to those minefields

For most such projects, yes.

> where a non-GC language is required

So, microcontrollers basically.

C/C++ are now Perl. They'll continue to be used in legacy applications, but Rust should be used in new places.

Eventually kids will stop learning C/C++ and the talent pool will dry up.

It'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.

>If you do not think C and C++ are good, propose solutions to their committees

Sorry, I cannot do that due to backwards compatibility, closing request.

> 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...

Reply on news.ycombinator.com