snaggen

Must be some glitch or something, the link is there for me... but here is the link anyway: https://www.linkedin.com/pulse/why-rust-easy-tue-henriksen

I think the author is correct about the compile / test ratio being drastically shifted in rust vs other languages. One thing to have in mind regardng this, is that in larger companies testing may be performed by a dedicated team. Hence, a shift to rust will give the impression of a much higher workload for the developers. In reallity the workload should be pretty much the same since the bugs from testing still needs to be fixed, but that will be spread out over a larger time span due to going by the test team first.

But the author doesn't mention the most common way to pass named argument, so I include a comment from mjec over at lobster.rs that covers that (since I'm to lazy to write my own):

It’s not obvious to me why the author didn’t include direct instantiation of the struct, rather than a builder:

#[derive(Default)]
struct SearchOptions {
   pub include_inactive: bool,
   pub age_within: Option<(u32, u32)>,
   // ...
}

let result = search_users(
 users,
 SearchOptions {
   include_inactive: true,
   age_within: Some((5, 29)),
   ..Default::default()
 }
);

This avoids the need for boilerplate enums, or to filter through a vec in order to find the value of an argument. Every caller has to specify ..Default::default() but I don’t mind that! I like the idea that you have to explicitly acknowledge that you want everything else to be default values (and it might be useful to omit it in some places, so you get a compile error if new options are introduced).

There is no dedicated learnrust forum here yet, so post your questions here, and if it becomes a problem it can be handled then (by creating a learnrust commynity).

That is pretty much the same policy I have for forcing adds on me.

Yes, I started off with a C mindset and had a bit of a struggle the first days until the mental model of ownership and borrowing landed, after that it is mostly learning to use new concepts like pattern matching, the ? operator aso.

Just to be clear, I'm not the author of the article. I just found it on the Internet and found it interesting.

It should be, in the ideal world, just be thrown as a last resort... but in reality it isn't. I assume it is because when you find a nice IllegalStateException, you might feel that it really describes your condition quite well, so you use that without realizing that it is a surprise exception since that is not very clear. When you are using your IDE and need to throw an exception in an error case, it is not clear what is a runtime exception and not, and then you are not forced to use throws and here we are...

The equivalent in Rust would be to have a std::error::GenericError(String) in rust, that looks like a normal error but secretly panics under the hood.

Well, but then any function may also throw random runtime exceptions, so even if a function declares that it throws IOException, it may also deep down throw an IllegalStateException. And if you then were naive enough to only catch IOException, then you are in trouble. I recently had that case, were I had forgot the top level catch (Throwable t) clause and the program just died with nothing in any log. Adding that top level catch and a log line, made me see where it threw and what. Then I just needed to add additional logging around that to see the application state to understand the why.

Yes, Java lives by the credo "Backtrace or it didn't happen!"

For both of you, wouldn't it be nice to let me add my home instance so you could provide quick links to subscribe (and open the community in my home instance).