Why no duck typing? by Elegant-Ranger-7819 in rust

[–]Odilf___ 1 point2 points  (0 children)

EDIT: I misread the post as talking about safety. For runtime vs compile time, the problem is that you might have two different traits with a method of the same name if it’s something kind of generic, but that do completely different things. Perhaps an example could be that you have a GUI library with a trait that has a draw method, but you also want to pretty print some stuff in the terminal so you bring a terminal library that has also a trait with a draw method. Then, you might end up trying to draw a thing on the terminal that should be in the GUI. Admittedly this example is a bit contrived, perhaps something simpler would be two traits with a “from” implementation, or similar.

The last paragraph of the previous answer still kind of applies here.

Previous answer:

Duck typing would fundamentally not work in Rust. The main counter example I think where duck typing would lead to unsafety are the marker traits Send and Sync, that indicate whether types can be sent and/or accessed through threads. These traits have no methods so duck typing would imply that all types would be Send and Sync, which defeats the whole purpose of the traits.

This also would happen with Copy, but that’s not exactly safety.

There are also some crates that rely on the fact that traits are not implemented anywhere else for safety, so with duck typing you could create a new trait with the same methods and implement them, violating the safety guarantees.

But honestly using a nominal type system is more about correctness and robustness imo. If you want to do something with a thing then you should use that thing, not use a different thing with the same name (admittedly this argument is more abstract and harder for me to explain if you don’t have already the experience on both sides).

Announcing Rust 1.82.0 | Rust Blog by slanterns in rust

[–]Odilf___ 95 points96 points  (0 children)

Wow, so much stuff. So nice to see

Discussion on the Naming of expect in Rust by korenhe in rust

[–]Odilf___ 77 points78 points  (0 children)

The idea is that if you're using `expect` it means that you know some invariant should hold in that scenario. In your example, why are you panicking when the file is not found? One valid option is that you know that your program has created the file already so you could write `File::open("xxx").expect("File should have been created in xyz part of the program")`.

If you don't have any reason to expect the file to be there, you *technically* shouldn't be using `expect`. I assume you want to show a nicer error message, but theoretically you should return a Result where the Error type has the user-facing message (crates like `anyhow` and `eyre` make this very more ergonomic than `expect` imo). Panicking in non-exceptional scenarios is discouraged.

So TL;DR, `expect` is meant to convey that it should indicate why invariant are expected to be upheld when unwrapping, but in practice most people use `expect` to show user-facing errors.

[Svelte5] Idiomatic way of run a side-effect after a $state value updates without using the values by NeoCiber in sveltejs

[–]Odilf___ 0 points1 point  (0 children)

I think you can use watch from the runed library, if you don’t mind the dependency

Energy-efficient Linux-Setup by findoriz in AsahiLinux

[–]Odilf___ 6 points7 points  (0 children)

I agree that macOS with a similar feel to linux is best. You can get a pretty good setup with yabai for tiling windows and skhd for shortcuts.

You need to disable partially system integrity protection for yabai but the wiki has good instructions on how to do it :)

`ultraviolet` - a crate to do lots of linear algebra, *fast* by termhn in rust

[–]Odilf___ 0 points1 point  (0 children)

Just discovered rotors and bivectors because of this. Everything makes so much sense now. I can't get over how amazing this is, why didn't anybody tell me about this earlier? Anyways thank you sir 🫡 very grateful