8 ms·
We switched to Rust. Generally, are there specific domains or applications where C/C++ remain preferable? Many exist—but are there tasks Rust fundamentally cann
by VivaTechnics 1y ago
We switched to Rust.
Generally, are there specific domains or applications where C/C++ remain preferable? Many exist—but are there tasks Rust fundamentally cannot handle or is a weak choice?
- imadr 1y agoI haven't used Rust extensively so I can't make any criticism besides that I find compilation times to be slower than C
- ost-ing 1y agoI find with C/++ I have to compile to find warnings and errors, while with Rust I get more information automatically due to the modern type and linking systems. As a result I compile Rust significantly less times which is a massive speed increase. Rusts tooling is hands down better than C/++ which aids to a more streamlined and efficient development experience
- bch 1y ago> Rusts tooling is hands down better than C/++ which aids to a more streamlined and efficient development experience Would you expand on this? What was your C tooling/workflow that was inferior to your new Rust experience?
- simonask 1y agoNot the GP, but the biggest one is dependency management. Cargo is just extremely good. As for the language tooling itself, static and runtime analyzers in C and C++ (and these are table stakes at this point) do not come close to the level of accuracy of the Rust compiler. If you care about writing unsafe code, Miri is orders of magnitude better at detecting UB than any runtime analyzer I've seen for C and C++.
- johnisgood 1y agoPacman is extremely good, too, for C. :)
- simonask 1y agoPacman solves a different problem. Cargo manages your project's dependencies, not system packages.
- johnisgood 1y agoI know, but often that is all you need for C.
- uecker 1y agoI do not think package management should be done at the level of programming languages.
- adwn 1y agoStrictly speaking, Cargo isn't part of the Rust programming language itself. Cargo is a layer on top of Rust, and you can use the Rust compiler completely independently of Cargo. I think bazel, for example, can compile and handle dependencies without Cargo.
- simonask 1y agoI agree, it should be done at the project level - that is, if you care about portability, reproducibility, deployment, etc.
- ykonstant 1y agoI also hear that Async Rust is very bad. I have no idea; if anyone knows, how does async in Rust compare to async in C++?
- 01HNNWZ0MV43FF 1y agoI am yet to use async in c++, but I did work on a multi threaded c++ project for a few years Rust is nicer for async and MT than c++ in every way. I am pretty sure. But it's still mid. If you use Rust async aggressively you will struggle with the borrow checker and the architecture results of channel hell. If you follow the "one control thread that does everything and never blocks" you can get far, but the language does not give you much help in doing that style neatly. I have never used Go. I love a lot of Go projects like Forgejo and SyncThing. Maybe Go solved async. Rust did not. C++ did not even add good tagged unions yet.
- ViewTrick1002 1y ago> I also hear that Async Rust is very bad. Not sure where this is coming from. Async rust is amazing as long as you only mix in one more hard concept. Be it traits, generics or whatever. You can confidently write and refactor heavily multithreaded code without being deathly afraid of race conditions etc. and it is extremely empowering. The problem comes when trying to write async generic traits in a multithreaded environment. Then just throwing stuff at the wall and hoping something sticks will quickly lead you into despair.
- kazinator 1y agoThe popular C compilers are seriously slow, too. Orders of magnitude compared to C compilers of yesteryear.
- uecker 1y agoAdvantages of C are short compilation time, portability, long-term stability, widely available expertise and training materials, less complexity. IMHO you can today deal with UB just fine in C if you want to by following best practices, and the reasons given when those are not followed would also rule out use of most other safer languages.
- lifthrasiir 1y ago> short compilation time > IMHO you can today deal with UB just fine in C if you want to by following best practices In the other words, short compilation time has been traded off with wetware brainwashing... well, adjustment time, which makes the supposed advantage much less desirable. It is still an advantage, I reckon though.
- uecker 1y agoI do not understand what you are tying to say, but it seems to be some hostile rambling.
- lifthrasiir 1y agoNever meant to be hostile (if I indeed were, I would have question every single word), but sorry for that. I mean to say that best practices do help much but learning those best practices take much time as well. So short compilation time is easily offseted by learning time, and C was not even designed to optimize compilation time anyway (C headers can take a lot to parse and discard even when unused!). Your other points do make much more sense and it's unfortunate that first points are destructively interfering each other, hence my comment.
- uecker 1y agoSorry, maybe I misread your comment. There are certainly languages easier to learn than C, but I would not say C++ or Rust fall into this category. At the same time, I find C compilation extremely fast exactly because of headers. In C you can split interface and implementation cleanly between header and c-file and this enables efficient incremental builds. In C++ most of the implementation is in headers, and all the template processing is order of magnitude more expensive than parsing C headers. Rust also does not seem to have proper separate compilation.
- pizza234 1y agoYes, based on a few attempts chronicled in articles from different sources, Rust is a weak choice for game development, because it's too time-consuming to refactor.
- Defletter 1y agoYup, this one (https://news.ycombinator.com/item?id=43824640 https://news.ycombinator.com/item?id=43824640) comes to mind. The first comment says "Another failed game project in Rust", hinting that this is very common.
- bakugo 1y agoThere's also the fact that a lot of patterns that are commonly used in game development are fundamentally at odds with the borrow checker. Relevant: https://youtu.be/4t1K66dMhWk?si=dZL2DoVD94WMl4fI https://youtu.be/4t1K66dMhWk?si=dZL2DoVD94WMl4fI
- simonask 1y agoBasically all of those problems originate with the tradition of conflating pointers and object identity, which is a problem in Rust as soon as you have ambiguous ownership or incongruent access patterns. It's also very often not the best way to identify objects, for many reasons, including performance (spatial locality is a big deal). These problems go away almost completely by simply using `EntityID` and going through `&mut World` for modifications, rather than passing around `EntityPtr`. This pattern gives you a lot of interesting things for free.
- bakugo 1y agoThe video I linked to is long but goes through all of this. Pretty much nobody writing games in C++ uses raw pointers in entities to hold references to other related entities, because entities can be destroyed at any time and there's no simple way for a referring entity to know when a referenced entity is destroyed. Using some sort of entity ID or entity handle is very common in C++, the problem is that when implementing this sort of system in Rust, developers often end up having to effectively "work around" the borrow checker, and they end up not really gaining anything in terms of correctness over C++, ultimately defeating the purpose of using Rust in the first place, at least for that particular system.
- mrheosuper 1y agoRust can do inline ASM, so finding a task Rust "fundamentally cannot handle" is almost impossible.
- eru 1y agoThat's almost as vacuous as saying that Rust can implement universal Turing machines are that Rust can do FFI?
- bluetomcat 1y agoRust encourages a rather different "high-level" programming style that doesn't suit the domains where C excels. Pattern matching, traits, annotations, generics and functional idioms make the language verbose and semantically-complex. When you follow their best practices, the code ends up more complex than it really needs to be. C is a different kind of animal that encourages terseness and economy of expression. When you know what you are doing with C pointers, the compiler just doesn't get in the way.
- eru 1y agoPattern matching should make the language less verbose, not more. (Similar for many of the other things you mentioned.) > When you know what you are doing with C pointers, the compiler just doesn't get in the way. Alas, it doesn't get in the way of you shooting your own foot off, too. Rust allows unsafe and other shenanigans, if you want that.
- bluetomcat 1y ago> Pattern matching should make the language less verbose, not more. In the most basic cases, yes. It can be used as a more polished switch statement. It's the whole paradigm of "define an ad-hoc Enum here and there", encoding rigid semantic assumptions about a function's behaviour with ADTs, and pattern matching for control-flow. This feels like a very academic approach and modifying such code to alter its opinionated assumptions isn't funny.
- eru 1y agoHow is encoding all the assumptions and invariants badly in eg a bunch of booleans and nullable pointers any better?
- za_creature 1y ago> When you know what you are doing with C pointers, the compiler just doesn't get in the way. Tell me you use -fno-strict-aliasing without telling me. Fwiw, I agree with you and we're in good[citation needed] company: https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg01647.html https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg...
- mgaunard 1y agoRust forces you to code in the Rust way, while C or C++ let you do whatever you want.
- nicoburns 1y ago> C or C++ let you do whatever you want. C and C++ force you to code in the C and C++ ways. It may that that's what you want, but they certainly dont let me code how I want to code!
- mgaunard 1y agoThere is no C or C++ ways. It's widely known that every codebase is its own dialect.
- nicoburns 1y agoThere are lots of C and particularly C++ ways, but you're still restricted. Want to use methods in C: nope, you can't. Want language-level tagged unions and pattern matching in either language: nope. Same for guaranteed tail call optimisation and a bunch of other things. This is especially true for C which supports almost nothing (it doesn't even have a sensible array type!). But is also true for C++: while it supports a lot, it doesn't support everything.
- bigfishrunning 1y agowhat changes, in your opinion, would need to be made to the C array type to make it "sensible"? C's array is simplistic, but I don't think it's not "sensible"...
- mgaunard 1y agoconsider the C++ std::array, which exists to make arrays behave like normal objects. You can do the same in C by wrapping your array in a struct.
- 1y ago
- pjmlp 1y agoYes, all the industries where C and C++ are the industry standards like Khronos APIs, POSIX, CUDA, DirectX, Metal, console devkits, LLVM and GCC implementation,.... Not only you are faced with creating your own wrappers, if no one else has done it already. The tooling, for IDEs and graphical debuggers, assumes either C or C++, so it won't be there for Rust. Ideally the day will come where those ecosystems might also embrace Rust, but that is still decades away maybe.
- m-schuetz 1y agoPrototyping in any domain. It's nice to do some quick&dirty way to rapidly evaluate ideas and solutions.
- eru 1y agoI don't think C nor C++ were ever great languages for prototyping? (And definitely not better than Rust.)
- m-schuetz 1y agoPlease try not to be obnoxious and turn this into a language war.
- eru 1y agoHow is this obnoxious? C and C++ have their strengths, but rapid prototyping is generally not seen to be amongst them. This shouldn't be any more controversial than saying that pure Python is generally slow.
- m-schuetz 1y agoThey are pretty much the best choice for prototyping 3D apps and GPU algorithms. They're fast, powerful, and don't impose restrictions - you can do whatever and however. It also helps that CUDA is C++.
- eru 1y ago> Generally, are there specific domains or applications where C/C++ remain preferable? Well, anything were your people have more experience in the other language or the libraries are a lot better.
- teunispeters 1y agoembedded hardware, any processor Rust doesn't support (there are many), and any place where code size is critical. Rust has a BIG base size for an application, uselessly so at this time. I'd also love to see if it offered anything that could be any use in those spaces - especially where no memory allocation takes place at all. C (and to a lesser extent C++) are both very good in those spaces.
- steveklabnik 1y agoYou can absolutely make small rust programs, you just have to actually configure things the right way. Additionally, the Rust language doesn’t have allocation at all, it’s purely a library concern. If you don’t want heap allocations, then don’t include them. It works well. The smallest binary rustc has produced is like ~145 bytes.
- teunispeters 1y agoThat is far from my only concern. But it's good to see Rust is finally paying attention to binary sizes. And the overwhelming complexity of rust code is definitely not a gain when one is working in embedded spaces anyway. I am however really REALLY annoyed with the aggressive sales tactics of the rust community.
- steveklabnik 1y ago> But it's good to see Rust is finally paying attention to binary sizes. Just to be clear, this isn't a recent development, it has been this way for many years at this point.
- jandrewrogers 1y agoAn application domain where C++ is notably better is when the ownership and lifetimes of objects are not knowable at compile-time, only being resolvable at runtime. High-performance database kernels are a canonical example of code where this tends to be common. Beyond that, recent C++ versions have much more expressive metaprogramming capability. The ability to do extensive codegen and code verification within C++ at compile-time reduces lines of code and increases safety in a significant way.
- mckravchyk 1y agoIf you wanted to develop a cross-platform native desktop / mobile app in one framework without bundling / using a web browser, only QT comes to mind, which is C++. I think there are some bindings though.