6 ms·

Ouch, quite a difference between the founders... now I'm sure that C++ and Go will rule the world... unfortunately. D would be awesome for game development, be

by nnq 11y ago

Ouch, quite a difference between the founders... now I'm sure that C++ and Go will rule the world... unfortunately. D would be awesome for game development, because it's a "C++ done right", but I don't think Andrei has the salesman qualities needed to sell his child to game devs, like getting a bunch of people together to write a good open-source game engine that could also serve as an example of codding patterns. And Rust and his daddy... they are just too smart to become popular nowadays, people just don't have the will and time to sit and learn better ways of doing things when they have alternatives that "mostly work most of the time" and have an easier learning curve...

vvanders 11y ago
I wouldn't discount Rust, I'm finding it incredibly refreshing after spending most of my career in C++.
- qznc 11y ago
  Rust has at least one niche for itself: Extension language for Python (or Javascript, Ruby, etc). A language with garbage collection disqualifies because Python already has one and two GCs in one application is not a good idea. Go has no plans to abandon GC and D still has a long way to go.
forgettableuser 11y ago
Game devs tired of C++ are waiting for Jonathan Blow's new language :) https://www.youtube.com/watch?v=TH9VCN6UkyQ https://www.youtube.com/watch?v=TH9VCN6UkyQ He states D isn't different enough to encourage most devs to go through the pain of switching. If they are going to switch, they would like that language to be much better targeted at solving game dev specific needs.
- Thaxll 11y ago
  Game devs will 'never' switch to D or anything different from C++, it's a standard in the industry for the past 20 years, everything is built around it. Edit: yeay the downvote bandwagon, you should go to a AAA studio and ask about C++.
  - teamhappy 11y ago
    Not sure why you're getting down voted. The middleware business is dominated by C++, Windows is still the big player, and pretty much all legacy code is written in C++. Adopting new language features is far more practical than moving to another language. Relatively small backend apps written in C++ may be a better target for D and Rust.
    - pjmlp 11y ago
      Everyone that has been related to the game industry since the early days, knows game studios also change languages, despite the existing eco-systems. The difference is that they only do it when the OS vendors, or game console vendors, force them to adopt new languages in their SDKs.
  - vvanders 11y ago
    The game industry isn't just AAA(arguably AAA died a while ago). I know many gamdevs using Unity, LUA, Javascript, Gamemaker and a ton of other options.
  - jeremiep 11y ago
    Never say never. I am a game dev. I worked on AAA titles. I want to switch to D. Badly. There are reasons why AAA studios stick to C++: they don't know any better, they're in constant crunch-mode and don't have time to look for better alternatives, they use an existing engine with years of development history and don't want to invest in a new one, they target platforms where only C/C++ compilers are available, etc. You'd be surprised of the horrors you can find in a game's C++ code base (there are gems too, but you kind of expect those.)
    - EliRivers 11y ago
      You'd be surprised of the horrors you can find in a game's C++ code base While it's true that some languages make some horrors easier to bring into the world (if you take away people's access to the memory, for example, you remove an entire class of memory-related nightmares), in my experience, the key requirement for creating these horrors isn't the language; it's the programmer and the constraints they're working under (such things as inexperience, painful levels of urgency, inappropriate processes, team churn, and so on and so on). People can and will make horrors in any language, and if D becomes the new C++, in twenty years people will be saying the same things about D.
- usrusr 11y ago
  D happened at the wrong time. It was a better C++ that nobody really asked for at a time when java and C# were the future. When some years later that surprising wave of alternative languages for CLR and the JVM arrived and opened the door wide for other languages as well, D was already stigmatized as the better C++ that did not make it. I also think that, due to it's early start, D simply fails to appeal to non-C++-developers. The other new native compiled languages, Go and Rust, are not just a new toy for C++ people, but are also seen as long awaited "on metal" opportunities for people from other language backgrounds (python and ruby for go, type-heavy managed languages for rust), who would never touch c++ or, guilty by association, D. This is a much bigger audience than the subset of c++ devs willing to give up their hard-earned mastery of c++. The perceived promise of native for high-level devs might not hold, but this won't help D at all.
  - acqq 11y ago
    Go is not "on metal" (garbage collector). Rust and D are. D has that nice introspection, it still can be better C++ than C++. The critical point is to make that as easy as possible for the existing code bases.
    - qznc 11y ago
      D is the only language I know which at least tries to provide C++ interop (without going through the C ABI). Being syntactically and semantically closer to C++ is an advantage here. This is probably the biggest promise D has for game developers. However, it is not production ready yet.
