More interesting design ideas in uv. Didn't know about the dashmap crate they're using here it looks like a nice one too.
OK maybe a longer piece than it should be. Still the idea is interesting. Clearly you want to mind the O(n) coupling in this context.
I'm not sure I fully align with this piece. The core tenet of generic design advice vs concrete design advice makes sense though.
Unsurprisingly, this is mostly not related to the use of Rust. The design choices are what male uv so fast.
Interesting tool and I like the underlying approach. I wish we'd have good equivalent tools for other ecosystems.
This is a good pattern, use it! This article does a good job showing variants and where it makes sense to reach out for it.
Looks like a nice tool for UX design and getting insights from conversations with users.
Very powerful talk from Bruce Sterling about design and the startup culture. The most impactful part starts somewhere in the middle (where the URL leads you).
Another illustration of how to use a new type to declare intent for display of values.
Deceptive title! It's far from simple and the article confirms it. It's fascinating to see all the dimensions you have to deal with to design a game though.
Indeed it feels like the Rust community has a cultural problem around abstractions. In a way it feels similar to the one Java developed years ago. This can bring lots of complexity and obfuscation you don't want in your project.
What's behind the notion? Some historical musing about self-organizing teams and the design they produce.
This is an interesting pattern that I still seldomly meet in C++ codebases. Of course don't go overboard with it, but don't be scared of using it for wrong reasons.
Good reminder that it's better to design your APIs to avoid putting people in the situation of inadvertently creating a divide by zero.
It's kind of an unusual design choice... This is subtle, I think I'm still a bit on the fence regarding this one.
An explanation about where the SRP comes from and what it really means. It's very often misunderstood or overlooked.
Apparently in the age of people using LLMs for their tests, there is a bias toward mockist tests being produced. It's a good time to remind why you likely don't want them in most cases and limit the use of mocks to consider fakes and checking system state instead.
Of course I agree with this. We should fight undue complexity at every step. This beast tends to creep up very quickly and we're all guilty of it at times. This is indeed particularly obvious in otherwise rich languages like C++ or Rust. Those tend to push people to try to be clever and show off, often for "performance reasons". This is rarely a good idea, think twice.
I would have titled the "defer refactoring" section differently though. Probably "defer abstracting" would have fit the bill better.
It's indeed a nice little pattern to use when the type system allows for exhaustiveness checks of destructure operations. Allows to gracefully handle extension of structs in the future.
Lots of good points in there. Very much focused on web services APIs, that being said the first part also applies to libraries APIs in my opinion.