Comparison to Go?

Posted Jan 10, 2025 18:39 UTC (Fri) by khim (subscriber, #9252)
In reply to: Comparison to Go? by ralfj
Parent article: Preventing data races with Pony

> Rust generics are not modeled after ML modules at all, they are modeled after Haskell typeclasses. So Rust feels nothing like ML when it comes to generic programming, it's a completely different style.

Well… the important thing, verification before instantiation, is the same, but I guess you would know better.

> Have you ever actually programmed with ML-style modules to be able to do a qualified comparison?

Yes, but that was long ago and I wasn't doing much generic programming thus I defer to your experience: if you say that Rust picked its generics from Haskell and not ML then so be it. My point was that they are entirely different from C++ or Zig.

> And if you consider "ensuring the equivalent of basic type safety for generics" to be "artificially crippling" the language, you should also call C++ "artificially crippled" because it doesn't let you use "+" on a "std::list" and a "std::hash_map", not even inside dead code where it clearly doesn't matter!

Thanks for the vote of confidence! Yes, that was an issue with C++ before C++17. The problem was that “dead code” without extra markup depends on the quality of optimizer. Making validity of someone's code depend on quality of the optimizer wasn't a good idea and that's why this limitation was in place till C++17 fixed it: now, if you use if constexpr compiler understands that code would be “guaranteed dead” and in that code it's perfectly valid to add std::list and std::unordered_map. Because it happens inside dead code where it clearly doesn't matter!

That's precisely what turned TMP from crazy wizardly accessible only to some “initiated” to easy and simple instrument.

Note that example from excors already relies on that extension. It's literally everywhere in modern C++!

> That's just what a proper type system does: it rejects code that can't be easily shown to follow some basic correctness principles.

Sure. And that turns it into a straitjacket. Quite stiffing and limiting. That was my point.

> There's nothing at all artificial about it.

Of course there is! If you use tricks to circumvent it (accept type that doesn't implement Debug, e.g. and then print it using well-known loophole… everything works.

Every typesystem is “artificial” to some extent, but when we are dealing with things like integers or structs that have different representations in memory… Rust protects you from easily shooting yourself in the foot and it also provides an easy way to tell the compiler to reinterpret object of one type and object of some other type.

But when we are dealing with types… checks are much stricter yet there are no official way to circumvent them when that's needed. Why? What's the reasoning behind that decision?

> IMO Rust made the right call.

It made the right call WRT defaults, sure. When your task can easily fit in a statically typed world… it's great: error messages are better, there are less code to debug… but the fact that Rust does provide unsafe for it's typesystem but nothing “official” is provided for it's meta-typesystem is jarring. The fact that if const in Rust doesn't work like if constexpr in C++ and there are no way to look on the type and act on it is very stiffing.

The only hope is that eventually someone would take Rust and produce Rust++ to make it possible to easily use Rust and C++ in one project.