snaggen

I updated the title of this post, as per your suggestion

This post seems to have taken the title from a previous post that this is built upon. So that is probably why the title gets a bit confusing when viewed standalone.

This feature sounds useful https://hachyderm.io/@epage/110707292330840528

It is possible to have an active discussion in a civil tone. What they promote is conflict, that is not the same as activity.

Taking the best parts from Perl, hashmaps for everyting ;)

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.

Also, if you try it out, then you cannot delete your threads account without deleting your Instagram account and loosing all your photos. So, Welcome to the Hotel California.

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).

You are right, it does. But as you say, it seems more limited in that aspect than error-stack from a first glance.

Error stack will give will print the full stack of errors and their corresponding line in the code. Much like a backtrace, but for errors.

But even there a TcpStream, a FileStream and a StringStream might have quite differen behaviour, since they all abstract very different things. So, even this simple example may fall apart very fast if you need to care about those. I'm not saying that Inheritance is always bad, but it is quite rigid and might cause problems in a large codebase if you suddenly run in to the corner cases where the assumptions the abstraction is based upon is no longer upheld.