Interesting exploration of how static and dynamic dispatchs work behind the scene in Rust. The chosen tradeoffs are different than in C++ and that's something to keep in mind.
Comparison of two concurrency models. This is a light read which shows quite well the differences.
Interesting case where you want to property test but without a specific property base test tool. Indeed, if you need to be exhaustive and the input space is small enough this is the better decision. This article also comes with interesting point on Rust type system but that's less central to the main point.
Unsurprisingly it's not all unicorns and rainbows. This piece tries to highlight the right questions to ask yourself before aiming for a rewrite.
Interesting tool. Maybe more chances for C++ and Rust hybrids?
Interesting policy. I think it strikes a good balance.
More ideas of things to check to harden a service, goes beyond just what's deployed. Many good points on how to handle errors and such.
Good checklist to reduce your attack surface as much as possible when deploying your service.
While some rewrite from Zig to Rust... others follow the opposite path. This is an interesting read pointing the strengths and weaknesses of both ecosystem. There's no one size fits all in our field so it's important to have this kind of explorations.
Another attempt at easing the pain navigating the Rust crates ecosystem? It has its merits as well.
A nicely balanced view at Rust the language but also the ecosystem. It's not all pretty and real issues are looming.
Still need some work I'd say but this is interesting research. Transpiling C++ to Rust is getting more accessible. It need some improvements on the optimisation side to be more generally usable.
Interesting Rust options to limit the amount of heap allocations if you're constrained by memory or for performance reasons.
Friendly reminder that the answer is "no". You don't want to just rewrite everything, it's not just a syntactical translation, it's a long project and at best you tackle critical components.
Sounds obvious to me, but I guess it's worth repeating. It illustrates well the type of issues you still have to deal with in multi-threaded Rust.
This is an excellent exercise to understand a language and its ecosystem better. This time it is about Rust.
Indeed, skipping the centralized package manager might be better in the long run.
Interesting take on why CVEs are reported differently for C/C++ and Rust libraries. The responsibility for API misuse is treated differently because the abilities to express contracts is treated differently.
Wondering how those are implemented and the challenges behind them? This is a good exploration of the idea.
Some of the examples lean on macro trickery. Still this gives a good example of the flexibility you get with the trait system.
The writing isn't perfect, but it covers quite a few important topics in Rust. Seems to be a nice resource even though it's still work in progress.
Nice suggestions on how to structure larger Rust code bases. The proposed error handling is particularly neat and tidy. This is doable in other languages but tends to be more verbose.
As usual with this author it feels a bit too much like advertising toward the end. Still this is an important post, it shows quite well why you can't limit yourself at only the language used when picking a stack. You definitely need to look at the standard library and the wider ecosystem as well. Rust is no different there and has its own issues.
Straight from the uutils rewrite. This is interesting both for the class of bugs which made it (very system integration oriented, unsurprisingly) and the ones which didn't appear at all (anything to do with memory).
Indeed, the memory layout of your structs can matter. Be it Rust or not, but in the case of Rust the use of Option might give the wrong feel about the resulting layout.
Finer grained borrowing is still something people need in Rust. Here is a potential solution to get them today.
When possible it's nice to nest your error types, this allows better investigation when something fails.
This bears repeating of course. I still wish our industry would run less on hype. It's not specific to Rust of course.
Can crates.io make things easier to secure? I do think so. But this post is right that we shouldn't forget the social aspect of the whole supply chain security conversation.
Indeed, the current supply chain model of Rust could be better. While we wait for improvements (with no sign of them coming), there are ways to try to avoid some of the common pitfalls.
Good guidelines for Rust code indeed.
Interesting proposal for rust borrow checker. I wonder if it'll get any traction.
Good explanation of where WebAssembly is going and why the current initiatives are important to its success.
Looks like an interesting ORM which brings advantages of the Django one without all the bagage. It's still young, let's see how it evolves.
Interesting look at Zig's comptime feature. It's not a purely Zig post though, does a good job of explaining parametricity and the implications of loosing it.
Looks like an interesting approach to lift some of the limitations around the Rust trait system. The learning curve doesn't look too great though, clearly requires effort to get into.
Yes, Rust like C++ comes with zero cost abstractions. Still they can get in the way of some compiler optimisations. This is an interesting case preventing vectorisation.
Short explanation of why you want to make invalid state impossible to represent. This leads to nice properties in your code, the price to pay is introducing more types to encode the invariants of course.
Looking at several languages and their reflection features. What's coming with C++26 is really something of another class than anything else. I just have concerned about its readability though.
This is indeed an important cultural trait in the Rust community. This can bring challenge when integrating Rust code into a context with more ambiguity.
There are growing concerns regarding the Rust supply chain. It's still time to address them but it's became important to tackle this area.
More interesting design ideas in uv. Didn't know about the dashmap crate they're using here it looks like a nice one too.
Wondering what's on the mind of people working on an hyperscaler? This podcast and its transcript gives good insights.
Looks like an interesting framework for embedded projects.
Error handling is still not a properly solved problem in my opinion. At least the Rust community discusses the topic quite a bit. This is good inspiration for other ecosystems as well I think.
This is indeed interesting to see how the landscape evolved around error handling. There's clearly a tension between exceptions and the result types we've seen popping up everywhere now.
A bit too unapologetic regarding Rust API choices for my taste. Still, it gives a good idea on how error handling works in Rust.
You assumed you could deserialise in a zero copy fashion? Are you really sure about that? Think twice.
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 definitely a useful idiom. A bit like the immediately invoked lambdas in C++ but less verbose. This is nice to control intermediate variables locality and mutability like this.
Definitely quite some nice resources in the Rust world for people interested by development for embedded systems.
There are indeed options for managing dependencies in more complex Rust codebases. It needs to be planned properly when doing the software architecture of your components though.
I admit I like CRDTs as well. They really are the foundation of cool use cases. Of course it raises questions related to security to broker properly the sessions between users. Still, it's nice to see them more and more used.
Very Rust focused, still it's an interesting debate. It gives a good overview of the different types of lock behaviors in case of failures. It's very much advocating for the poisoning approach which is indeed an interesting one (coming with its own tradeoffs of course).
Shows that you don't always need to put stuff in Box to get dynamic dispatch.
Another illustration of how to use a new type to declare intent for display of values.
A bit of a shameless plug toward the end. That said the explanations of why Cloudflare is banking on Rust so much or how the recent downtime could have been avoided are spot on.
Nice approach to stub standard types in Rust. The article is a bit confusing the different types of test doubles though.
Didn't know about that clippy feature. This is neat, allows to precisely target some of your project rules.
Wondering what happened at Cloudflare? Here is their postmortem, this is an interesting read.
Now for Rust developers... this is a good illustration of why you should stay clear from unwrap() in production code.
Nice alternative syntax to the good old regular expressions. Gives nice structure to it all. There's a Rust crate to try it out.
Early days but this looks like interesting tooling to inspect and debug programs using Rust channels.
Interesting analysis of the crates ecosystem. It shows quite well some of the challenges and weaknesses. Nothing to worry about yet about the ecosystem health overall. Still, you should probably be careful when picking dependencies.
A good list of code smells to pay attention to in Rust. Also provides patterns to avoid such smells.
This is unfortunately still a bit complicated for my taste. Ideally std::simd should be stabilized, but since it's not the case yet options have to be evaluated.
Indeed, the C++ syntax for closure captures is way superior to the Rust one. Interesting musing on a potential path forward for Rust.
Interesting notes about borrow checking in Rust. Looks like it does a good job exploring the whole space of issues one can encounter with potential solutions.
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.
An illustration of why C++ can still be a relevant choice in new code. It all depends on the contraints you have for a given problem.
Interesting post which gives plenty of insights on how async Rust is designed and behaves.
Just a little dive in the Rust standard library. It gives a good idea on how they pile layers to ensure safety while providing a nice API on top.
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.
A good explanation of why you likely don't want a centralised package manager for your ecosystem.
Bad actors will go to great length to try to compromise your supply chain.
Need a refresher on how to write a parser? This is a good one. Also gives a few ideas of Rust libraries you can use to make the task easier.
This is not an easy case, even with the support of PyO3. This short article gives a nice blueprint to share a reference between Rust and Python.
Nice bag of tricks for better Rust performance at low level. The compiler is indeed helping quite a bit here.
This is indeed a welcome improvement in my opinion. It's nice to get a glimpse of the process of adding such features in Rust.
Nice chapter to better understand Rust dyn traits (also called trait objects).
Due to the strict type system this kind of conversion is not necessarily a given. There are ways though, and you can even keep it performing well.
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.
Interesting talk. The tools presented can indeed go a long way helping people figure out what's wrong with a piece of code or learning some of the harder parts of a language.
Clearly the error handling landscape still evolves in Rust and that's a good thing. The current solutions are too fragmented at the moment.
No good tricks to optimize your code, but knowing the tooling knobs sometimes help.
Indeed, is it that the language itself has a steep learning curve? Or that the emphasis is on the wrong things in the public discourse? I like the emphasis on the Aliasing Xor Mutability, it looks like a good way to approach the language.
This is a nice summary of the Send and Sync traits semantic in Rust.
Interesting point, fairly logical but didn't sit to think it through before. Indeed, using arenas to get back features of manual memory management won't lead to the same security issues than outside of a memory safe language.
Very interesting pattern. The article is really in-depth and gets all the way to language lawyer level. It's not for everyone I guess.
Dealing with temporaries is always complicated it seems, whatever the language.
Nice pattern to workaround limitations of the Rust trait system preventing blanket implementations.
There are indeed other options beyond the model with "one enum with all the errors".
Nice new tool to investigate code generated by macros in Rust. Indeed you can quickly add lots of lines to the compiled code without even realizing, in large code bases it's worth keeping in check.
Nice exploration which shows the many levers one can use to impact Rust compilation times. They all have their own tradeoffs of course, so don't use this just for the sake of reducing time.
I like this kind of oddities in languages. This is nice to see such a list for Rust at a single place.
This piece is a bit too much written as Rust zealotry for my taste. That being said, there's in my opinion an interesting core truth hidden in there: for now it seems to better foster "expert generalists" when investing in it. Now it might be just for now and might stop later... time will tell.
They both have their niches and it's welcome in my opinion. Now there are questions about the long term viability of Zig's ecosystem... the niche being smaller it's more at risk.
Nice move. It doesn't have to be about rewriting everything in Rust. Still there are some areas where we can benefit from the language and sandboxing.
A good example of how you can get bitten by cache coherency algorithms in the CPU.
Interesting selection of options to model data structure with some variability in Rust.