FrankHB (frankhb1989.delete@this.gmail.com) on July 16, 2021 6:43 am wrote:
> For example, the abuse of explicitly fixed-width machine numbers in the basic type system is totally against
> the abstraction purpose: consider the fact you should not have many chances to have an exactly fixed-with
> integer like "i32" in the real business logic (expect for some low-level [de]serialization works between some
> on-wire formats and some in-memory representations), you're routinely making the conversion unconsciously
> to fit the semantic gap between the code and the real design implicitly. Such implicity is dangerous before
> you leak "i32" to the design, and then you totally failed to abstract details like "32" away. (Rust certainly
> won't insert any check between the gap of "i32" and the_real_type_you_need_in_the_design!)
>
> And compared to exception handling, the typical error handling mechanism in Rust is somehow enforcing
> the designers of API to go against separation of concerns, because the error information is always
> forced explicitly (equally significantly to the non-error "workloads") in the type signature of
> API (also often bad for ABI compatibility, but this is an implementation detail).
>
> Such glitches are often not obvious for most users, making it even more error-prone
> in everyday programming. I don't expect my life easier working with these users.

I agree here, but in the specific context of "everyday programming", Rust is not a good general purpose language, for the "everyday" when I just want to make something simple just works I want a GC and proper exception handling, C++ works better than Rust in this respect but C# works even better.

Rust is claimed as "system programming" which is a very specific niche, it would be very ankward to use C# in this niche, C++ have some caveats too, but Rust do very well in this niche, since the topic started about Linux kernel, I don't think it would be very productive to ignore this specific detail.