4 ms·
I'm pretty sure a lot of fields would disagree with you. Last I checked game programming, OS development, embedded development and more were deeply invested in
by c0balt 1y ago
I'm pretty sure a lot of fields would disagree with you. Last I checked game programming, OS development, embedded development and more were deeply invested in either C or more often C++, especially when RT tasks were involved or vendor-provided compilers are required.
Rust just doesn't have close to the same type of adoption/support yet, especially when considering various embedded platforms.
- holowoodman 1y agoThere is a big big difference between C and C++. The article is about C++, which is being replaced by Rust imho. C is different, and far more frequently used for embedded or OS development. Don't know about games, but last I looked, stuff like unity was C#, so something else yet again.
- jonathrg 1y agoC++ is widely used in embedded. Most compilers support it. Usually you turn some things off (e.g. -fno-rtti, -fno-exceptions) and try to stick to some sane subset of the ++.
- com2kid 1y agoC++ in embedded is basically C with classes. It is a nice simple language and often doesn't even include templates (or if it does they are very simple data structures that are not even heap allocated). C++ as C with classes is a pretty good language!
- deleted 1y ago[deleted]
- grg0 1y agoGame engines (the thing that C# runs on top of) are written in C++. As is the C#/.NET runtime. As is anything that requires careful management of memory for performance. Application code is perfectly reasonably written in managed languages, but not so for the things that run underneath.
- ShinTakuya 1y agoThere's nothing inherent about C++ that makes it more suited than Rust for game engines though, Rust supports careful management of memory too. Of course, nothing besides inertia (i.e. Libs, existing code, etc.). And that of course is more than big enough of a reason to stick with it.
- grg0 1y agoRust supports careful management of memory at the expense of unsafety, at which point that particular area of the code offers no benefit over C/C++, let alone value in a rewrite. There is no type system for reinterpreting bits of memory. And for the safe parts, the posts that I've read from people who have spent a non-trivial amount of effort with the language do not paint a clear picture either on whether there was really a benefit to the language overall. So to say that "the world has moved on" in light of all of this is pure hubris.
- drwu 1y agoIt is a pitty that - GCC switched from C to C++ - CUDA switched from C to C++ But I can understand the decision, and at that time , C++ frontend features and libs were a little bit less horrible.
- deeznuttynutz 1y agoIt's a pity? Please explain in detail how alternatives would have worked better for GCC and CUDA. Also, if you could share some historical context about how those alternatives could realistically have been implemented at the time, that would be helpful too. I love to hear all the "would've" and "should've" scenarios.
- j16sdiz 1y agoLast time I checked, MSVC don't want to implement C99/newer and instead focus on C++.
- drwu 1y agoTo be fair, MSVC has the most C99 stuffs. What is mainly missing for porting (my) programs is the native complex number. But we have Intel compiler for free on Windows, which is fully compatible with the C/C++ standard and produces faster binaries. The C++ frontend of MSVC handles (the common) compiler-specific language extensions differently than the other compilers. Besides, its pre-processor behaves differently too. It is now good that there is a clang frontend for MSVC.
- feelamee 1y agohaha, fun fact - Unity is C++ code base. You need to look deeper