6 ms·
D made the right tradeoffs for whom? There are many safe languages with great ecosystems which have a GC. Realistically, before rust, there wasn't really any fo
by surajrmal 3y ago
D made the right tradeoffs for whom? There are many safe languages with great ecosystems which have a GC. Realistically, before rust, there wasn't really any for languages without a GC. A major problem for folks who must not use a GC is that large parts of the D ecosystem rely on the GC which makes it not useful for the segments that cannot use said GC. I've not actually used D professionally, so I could be off base, but this is at least the perception.
Rust is facing a similar problem in terms of sync vs async, which seems to limit options primarily for folks who want to avoid async, but it doesn't seem like a major blocker for adoption comparatively.
- connicpu 3y agoI think one notable difference for Rust is that it's still perfectly possible to call async code from sync code. It might be slightly less efficient than if everything was participating in async, but often that's fine when it's just the one-off network request in your otherwise synchronous CPU-heavy workload. Meanwhile, for people who need to have no GC, you can't paper over an internal dependency that uses GC. The whole stack has to be no-GC period. A similar comparison in the Rust world is probably with the #![no_std] ecosystem. Kernels/kernel modules and super low power microcontrollers have the biggest restrictions on what libraries they can pull in, since they can't use any dependencies that use the normal standard library, only the core library. (Low power is relative though, eg the ESP32 chips have nearly full std lib support)