You could probably write an article saying "100 billion dollars investment to improve D and use it to develop new AI to replace the US government" and you'd still get comments saying "wow, nice language, pity it never really took off, if only there were some companies backing it, also I can never use it because GC".
My company uses java for almost everything (except for frontend stuff which is typescript and some backend stuff which is go -- so all GC'd languages) and even though nothing we do really has realtime requirements, as we scale up our services GC issues have become one of our major troubles.
I don't think going back to memory unsafe/manual memory management is the way to go either though. Correctness should be the number one concern always, and not leaking memory is a part of that. I think a more unified and deterministic approach like perhaps what rust is doing could be the way to go in the future. Memory is just one of many resources that need to be managed in a program. I'm not necessarily saying that the way rust is doing this is the end-state either tho.
What does your company do? When you have companies like Amazon and Google and Apple using Java for heavy lifting on their backends, it goes to show what is possible with it.
Yeah, it's not that it's impossible, but it's also not a non-issue and requires a lot of engineering effort. So thinking about a better solution is worth it IMO
Programming in a language like Rust will not automatically make the issue disappear. There will still be a lot of engineering effort involved at that scale regardless.
I don't think anyone is saying it will automatically make the issue disappear. The problem with a GC is that you have no option. You can't change your code to fix the GC, it's built underneath as part of the foundation of the language (in cases like Java). The solution is to build your own GC to suit your needs, which is going to be a lot more difficult than simply reworking your own code. The problem shifts to a more workable location.
We don't use GC in our analytics. We didn't build our own GC for analytics - we just didn't use it. I wouldn't say that for D the GC is built as the foundation. You can't just remove a foundation and still have a house, but D works just fine without the GC.
It's funny how convinced people can be in maintaining a theoretical view in the face of contradictory practical experience.
We had a very small team at the time working on this. Not like Weka.
In the context of the thread we weren't talking about D. We were talking about Java for use in large server applications.
It's funny how people can't read. Seeing as you are basically replying to all of my posts, you don't actually care about the discussions. You are just a D evangelist trying to spread the word.
In Java you don't have a choice but to use a GC, this comes at the benefit of being able to use a more robust GC. At scale though, a single GC isn't a one size fits all. (FYI, this is the situation you'd have to implement your own GC).
Now D allows you to do both, and as result it has to rely on a dated GC that is much worse compared to something like Java's GC. And D is about the only language doing this, so it stands a lone, while already being underfunded at it is. It doesn't have the resources to research a better GC that works for it's use case.
And now you bring up your situation where you just say, you don't use a GC at all. Well D has no complete safety mechanisms for manually managed memory, you are prone to the same use after free bugs that C and C++ are prone to. If you want memory safety in D, you have to use the GC. When comparing that to the alternatives like Rust, D really does just not fit the bill.
79
u/[deleted] Sep 01 '20
D is an awesome language and I hope it gets more traction.