However I don't think the pace of updates really changes anything in terms of tool chain security. If Rust decided to go to a 36 week release cycle, each release would just have 6x as much stuff in it. If you can't keep up reviewing N changes in a 6 week release cycle, moving to a 6*X release cycle will not help you review N*X changes.

This is a standard V community tactic: all negative feedback is "bashing", anything older than a week is "outdated", anything up to date shouldn't have been written and posted on the issue tracker to be ignored instead.

Stop trying to control everyone else's speech and just work on fixing the long list of issues folks already took the time to report.

Now if we remove in tree tests from the totals, we arrive at 1.5M lines of C++ (most tests are written in C# as you would expect) and 1.7M lines of Rust.

However, this does not exclude safe Rust code. I don't have a tool off hand that can provide a precise count of lines of unsafe code but we can get some general estimates. There are 1958 instances of "unsafe fn" out of 103,205 instances of "fn ". Further there are 11,545 instances of "unsafe " in the Rust repo while there are 10,768 instances of "unsafe " in the runtime repo.

Given that unsafe functions comprise less than 2% of all functions in the Rust repo, I think my claims are reasonable.

Not everyone is of course, but hardly "just (Rust) advocates" like you suggest.

D is much more closely a competitor of C# than it is C++. D has a few nice features like advanced compile time programming but the actual nuts and bolts that Staff engineering management looks isn't really solid. D's GC is a design straight out of the 80's. Dmd has good compiler throughout but code quality isn't very good. Ldc is much better but compile times are much longer.

Adopting languages at FAANG beyond a single team just yolo deploying them to production requires integrating dozens of engineering systems for everything from post mortem debugging to live profiling to authentication systems. The cost to do this is in the order of tens of millions of dollars.

D just isn't suitable as a C or C++ replacement in the places that actually require it and the cost to enable it in large companies isn't worth it for the incremental improvement it does offer in some areas.

The fundamental issue is testing, how do you acquire test environments that old and what exactly is gained by the continuous effort required to keep them running when their Apple themselves refuses to do so?

https://github.com/vlang/v/commit/ba38c94a403b72222508a85704...