7 ms·

Disagree 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 2y ago
Also 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 2y ago
  I'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 2y ago
    Yes, 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 2y ago
      Thanks 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 2y ago
        Rust is not used in V8, to my knowledge.
  - meheleventyone 2y ago
    I'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 2y ago
      There 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 2y ago
        Looks 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 2y ago
        Speaking 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 2y ago
        Agreed. We've learned a lot from Godot, by the way. I consider all us open source engines to be in it together :)
        meheleventyone 2y ago
        Game 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 2y ago
    Repo 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 2y ago
      That'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 2y ago
        I wish Microsoft had any direction on the 'way of the future' for native apps on Windows
        travisgriggs 2y ago
        If 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 2y ago
        I'd have bought into MAUI if there was Linux support in the box.
        somenameforme 2y ago
        The 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 2y ago
    So 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 2y 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 2y ago
        I 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 2y ago
  not 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 2y ago
    Not really relevant to 30 years ago though.
- IggleSniggle 2y ago
  That description of problems bodes well for Zig
- SunlitCat 2y ago
  Theoretically 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 2y ago
    I 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 2y ago
[deleted]
georgeecollins 2y ago
I 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 2y ago
  I 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 2y ago
  I 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 2y ago
    I 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 2y ago
      Not 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.

pavlov 2y ago

Also 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 2y ago
I'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 2y ago
  Yes, 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 2y ago
    Thanks 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 2y ago
      Rust is not used in V8, to my knowledge.
- meheleventyone 2y ago
  I'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 2y ago
    There 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 2y ago
      Looks 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 2y ago
        Speaking 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 2y ago
        Agreed. We've learned a lot from Godot, by the way. I consider all us open source engines to be in it together :)
        meheleventyone 2y ago
        Game 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 2y ago
  Repo 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 2y ago
    That'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 2y ago
      I wish Microsoft had any direction on the 'way of the future' for native apps on Windows
      - travisgriggs 2y ago
        If 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 2y ago
        I'd have bought into MAUI if there was Linux support in the box.
        somenameforme 2y ago
        The 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 2y ago
  So 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 2y 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 2y ago
      I 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 2y ago
not 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 2y ago
  Not really relevant to 30 years ago though.
IggleSniggle 2y ago
That description of problems bodes well for Zig
SunlitCat 2y ago
Theoretically 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 2y ago
  I 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 2y ago

[deleted]

georgeecollins 2y ago

I 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 2y ago
I 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 2y ago
I 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 2y ago
  I 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 2y ago
    Not 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.