5 ms·

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

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.
    - jeremiep 11y ago
      While I agree with you I think D's design avoid a lot of the pitfalls of C++. When I think about all the different variable initialization rules in C++ I know I'll get it wrong in crunch time and most likely get it wrong when all my work conditions are perfect because there's like 7 different rules. And that's for one feature only. D doesn't make it impossible to write horrors, it just doesn't ask for it the way C++ does.
- pjmlp 11y ago
  I don't know if it will be D, but I am 100% sure they will change. First there was only Assembly, C and Pascal dialects were dog slow, and the OS vendors forced them to go C. Then there was only C, C++ was dog slow, and the OS vendors forced them to go C++. Then there was only C++, language X was dog slow, and the OS vendors force them to go language X. The question is what language X stands for.
- cpeterso 11y ago
  Tim Sweeney (Epic Games) gave a great presentation about programming languages and game development, with examples from the Unreal Engine (e.g. "90% of integer variables in Unreal exist to index into arrays."). https://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf https://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced...
- nnq 11y ago
  No, but fortunately (in this rare case), people also tend to... uhm... you know... after a certain age (or sooner, after too many energy drinks and sleepless nights) ...die :) And the new generation usually comes with a fresh set of ideas about things, and some of the newbloods will be "stupid" enough to start and rewrite some of the C++ tools, at the expense of their employers that will see delayed projects and tons of bugs because of this, and probably fire the trouble-makers, but the retooling will happen anyway, so it's probably better for people to embrace it and start allocating budget slices for it.
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.

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.
  - jeremiep 11y ago
    While I agree with you I think D's design avoid a lot of the pitfalls of C++. When I think about all the different variable initialization rules in C++ I know I'll get it wrong in crunch time and most likely get it wrong when all my work conditions are perfect because there's like 7 different rules. And that's for one feature only. D doesn't make it impossible to write horrors, it just doesn't ask for it the way C++ does.
pjmlp 11y ago
I don't know if it will be D, but I am 100% sure they will change. First there was only Assembly, C and Pascal dialects were dog slow, and the OS vendors forced them to go C. Then there was only C, C++ was dog slow, and the OS vendors forced them to go C++. Then there was only C++, language X was dog slow, and the OS vendors force them to go language X. The question is what language X stands for.
cpeterso 11y ago
Tim Sweeney (Epic Games) gave a great presentation about programming languages and game development, with examples from the Unreal Engine (e.g. "90% of integer variables in Unreal exist to index into arrays."). https://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf https://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced...
nnq 11y ago
No, but fortunately (in this rare case), people also tend to... uhm... you know... after a certain age (or sooner, after too many energy drinks and sleepless nights) ...die :) And the new generation usually comes with a fresh set of ideas about things, and some of the newbloods will be "stupid" enough to start and rewrite some of the C++ tools, at the expense of their employers that will see delayed projects and tons of bugs because of this, and probably fire the trouble-makers, but the retooling will happen anyway, so it's probably better for people to embrace it and start allocating budget slices for it.

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.