I'm writing a small 3D Vulkan game engine using C++. I'm working in a team, and the other members really don't know almost anything about C++. About three years ago i found this new programming language called D wich seems very interesting, as it's very similar to C++. My idea was to implement core systems like rendering, math, serialization and so on using C++ and then wrapping all with a D framework, easier to use and less complicated. Is it worth it or I should stick only to C++ ? Does it have less performance compared to a pure c++ application ?
Using D with C++
You probably won't see any performance drawbacks as long as you're clever about avoiding the GC in general.Granted, that's easier said than done, but them's the breaks.
IMO, the biggest advantage of D over C++ is the compile-time reflection/introspection, which makes serialization much easier, along with stuff like binding functions to a developer console or something. You might also find that, while D can "talk C++", you're going to lose a lot of that functionality across language boundaries.
I originally started writing a game with a similar approach (except using wrappers around C++ rendering/math APIs rather than writing the subsystems in C++ directly), and I found that, while my productivity went through the roof for a lot of the typical drudgery glue code and engine business logic:
- The terrible state of library support got to be a problem -- a lot of the bindings to stuff like UI libraries and graphics APIs are in various states of disrepair, some requiring me to dig in and fix them.
- The build system for D is absolutely atrocious; they build everything around a package manager, but like most package managers it makes for a terrible build tool, and none of the larger build systems people have extended for D support the aforementioned package manager (but the library ecosystem requires it, so good luck with that).
- If you have any inkling at all of supporting 32-bit windows builds, walk away from D immediately. To be fair, 32-bit isn't something many people care to support nowadays, but if you do want to, you've got to worry about the fact that the backend for the mainline D compiler (which is the only one that works on windows without POSIX shenanigans of some sort) is built around OMF format object files, so you need to make sure all of your library dependencies are built in that format. This is a pretty significant pain point for your build pipeline, and I'm not even sure it's possible to sustain if you require any closed-source libraries.
If you can deal with those issues, D is a great language, and while I eventually migrated to pure C++, I was probably twice as productive in D overall with a similar performance profile despite having several years more experience with C++. However, the language is suffering the classic chicken-and-egg problem (no tooling/libraries = no users = no tooling/libraries) that most new languages face, and most new languages never really get out of that and die out.
That said, if you want to dogfood everything, and don't want to take in any external dependencies at all, or if all your external dependencies are things you plan to write C/C++ modules around, then sure, go for it. Just be careful of the GC.
You might be able to get most of the advantages of D with none of the disadvantages if you do the above and use this:
https://dlang.org/spec/betterc.html
However I don't really have much experience with it.
8 hours ago, SeraphLance said:You probably won't see any performance drawbacks as long as you're clever about avoiding the GC in general.Granted, that's easier said than done, but them's the breaks.
IMO, the biggest advantage of D over C++ is the compile-time reflection/introspection, which makes serialization much easier, along with stuff like binding functions to a developer console or something. You might also find that, while D can "talk C++", you're going to lose a lot of that functionality across language boundaries.
I originally started writing a game with a similar approach (except using wrappers around C++ rendering/math APIs rather than writing the subsystems in C++ directly), and I found that, while my productivity went through the roof for a lot of the typical drudgery glue code and engine business logic:
- The terrible state of library support got to be a problem -- a lot of the bindings to stuff like UI libraries and graphics APIs are in various states of disrepair, some requiring me to dig in and fix them.
- The build system for D is absolutely atrocious; they build everything around a package manager, but like most package managers it makes for a terrible build tool, and none of the larger build systems people have extended for D support the aforementioned package manager (but the library ecosystem requires it, so good luck with that).
- If you have any inkling at all of supporting 32-bit windows builds, walk away from D immediately. To be fair, 32-bit isn't something many people care to support nowadays, but if you do want to, you've got to worry about the fact that the backend for the mainline D compiler (which is the only one that works on windows without POSIX shenanigans of some sort) is built around OMF format object files, so you need to make sure all of your library dependencies are built in that format. This is a pretty significant pain point for your build pipeline, and I'm not even sure it's possible to sustain if you require any closed-source libraries.
If you can deal with those issues, D is a great language, and while I eventually migrated to pure C++, I was probably twice as productive in D overall with a similar performance profile despite having several years more experience with C++. However, the language is suffering the classic chicken-and-egg problem (no tooling/libraries = no users = no tooling/libraries) that most new languages face, and most new languages never really get out of that and die out.
That said, if you want to dogfood everything, and don't want to take in any external dependencies at all, or if all your external dependencies are things you plan to write C/C++ modules around, then sure, go for it. Just be careful of the GC.
You might be able to get most of the advantages of D with none of the disadvantages if you do the above and use this:
https://dlang.org/spec/betterc.html
However I don't really have much experience with it.
Thanks for your answere. I'll try to avoid the GC as much as i can. I Think the disadvantages you wrote about can be easily avoided in my project. Thank you very much.
Note that you can annotate a function with @nogc to tell it not to use the GC. Some people avoid the GC by just annotating main, because the attribute propagates to everything the annotated function calls (which in the case of main is basically your whole program). You don't necessarily have to go that far, but I'd recommend controlling things tightly through that.
It might also help to have the rest of the team read the combined Parashift/Stroustrup Super C++ FAQ to get a better handle on C++.