dequan

The cranelift backend itself has a JIT mode.

100% agreed. Thank you for your work on ntpd-rs!

I agree that it would be great if the ecosystem was a bit slower to use every new version and it does seem like things are beginning to tend in that direction as many foundational crates have begun declaring MSRVs of !LATEST.

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.

What an interesting coincidence that all three of these accounts were created within 15 minutes of each other. I'm sure all "three" users are being "intellectually honest" here.

All of a sudden? They've been unsafe for decades, it's just that you had less of a choice then.

Garbage collection seems like a significant no-go for many safety critical systems. Other oddities like 31 and 63 bit numbers probably aren't a big deal but are still weird. "Mature" seems like a stretch when OCaml only got proper multi threading 1.5 years ago.

"outdated article" the commit tested is 3 months old.

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.

I think you've missed my point entirely but that's fine.

Not really. The lack of fields in traits or a classical inheritance system is pretty strongly missed by some people coming from C++.

Which doesn't really have anything to do with GP's incorrect assertion that C# is somehow safer than Rust.

Hmm? Dotnet on Linux uses LLVM for codegen so that seems to be a wash. Lots of nuget packages are wrappers around native libraries as well.

The "link" is just the repos rather than asking AI to hallucinate an answer. Rust's repo contains 2.2M LOC. The dotnet runtime contains 1.5M lines of C++.

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.

The entire JIT, garbage collector and most of the C#'s VM are all implemented in C++. This has caused various issues in the past which are exploitable from managed code. The amount of unsafe code used to implement C# vastly outweighs the amount in Rust's standard library.

That's not really accurate. Ojeda is a long time kernel contributor and so are many of the folks writing drivers. Maintainers of various subsystems are also particularly interested.

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

Nonsense, WG21 is committed to ensuring C++ has more warts and sharp edges than any other language on the planet.

C# is not more safe than Rust is and falls to prevent null pointer exceptions and modified collection exceptions.

I don't find it particularly surprising. D uses a garbage collector while C, C++ and Rust do not. D's GC can be disabled but that isn't that useful when most D code including the standard library until just a few years ago were not written with that in mind.

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.

Apple themselves no longer support the new minimum supported macOS and iOS versions and haven't for years.

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?

I thought V has a backwards compatibility guarantee as of 3 years ago so you don't have to rewrite your programs?

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