3 ms·

That's not a language feature as much as it is a culture and standard library feature. For instance, Java could do the same, but in practice conversion methods

That's not a language feature as much as it is a culture and standard library feature. For instance, Java could do the same, but in practice conversion methods throw runtime exceptions that you won't be warned about and your code will randomly crash if conversions fail, except in some cases when it doesn't. For casting between numeric types the language does have some legacy cruft, but for web applications nothing is stopping you from doing this. Java's explicit exception system is great at forcing developers to deal with potential failures, but in practice Java developers chose not to deal with exceptions so often that exceptions now get hidden. Rust does this stuff in the standard library and that gives you the advantage that you don't need to explain the concept and convince every developer that this is a good idea. The same way Java has optional nullability annotations that are rarely used in practice because not every developer feels like adding them, unlike languages where nullability is part of the type system. The concept is not exclusive to Rust, but I also haven't found it very popular outside of Rust developer circles.

baq 1y ago
I'm happily using this pattern in TS to wrap DB ids to avoid mistakenly passing e.g. user id to a function accepting a thing id or vice versa. Works very well and prevented a few close calls. I'd call it a type system feature, especially if you pack the id in a nominal type.
cleartext412 1y ago
> Java's explicit exception system is great at forcing developers to deal with potential failures, but in practice Java developers chose not to deal with exceptions so often that exceptions now get hidden. Every time I see someone bringing up the idea of adding checked exceptions to a language (usually in these endless exceptions vs returning errors debates), it is met with "it won't work, look at Java", and it feels like a real shame. I'm sure complications of additional syntax would pay off just as fast as it does for regular type annotations.

baq 1y ago

I'm happily using this pattern in TS to wrap DB ids to avoid mistakenly passing e.g. user id to a function accepting a thing id or vice versa. Works very well and prevented a few close calls. I'd call it a type system feature, especially if you pack the id in a nominal type.

cleartext412 1y ago

> Java's explicit exception system is great at forcing developers to deal with potential failures, but in practice Java developers chose not to deal with exceptions so often that exceptions now get hidden. Every time I see someone bringing up the idea of adding checked exceptions to a language (usually in these endless exceptions vs returning errors debates), it is met with "it won't work, look at Java", and it feels like a real shame. I'm sure complications of additional syntax would pay off just as fast as it does for regular type annotations.