- boost_ 11y ago
  funny, every time someone says they're sick of C++ all i see in their code samples is horrible C with classes code. take for example a lot of C++ samples that that guy shows in the video, he calls it "C++11" and uses code like: - void* data = NULL; - no STL - no stack allocations - only dynamic memory allocation using new and delete i mean come on..
  - jeremiep 11y ago
    Almost every AAA game I've seen didn't use the STL. Boost is a definite no-go for most studios. Stack allocations are discouraged because they can introduce non-deterministic bugs (stack overflow depending on the call sequence which can't be predicted in advance). Its nearly impossible to write a game without dynamic allocations. Most of the time they'll override the new/delete operators and on that level they work almost exclusively on void*. You're working on a scale where a lot of the C++ features work against you.
    - boost_ 11y ago
      - "Almost every AAA game I've seen didn't use the STL." that’s probably because most of the AAA games you've seen used old in-house libraries that replaced the STL, since the earlier STL implementations weren't the best. STL is not 100% the way to go every time, but i would say that nowadays unless there’s a really specific implementation need, it should be used at least 90% of the times, even if only for base for new data structures to be built on top of. - "Stack allocations are discouraged because they can introduce non-deterministic bugs (stack overflow depending on the call sequence which can't be predicted in advance)." i really don’t understand this problem, you can change the stack size on every compiler and every OS either on compile time or runtime. also, are you writing functions or methods with 10k LoC? stack allocations are actually easier to follow than heap, its not even close.. - "Its nearly impossible to write a game without dynamic allocations. Most of the time they'll override the new/delete operators" yes i agree, dynamic allocations are still really needed, and not only for games. But, overriding new / delete operators in C++ when you can set custom allocators and deallocators for both unique_ptr and shared_ptr? once again i think that’s more of a legacy code update problem than an actually implementation need problem. - "and on that level they work almost exclusively on void*." only if they want to, that’s what templates (and again the STL) are here for. I’m not saying pure C++11/14 features are the only way to go, i just think that at least in new code it should take priority, the cleanness and robustness it provides its just too good to ignore.
- nnq 11y ago
  Thanks! You made me google Jonathan Blow and his language again (I've listened to his talk about a new language for game development some time ago, and I really like his thoughts on game design), and came across this on Jai's page https://sites.google.com/site/jailanguageprimer/ https://sites.google.com/site/jailanguageprimer/ : "Abstractions like RAII, constructors and destructors, polymorphism, and exceptions were invented with the intention of solving problems that game programmers don’t have, and with the result of interfering with the solutions to problems that game programmers do have." ...that's basically enough to make me never bother to look him up again. We don't need more special purpose languages, we need more general purpose ones. That's the cool thing about D and Rust and Go too. You can easily use the same language for anything from simple scripts (D even has rdmd that basically works like a ruby/python-style interpreter to run a file without even compiling!) to, I don't know, navigation control code for a drone. We really don't need more special purpose tools now, the hardware allows us to have languages that span the full spectrum from metal to web page (via compile-to-js, but still...), so let's use this. Yeah, full-spectrum languages will be neither C-like (like close enough to metal so you can see the resulting machine code in your head) nor Javascript-like (idiot-friendly but professional-hostile), so we should prepare for some "weirdness". It's not like we don't already know that this is possible since like 30 years ago: Lisp machines used one high level language for everything from OS to GUIs but and it worked great, with the exception that their price/performance ratio was horrible, but now we kind of solved the problem of building dirt-cheap machines, so we can get back to dreaming awesome stuff! And in the games world, I think that John Carmack has partially "seen the light" too, and maybe he'll convince more people of what he's seen ;)
  - kibwen 11y ago
    Assuming that a special-purpose tool services a given need better than a general-purpose tool, the only reason to prefer the general tool is because the market for that service may not be sufficiently large to bear the cost of supporting a specialized tool. But in a niche whose market is perpetually growing, the preferred tools will become more and more specialized over time and sticking with a general solution will become less and less competitive. A shrinking market may experience the opposite effect. Regardless of whether Jai is a useful tool, the question of whether to pursue specialized tools for game development depends on where you see market demand for those tools heading in the next decade.
detaro 11y ago
I've seen quite a bit of interest from hobby gamedev people in rust, way more than in D. I think reddit has had a rust gamedev sub for quite a while. Now if hobbyist/indie interest will influence the industry at large is a different matter, but I wouldn't count Rust out just yet.
- masklinn 11y ago
  > I think reddit has had a rust gamedev sub for quite a while. https://www.reddit.com/r/rust_gamedev https://www.reddit.com/r/rust_gamedev it's pretty small though (1264 subscribers, /r/rust has 12000, /r/swift is the same and /r/golang has 16000)
  - Cyph0n 11y ago
    That's actually quite impressive for such a niche subreddit.
    - Keyframe 11y ago
      It's almost as /r/d_language
Intermernet 11y ago
I actually got the impression that the C++ and Go camps were pretty happy to see the competition and conversation. Those 4 languages are a pretty good cross section of the state of "systems programming" and I don't think any of them really feel that there isn't room, in the near future at least, for all of their offerings. I think D and Rust will both be fairly well received (if they aren't already), if only for their perspective on memory management. Andrei hopefully doesn't need salesman like qualities. I hope that there will be enough D evangelists to do the selling for him. Rust will hopefully be hugely successful, but if not, the ideas it espoused will certainly be developed further by future languages. Those 4 languages are aiming at different targets (I think Rust and D would be aiming at the most common group). C++ is looking to gain the ability to do "modern things" in C++ without confusing existing C++ devs, Go is looking to attract devs who want to do modern stuff with a tiny ramp-up cost (low cognitive over-head, low time-to-productivity, brilliant standard library, native concurrency primitives) whereas D and Rust are both offering languages with more "modern" features that may be theoretically sound, but don't have as much proven use in production code. These differences are blurred, and the languages obviously do have cross-over in terms of features and paradigms, but I doubt they're truly competing for many jobs yet. They all have their place, depending on what you're trying to achieve.
pcwalton 11y ago
> And Rust and his daddy... they are just too smart to become popular nowadays, people just don't have the will and time to sit and learn better ways of doing things when they have alternatives that "mostly work most of the time" and have an easier learning curve... That presupposes that Rust is more complex than C++ in a way that causes developers to learn C++ instead of Rust. Certainly there are a lot of C++ developers at the moment (though that number is much less than in years and decades past!) But I don't see that many new developers learning C++ anymore. Even beginning programmers who are interested in games are turning to higher-level languages and frameworks these days. My employer hires lots of C++ developers, and it's well-known that it's getting increasingly harder to find them. When comparing Rust to Go, sure, Go is an easier language to pick up. When comparing Rust to C++, the majority of people I've talked to think the ease of use advantage goes to Rust.

by nnq 11y ago

vvanders 11y ago

I wouldn't discount Rust, I'm finding it incredibly refreshing after spending most of my career in C++.

qznc 11y ago
Rust has at least one niche for itself: Extension language for Python (or Javascript, Ruby, etc). A language with garbage collection disqualifies because Python already has one and two GCs in one application is not a good idea. Go has no plans to abandon GC and D still has a long way to go.

forgettableuser 11y ago

Game devs tired of C++ are waiting for Jonathan Blow's new language :) https://www.youtube.com/watch?v=TH9VCN6UkyQ https://www.youtube.com/watch?v=TH9VCN6UkyQ He states D isn't different enough to encourage most devs to go through the pain of switching. If they are going to switch, they would like that language to be much better targeted at solving game dev specific needs.

Thaxll 11y ago
Game devs will 'never' switch to D or anything different from C++, it's a standard in the industry for the past 20 years, everything is built around it. Edit: yeay the downvote bandwagon, you should go to a AAA studio and ask about C++.
- teamhappy 11y ago
  Not sure why you're getting down voted. The middleware business is dominated by C++, Windows is still the big player, and pretty much all legacy code is written in C++. Adopting new language features is far more practical than moving to another language. Relatively small backend apps written in C++ may be a better target for D and Rust.
  - pjmlp 11y ago
    Everyone that has been related to the game industry since the early days, knows game studios also change languages, despite the existing eco-systems. The difference is that they only do it when the OS vendors, or game console vendors, force them to adopt new languages in their SDKs.
- vvanders 11y ago
  The game industry isn't just AAA(arguably AAA died a while ago). I know many gamdevs using Unity, LUA, Javascript, Gamemaker and a ton of other options.
- jeremiep 11y ago
  Never say never. I am a game dev. I worked on AAA titles. I want to switch to D. Badly. There are reasons why AAA studios stick to C++: they don't know any better, they're in constant crunch-mode and don't have time to look for better alternatives, they use an existing engine with years of development history and don't want to invest in a new one, they target platforms where only C/C++ compilers are available, etc. You'd be surprised of the horrors you can find in a game's C++ code base (there are gems too, but you kind of expect those.)
  - EliRivers 11y ago
    You'd be surprised of the horrors you can find in a game's C++ code base While it's true that some languages make some horrors easier to bring into the world (if you take away people's access to the memory, for example, you remove an entire class of memory-related nightmares), in my experience, the key requirement for creating these horrors isn't the language; it's the programmer and the constraints they're working under (such things as inexperience, painful levels of urgency, inappropriate processes, team churn, and so on and so on). People can and will make horrors in any language, and if D becomes the new C++, in twenty years people will be saying the same things about D.
usrusr 11y ago
D happened at the wrong time. It was a better C++ that nobody really asked for at a time when java and C# were the future. When some years later that surprising wave of alternative languages for CLR and the JVM arrived and opened the door wide for other languages as well, D was already stigmatized as the better C++ that did not make it. I also think that, due to it's early start, D simply fails to appeal to non-C++-developers. The other new native compiled languages, Go and Rust, are not just a new toy for C++ people, but are also seen as long awaited "on metal" opportunities for people from other language backgrounds (python and ruby for go, type-heavy managed languages for rust), who would never touch c++ or, guilty by association, D. This is a much bigger audience than the subset of c++ devs willing to give up their hard-earned mastery of c++. The perceived promise of native for high-level devs might not hold, but this won't help D at all.
- acqq 11y ago
  Go is not "on metal" (garbage collector). Rust and D are. D has that nice introspection, it still can be better C++ than C++. The critical point is to make that as easy as possible for the existing code bases.
  - qznc 11y ago
    D is the only language I know which at least tries to provide C++ interop (without going through the C ABI). Being syntactically and semantically closer to C++ is an advantage here. This is probably the biggest promise D has for game developers. However, it is not production ready yet.
boost_ 11y ago
funny, every time someone says they're sick of C++ all i see in their code samples is horrible C with classes code. take for example a lot of C++ samples that that guy shows in the video, he calls it "C++11" and uses code like: - void* data = NULL; - no STL - no stack allocations - only dynamic memory allocation using new and delete i mean come on..
- jeremiep 11y ago
  Almost every AAA game I've seen didn't use the STL. Boost is a definite no-go for most studios. Stack allocations are discouraged because they can introduce non-deterministic bugs (stack overflow depending on the call sequence which can't be predicted in advance). Its nearly impossible to write a game without dynamic allocations. Most of the time they'll override the new/delete operators and on that level they work almost exclusively on void*. You're working on a scale where a lot of the C++ features work against you.
  - boost_ 11y ago
    - "Almost every AAA game I've seen didn't use the STL." that’s probably because most of the AAA games you've seen used old in-house libraries that replaced the STL, since the earlier STL implementations weren't the best. STL is not 100% the way to go every time, but i would say that nowadays unless there’s a really specific implementation need, it should be used at least 90% of the times, even if only for base for new data structures to be built on top of. - "Stack allocations are discouraged because they can introduce non-deterministic bugs (stack overflow depending on the call sequence which can't be predicted in advance)." i really don’t understand this problem, you can change the stack size on every compiler and every OS either on compile time or runtime. also, are you writing functions or methods with 10k LoC? stack allocations are actually easier to follow than heap, its not even close.. - "Its nearly impossible to write a game without dynamic allocations. Most of the time they'll override the new/delete operators" yes i agree, dynamic allocations are still really needed, and not only for games. But, overriding new / delete operators in C++ when you can set custom allocators and deallocators for both unique_ptr and shared_ptr? once again i think that’s more of a legacy code update problem than an actually implementation need problem. - "and on that level they work almost exclusively on void*." only if they want to, that’s what templates (and again the STL) are here for. I’m not saying pure C++11/14 features are the only way to go, i just think that at least in new code it should take priority, the cleanness and robustness it provides its just too good to ignore.
nnq 11y ago
Thanks! You made me google Jonathan Blow and his language again (I've listened to his talk about a new language for game development some time ago, and I really like his thoughts on game design), and came across this on Jai's page https://sites.google.com/site/jailanguageprimer/ https://sites.google.com/site/jailanguageprimer/ : "Abstractions like RAII, constructors and destructors, polymorphism, and exceptions were invented with the intention of solving problems that game programmers don’t have, and with the result of interfering with the solutions to problems that game programmers do have." ...that's basically enough to make me never bother to look him up again. We don't need more special purpose languages, we need more general purpose ones. That's the cool thing about D and Rust and Go too. You can easily use the same language for anything from simple scripts (D even has rdmd that basically works like a ruby/python-style interpreter to run a file without even compiling!) to, I don't know, navigation control code for a drone. We really don't need more special purpose tools now, the hardware allows us to have languages that span the full spectrum from metal to web page (via compile-to-js, but still...), so let's use this. Yeah, full-spectrum languages will be neither C-like (like close enough to metal so you can see the resulting machine code in your head) nor Javascript-like (idiot-friendly but professional-hostile), so we should prepare for some "weirdness". It's not like we don't already know that this is possible since like 30 years ago: Lisp machines used one high level language for everything from OS to GUIs but and it worked great, with the exception that their price/performance ratio was horrible, but now we kind of solved the problem of building dirt-cheap machines, so we can get back to dreaming awesome stuff! And in the games world, I think that John Carmack has partially "seen the light" too, and maybe he'll convince more people of what he's seen ;)
- kibwen 11y ago
  Assuming that a special-purpose tool services a given need better than a general-purpose tool, the only reason to prefer the general tool is because the market for that service may not be sufficiently large to bear the cost of supporting a specialized tool. But in a niche whose market is perpetually growing, the preferred tools will become more and more specialized over time and sticking with a general solution will become less and less competitive. A shrinking market may experience the opposite effect. Regardless of whether Jai is a useful tool, the question of whether to pursue specialized tools for game development depends on where you see market demand for those tools heading in the next decade.

detaro 11y ago

I've seen quite a bit of interest from hobby gamedev people in rust, way more than in D. I think reddit has had a rust gamedev sub for quite a while. Now if hobbyist/indie interest will influence the industry at large is a different matter, but I wouldn't count Rust out just yet.

masklinn 11y ago
> I think reddit has had a rust gamedev sub for quite a while. https://www.reddit.com/r/rust_gamedev https://www.reddit.com/r/rust_gamedev it's pretty small though (1264 subscribers, /r/rust has 12000, /r/swift is the same and /r/golang has 16000)
- Cyph0n 11y ago
  That's actually quite impressive for such a niche subreddit.
  - Keyframe 11y ago
    It's almost as /r/d_language

Intermernet 11y ago

I actually got the impression that the C++ and Go camps were pretty happy to see the competition and conversation. Those 4 languages are a pretty good cross section of the state of "systems programming" and I don't think any of them really feel that there isn't room, in the near future at least, for all of their offerings. I think D and Rust will both be fairly well received (if they aren't already), if only for their perspective on memory management. Andrei hopefully doesn't need salesman like qualities. I hope that there will be enough D evangelists to do the selling for him. Rust will hopefully be hugely successful, but if not, the ideas it espoused will certainly be developed further by future languages. Those 4 languages are aiming at different targets (I think Rust and D would be aiming at the most common group). C++ is looking to gain the ability to do "modern things" in C++ without confusing existing C++ devs, Go is looking to attract devs who want to do modern stuff with a tiny ramp-up cost (low cognitive over-head, low time-to-productivity, brilliant standard library, native concurrency primitives) whereas D and Rust are both offering languages with more "modern" features that may be theoretically sound, but don't have as much proven use in production code. These differences are blurred, and the languages obviously do have cross-over in terms of features and paradigms, but I doubt they're truly competing for many jobs yet. They all have their place, depending on what you're trying to achieve.

pcwalton 11y ago

> And Rust and his daddy... they are just too smart to become popular nowadays, people just don't have the will and time to sit and learn better ways of doing things when they have alternatives that "mostly work most of the time" and have an easier learning curve... That presupposes that Rust is more complex than C++ in a way that causes developers to learn C++ instead of Rust. Certainly there are a lot of C++ developers at the moment (though that number is much less than in years and decades past!) But I don't see that many new developers learning C++ anymore. Even beginning programmers who are interested in games are turning to higher-level languages and frameworks these days. My employer hires lots of C++ developers, and it's well-known that it's getting increasingly harder to find them. When comparing Rust to Go, sure, Go is an easier language to pick up. When comparing Rust to C++, the majority of people I've talked to think the ease of use advantage goes to Rust.