> For things that don't need classes (and there is a lot of code) I stick to C.
I'd use D anyway just for the GC or whatever, less compiler fighting, betterC etc. Procedural, OOP, functional, yay.
I'd use D anyway just for the GC or whatever, less compiler fighting, betterC etc. Procedural, OOP, functional, yay.
A lot of the standard library ranges are inherently lazy and therefore require no interaction with the GC. Exceptions are also nogc now.
Metaprogramming, for example, in D is obvious and almost fun. The compile times are ridiculous compared to C++, i.e. I can build the main D compiler in three different configurations in about 5sec on my machine.
Some people would argue that you can use D for equally high performance things to C++, and make sure you use the GC very selectively, etc. However, you don't appear to be making that argument. If you aren't, then there's just no real point comparing C++ and D. If you don't have any of those requirements, and you are ok with obscurity, you have much stiffer competition from many other languages like Haskell, Kotlin, etc.
I should know, I've written a C++ compiler and know where the bloat is buried, and designed D to eschew features that would be inherently slower than the C++ counterparts.
You can even turn off the runtime array bounds checking.
llvm vs icc could be a hit, but that's all really.
So even C++ isn't good enough for them.
Yet a few vocal anti-C++ devs in the game world, from Insiomatic Games are now at Unity driving HPC# efforts, so there's that.
in release mode.
As for game developers, you don't have to look any further than Unreal, CryEngine or EASTL, or a couple of talks at GDC Vault.
So who's right?
Not using some or most of the standard library is precisely not an example of subsetting C++. Just because the C++ standard library has a hash table available doesn't mean that every project has to use it. Companies standardizing their own high performance data structures where it makes sense, and other things as well, is just something that happens and often makes sense independent of language.
Keep up the good fight! "Exceptions are slow" is a realy outdated opinion
Root of all evil etc. etc.
Your comments read like you're explaining optimization to a beginner, it's a bit bad faith tbh.
GCC and LLVM have broadly similar performance characteristics(i.e. for any arch/uBenchmark combo there is another that puts the other one faster).
If GCC is appreciably faster for your purpose, then fair enough but LLVM is not drastically slow by any means (Especially when you consider that any "Anything you can do..." Between LLVM and GCC moves much faster on the LLVM side due to a much saner codebase)
(Can it be a C replacement? Sure, but so can Rust/Swift/Go/etc)
Just because it is tiny does not make it inexistent.
Then there is the whole POSIX, which is kind of runtime that wasn't made part of ISO C, but follows it everywhere.
One just links another implementation, just like printf() vs printk().
Then again, OOMing due to leaks is something you’re more likely to see in poorly-written systems in non-GC languages (Objective-C, C, C++, etc), so there are certainly trade offs.
[0]: Maybe “poorly written” is unfair. Perhaps “written by people who are unaware of how to write code that performs well in a GC system”.
I have never in my life worked in any kind of software where this was remotely acceptable
If you never allocate from it (which is able to be verified very easily with the @nogc attribute), it will never trigger. You can disable it and trigger when you feel it is needed. You can choose to just leak.
The default GC is OK, but not great. However it recently was made multithreaded in the mark phase so it is much faster than it used to be. There is a fork based (on linux only IIRC) GC, used by several companies for hard realtime systems, that marks and sweeps in a separate process with CoW pages.
D has a built-in GC by default and doesn't force you to manage memory like Rust. Also, the author mentioned that D is pretty straightforward to anyone with some basic programming knowledge (think C, C++, Java, and C# which fits the majority of coders). Rust is very different from those languages. My main goto language is Python and I can understand D a lot more than Rust which confuses me to no end (disclaimer: I'm a total noob).
Go is probably as easy to read as D if not more and is also GC and fast. It is also very spartan. I bet D has a lot of additional features.
Go is okay but you can't get clever with it. You're productive from the start butit becomes routine quite fast and at a certain point there isn't anything new to learn. Error checking is also quite annoying.
D has the best of both worlds and it also plays nicely with C/C++, something that the author of Zig also understood is a must have in any language that aims to be a better C/C++. In D one is productive from the start and there's always something new to learn. And one learns it as they code, without having to first read Programming in D by Ali Çehreli to make any sense of the language.
I also tried Crystal and liked it but one is more productive in D and Go without any prior knowledge of those languages. I was kind of annoyed by the fact that Crystal removed the for loop, which works perfectly fine in Ruby.
Don't get me wrong, I like a language with a Gc by default, my favourite language is OCaml, but I can't claim it to be a drop-in replacement for C projects. Go, Rust (or D) stand a better chance at that.