8 ms·
Exactly, it's all about the ecosystem and very little about the language features
by hot_gril 3y ago
Exactly, it's all about the ecosystem and very little about the language features
- meheleventyone 3y agoDisagree the adoption of C++ was more about Moore's law than ecosystem, although having compilers that were beginning to not be completely rubbish also helped.
- pavlov 3y agoAlso C++ could be adopted incrementally by C developers. You could use it as “C with classes”, or just use operator overloading to make vector math more tolerable, or whatever subset that you happened to like. So there’s really three forces at play in making C++ the standard: 1) The Microsoft ecosystem. They literally stopped supporting C by not adopting the C99 standard in their compiler. If you wanted any modern convenience, you had to compile in C++ mode. New APIs like Direct3D were theoretically accessible from C (via COM) but in practice designed for C++. 2) Better compilers and more CPU cycles to spare. You could actually count on the compiler to do the right thing often enough. 3) Seamless gradual adoption for C developers. Rust has a good compiler, but it lacks that big ticket ecosystem push and is not entirely trivial for C++ developers to adopt.
- pcwalton 3y agoI'd say Rust does have that big ticket ecosystem push. Microsoft has been embracing Rust lately, with things like official Windows bindings [1]. The bigger problem is just inertia: large game engines are enormous. [1]: https://github.com/microsoft/windows-rs https://github.com/microsoft/windows-rs
- zozbot234 3y agoYes, the Google folks are also funding efforts to improve Rust/C++ interop, per https://security.googleblog.com/2024/02/improving-interoperability-between-rust-and-c.html https://security.googleblog.com/2024/02/improving-interopera...
- Sn0wCoder 3y agoThanks for the link. This one was also posted awhile back in a rust comment and when I first read it, I thought Google had used Rust in the V8 sandbox, but re-reading it seems that the article uses Rust as an ‘example’ of a memory safe language but does not explicitly say that it uses Rust. Maybe someone with more knowledge can confirm that Rust was (or was not) used in the V8 Google Chrome sandbox example…. https://v8.dev/blog/sandbox https://v8.dev/blog/sandbox
- steveklabnik 3y agoRust is not used in V8, to my knowledge.
- meheleventyone 3y agoI'd say the inertia is far more social than codebase size related. Right now whilst there are pockets of interest there is no broader reason to switch. Bevy as the leading contender isn't going to magic it's way to being capable of shipping AAA titles unless a studio actually adopts it. I don't think it's actually shipped a commercially successful indie game yet. Also game engines emphatically don't have to be huge. Look at Balatro shipping on Love2d.
- pcwalton 3y agoThere are a few successful games like Tunnet [1] written in Bevy. [1]: https://store.steampowered.com/app/2286390/Tunnet/ https://store.steampowered.com/app/2286390/Tunnet/
- meheleventyone 3y agoLooks cool and well received but at ~300ish reviews hardly a shining beacon if we extrapolate sales from that. But I'll say that's a good start.
- TillE 3y agoSpeaking as a Godot supporter, I don't think sales numbers of shipped games are relevant to anyone except the game's developer. When evaluating a newer technology, the key question is: are there any major non-obvious roadblocks? A finished game (with presumably decent performance) tells you that if there are problems, they're solvable. That's the data.
- pcwalton 3y agoAgreed. We've learned a lot from Godot, by the way. I consider all us open source engines to be in it together :)
- meheleventyone 3y agoGame engines are tools not fan clubs. It’s reasonable to judge them on their performance for which they are designed. As someone who cares about the commercial viability of their technology choices this is a small but positive signal. What it tells me is someone shipped something and it wasn’t awful. Props to them!
- withinrafael 3y agoRepo contributor here, just to curb some expectations a bit: it's one very smart guy (Kenny), his unpaid volunteer sidekick (me), and a few unpaid external contributors. (I'm trying to draw a line between those with and without commit access, hence all the edits.) There's no other internal or external Microsoft /support/ that I'm aware of. I wouldn't necessarily use it as a signal of the company's intentions at this time. That said, there are Microsoft folks working on the Rust compiler, toolchain, etc. side of things too. Maybe those are better indicators!
- heavyset_go 3y agoThat's disappointing on Microsoft's part, because their docs make it seem like windows-rs is the way of the future. Thanks for your work, though!
- smileson2 3y agoI wish Microsoft had any direction on the 'way of the future' for native apps on Windows
- travisgriggs 3y agoIf they did publish a “way of the future” direction, would you believe them? Fool me N times then shame on them, fool me N+1 times, then shame on me sort of thing.
- tracker1 3y agoI'd have bought into MAUI if there was Linux support in the box.
- somenameforme 3y agoThe most infuriating thing is their habit of rebuilding things just about the time they reach a mature and highly stable state, creating an entirely new unstable and unreliable system. And then the time that system almost reaches a stable state - it's scrapped and it starts all over again. WPF -> UWP -> WinUI -> WinUI 2 -> WinUI 3 is just such a ridiculous chain. WPF was awesome, highly extensible, and could have easily and modularly been extended indefinitely - while also maintaining its widespread (if unofficial) cross platform support and just general rock solid performance/stability. Instead it's the above pattern over and over and over. And now it seems WinUI 3 is also dead, alas without even bothering with a replacement. Or maybe that's XAMARIN, wait I mean MAUI? Not entirely joking - I never bothered to follow that seemingly completely parallel system doing pretty much the same things. On the bright side this got me to finally migrate away from Microsoft UI solutions, which has made my life much more pleasant since!
- jacobgorm 3y agoSo far I am way less productive in rust than in any language I've ever used for actual work, so to rewrite an entire game engine would seem like commercial suicide.
- chromatin 3y ago"so far" is doing a lot of heavy lifting there =) I was the same the first two times I tried to use rust (earnestly). However, one day it just "clicked" and my productivity exceeds that of almost anything else, for the specific type of work I'm doing (scientific computation)
- vacuity 3y agoI think we shouldn't expect any language to lead different programmers to the same experiences. Rust has the inital steep learning curve, and after that it's a matter of taste whether one is willing to forge on and turn it into a honed tool. Also, I think it's clear that Rust excels in some fields far more naturally than in others. Making blanket statements about how Rust, or any language, is (un)productive is a disservice to everyone.
- synergy20 3y agonot true anymore, c11 and c17 are either supported or coming https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/ https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-...
- meheleventyone 3y agoNot really relevant to 30 years ago though.
- IggleSniggle 3y agoThat description of problems bodes well for Zig
- SunlitCat 3y agoTheoretically accessible describes the experience of trying to use D3D from C very well! Was trying to use it with some kind of gcc for windows. The C++ part was still lacking some required features, so it was advised to use D3D from C instead C++. There were some helper macros, but overall I was glad when Microsoft started to release their Express (and later Community) Editions of Visual Studio.
- flohofwoe 3y agoI access D3D(11) from C in my libraries and tbh it's not any different from C++ in terms of usability (only difference is that the "this" argument and vtable indirection is implicit in C++, but that's just syntax sugar that can be wrapped in a macro in C).
- deleted 3y ago[deleted]
- georgeecollins 3y agoI worked on many of Activision's games 1995-2000 and C++ was the overwhelming choice of programming language for PC games. C was more common for console. In 1996 the quality of MSFT IDE/ Compiler, plus the CPUs available at the time was such that it could take an hour to compile a big game. By 1998 it was a few minutes. As I recall I think MSFT purchased another companies compiler and that really changed Visual Studio.
- meheleventyone 3y agoI was a teenager at that point. I learnt C in the early 90s and C++ after 96 IIRC. Didn’t start professionally in games until 2004 though!
- philiplu 3y agoI was a developer on the Microsoft C++ compiler team from 1991 to 2006. We definitely didn't purchase someone else's compiler in that time. We looked at the EDG front end at various times but never moved over to it while I was there. Perhaps the speed-up you remember had something to do with the switch-over from 16 bits to 32, which would have been the early to mid 90s. Or you're thinking of Microsoft's C compiler starting from Lattice C, back in the 80s before my time. There was also a lot of work done on pre-compiled headers to speed compilation in the latter half of the 90s (including some that I was responsible for).
- throwaway2037 3y agoI heard that early versions of C++ IntelliSense from Visual Studio used Edison Design Group's (EDG) front end. Is that true? No trolling here -- honest question. If yes, are they still using it now?
- philiplu 3y agoNot true by the time I retired in 2007, but I've got a vague memory of talking to someone on the C++ front-end team some time after that and EDG for IntelliSense being mentioned. So no idea if that's really true or not, and if so, whether that's true today. I was heavily involved in the first version of C++ IntelliSense, roughly 1997?, and it was all home-grown. It was also a miracle it worked at all. I've blocked out most of the ugly details from my memory, but parsing on the fly with a fast enough response time to be useful in the face of incomplete information about which #if branches to take and, especially, template definitions was a tower of heuristics and hacks that barely held together. Things are much better nowadays with more horsepower available to replace those heuristics.
- delfinom 3y agoKind of both in my opinion. But rust is bringing nothing to the table that games need. At best rust fixes crash bugs and not the usual logic and rendering bugs that are far more involved and plague users more often.
- pcwalton 3y agoThe ability of engines like Bevy to automatically schedule dependencies and multithread systems, which relies on Rust's strictness around mutability, is a big advantage. Speaking as someone who's spent a long time looking at Bevy profiles, the increased parallelism really helps. Of course, you can do job queuing systems in C++ too. But Rust naturally pushes you toward the more parallel path with all your logic. In C++ the temptation is to start sequential to avoid data races; in systems like Bevy, you start parallel to begin with.
- NBJack 3y agoAside from a physics simulation, I'm curious as to what you think would be a positive cost benefit from that level of multithreading for the majority of game engines. Graphical pipelines take advantage of the concept but offload as much work as possible to the GPU.
- Animats 3y agoIn big-world high-detail games, the rendering operation wants so much time that the main thread has time for little else. There's physics, there's networking, there's game movement, there's NPC AI - those all need some time. If you can get that time from another CPU, rendering tends to go faster. I tend to overdo parallelism. Load this file into a Tracy profile, version 0.10.0, and you can see what all the threads in my program are doing.[1] Currently I'm dealing with locking stalls at the WGPU level. If you have application/Rend3/WGPU/Vulkan/GPU parallism, every layer has to get it right. Why? Because the C++ clients hit a framerate wall, with the main thread at 100% and no way to get faster. [1] https://animats.com/sl/misc/traces/clockhavenspeed02.tracy https://animats.com/sl/misc/traces/clockhavenspeed02.tracy
- 3y ago
- jacobgorm 3y agoC++ classes with inheritance are a pretty good match for objects in a 3D (or 2D) world, which is why C++ became popular with 3D game programmers.
- hot_gril 3y agoYeah, OOP makes sense for games. The language will matter a bit for which one takes off, but anything will work given enough support. Like, Python doesn't inherently make a lot of sense for data processing or AI, but it's good enough.
- kagakuninja 3y agoOOP kind of goes out the window when people start using entity component systems. Of course, like the author, I'm not sure I'll need ECS since I'm not building a AAA game.
- hot_gril 3y agoHad to look up ECS to be honest, and it's pretty much what I already do in general dev. I don't care to classify things, I care what I can do with something. Which is Rust's model.
- remram 3y agoSorry I got lost in that sentence. What is Rust's model?
- hot_gril 3y agoRust has traits on structs instead of using inheritance. Aka composition.
- zozbot234 3y agoYou can also have structs be generic over some "tag" type, which when combined with trait definitions gets you quite close to implementation inheritance as seen in C++ and elsewhere. It's just less common because usually composition is all that's required.