Awesome, and congrats to AA! We have an all out languages war ahead with D vs. Rust vs Go. I'm sure tons of innovations will come out of this that will benefit us all!
(Yeah, I get it that the languages target different niches in theory, but there will be significant overlap among the people who use them, I'm sure...)
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...
> 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.
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.
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.
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.
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.
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.
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++.
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.)
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.
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.
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.
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.").
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.
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.
- "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.
You arguably don't need that many data structures in a game engine, almost everything is tightly packed in linear arrays. Even hash-maps are frowned upon. The single most used structure I've seen in engines is the plain old array because of cache locality. Everything is pre-sorted, pre-looked-up and pre-crunched so the main use-case is a straightforward linear traversal with as little branches as possible. Also templates can greatly affect compilation times which are already horrible on projects of such magnitude.
On the last AAA game I worked on we had very tight memory constraints and running about a dozen threads. Almost all of them used the minimum stack size except for the main thread. There were still a lot of stack allocations, but only for very small temporary objects and when the call stack was known to be shallow. Using megabytes for stack sizes would consume a noticeable percentage of the available memory which was direly needed elsewhere.
I've seen one game using shared_ptr and it was far from being great. There's a big overhead to it when compared to custom allocators. You can't easily optimize for cache locality with shared_ptr (as far as I know!) and working around enable_shared_from_this can be a real pain. With custom allocators you can easily optimize according to the use-cases.
Finally, templates are required to know their type at compile time, which for things like allocators is just not possible in many cases. For example, we used a bump-the-pointer allocator for a frame's temporary values which could be of any type but still needed cache locality. We also used a fixed-size allocator when avoiding memory fragmentation was more important than cache locality. Both would be impossible to do on anything but void*.
I haven't tried Rust yet, but they all easily translate into D!
I've lost count of the number of times I've thought to myself "I wish C++ has this D feature." A lot of them are being added now but the interesting ones (concepts!) are still years away and some (inout functions!) are nowhere in sight.
And then there's templates, mixins, auto this, compile-time reflection, and so much more. Its far from perfect (nothing is) but constantly improving and rather productive. Of course also being a user of Clojure (and Emacs-LISP) I sometimes miss something like defmacro, which I can almost get with mixins and templates but often not as elegantly. On the other hand, I write shell scripts in D all the time and not in Clojure!
Did they ever fix the memory release semantics with std::vector?
Last time I looked std::vector::clear() wasn't required to release memory and caused a lot of headache when certain implementations wouldn't free the underlying memory.
I'm aware that the work around is to assign a new std::vector<T>() but that always felt like more of a hack then anything else.
this is a reply to vvanders comment, for some reason i cant reply directly to his comment, so ill reply to myself..
they didn’t really "fix" it, instead they added a method called std::vector<T>::shrink_to_fit() which i'll admit its not the most elegant way, but it works.
what it does is, it resizes the capacity() to be the same as the size(), deallocating all the extra memory.
About the reply issue: its simply HN's mechanism to prevent flamewars from escalading quickly. The deeper a comment is the longer you have to wait after it is posted to be able to reply to it.
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/ :
"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 ;)
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.
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.
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.
One of the first things I'm looking at in Go and Rust is compatibility with C. I haven't used D, but this page makes it look as good or better from that perspective:
(Rust has the advantage of having no runtime beyond what C needs unlike D with its current garbage collector, so FFI, especially exposing a C interface, is likely somewhat simpler.)
I can. I've written D interfaces to vendor-supplied C and C++ SDKs and for an open source C library (libusb). We're using this at work. For C, it's relatively easy and mechanical to translate by hand but https://github.com/jacob-carlborg/dstep makes starting trivial. For C++, I had two cases- one was easy as that vendor provided a C handle and function call syntax while the other required doing a C shim (facade) to wrap up the object. I didn't find SWIG to be useful but did examine its output to get ideas. The built-in unit testing in D is very handy.
(Yeah, I get it that the languages target different niches in theory, but there will be significant overlap among the people who use them, I'm sure...)