> 1. Learn to work on team projects to improve D ecosystem
Criticism is right on point.
I believe if you use D in a team, you need to be extra careful to keep the same subset, and also using D is way nicer if you avoid unproven features.
To be happy with D you need the utmost restraint with features, and yes unittest helps a lot.
> GC crashes day in and day out.
Sounds like the old destruction ordering problem, and that can be solved by detecting accidental correctness. The problem is destructors called from GC. If you use the GC, you will probably need deterministic destruction in production code, and there are of course ways to achieve it systematically.
> Using D itself is a code smell, IMHO.
I don't see it as more risky than any other language. Especially as the langage is slow-moving, and you don't have to re-learn every 3 years.
Large codebase in any language becomes unwieldly. Let's reflect on your next decade of Rust once it's achieved :)
Criticism is right on point. I believe if you use D in a team, you need to be extra careful to keep the same subset, and also using D is way nicer if you avoid unproven features. To be happy with D you need the utmost restraint with features, and yes unittest helps a lot.
> GC crashes day in and day out.
Sounds like the old destruction ordering problem, and that can be solved by detecting accidental correctness. The problem is destructors called from GC. If you use the GC, you will probably need deterministic destruction in production code, and there are of course ways to achieve it systematically.
> Using D itself is a code smell, IMHO.
I don't see it as more risky than any other language. Especially as the langage is slow-moving, and you don't have to re-learn every 3 years. Large codebase in any language becomes unwieldly. Let's reflect on your next decade of Rust once it's achieved :)