Runtime performance is entirely unaffected by the use of macros. It can have a negative impact on compile-time performance though, if you overdo it.
Might be relevant to mention that Rust has formal verification methods available as well, similar to SPARK, but also optional. One that looks pretty appealing is this one: https://verus-lang.github.io/verus/guide/overview.html
While I can get behind most of the advice here, I don’t actually like the conditions array. The reason being that each condition function now needs additional conditions to make sure it doesn’t overlap with the other condition functions. This was much more elegantly handled by the else clauses, since adding another condition to the array has now become a puzzle to verify the conditions remain non-overlapping.
Today the Direct3D and HLSL teams are excited to share some insight into the next big step for GPU programmability. Once Shader Model 7 is released, DirectX 12 will accept shaders compiled to SPIR-V™. The HLSL team is committed to open development processes and collaborating with The Khronos® Group ...
SPIR-V is the intermediate shader target used by Vulkan as well, so it sounds like this may indirectly make DirectX on Linux smoother.
I mentioned it in the first comment:
the reason I tend to recommend B-Tree maps over hash maps for ordinary programming is consistent iteration order. It is simply too easy to run into a situation where you think iteration order doesn’t matter, but then it turns out it does in some subtle unforeseen way.
I’m not talking about bugs in the implementation of the map itself, I’m talking about unforeseen consequences in the user’s code since they may not anticipate properly for the randomness in iteration.
Oh, I agree, they both have their use cases. But that doesn’t mean there’s not plenty of situations where the performance is effectively irrelevant, but where people tend to default to using a hash map because they heard it’s faster (probably because lookups are O(1) indeed). So that’s where I would say, as long as performance doesn’t matter it’s better to default to B-Tree maps than to hash maps, because the chance of avoiding bugs is more valuable than immeasurable performance benefits (not to mention that for smaller data sets B-Tree maps can often outperform hash maps due to better cache locality, but again that’s hardly relevant since the data set is small anyway).
Hehe, yeah, I actually agree in principle, although in the context of web tooling I think it’s at least understandable. For many years, web tooling was almost exclusively written in JavaScript itself, which was hailed as a feature, since it allowed JS developers to easily jump in and help improve their own tooling. And it made the stack relatively simple: All you needed was Node.js and you were good to go.
Something like the Google Closure Compiler, written in Java, was for many years better than comparable tooling written in JS, but remained in obscurity, partially because it was cumbersome to setup and people didn’t want to deal with Java.
Then the JS ecosystem ran into a wall. JS projects were becoming bigger and bigger, and the performance overhead of their homegrown tooling started frustrating more and more. That just happened to be the time that Rust came around, and it happened to tick all the boxes:
- It showed that it can solve the performance bottlenecks.
- It has great support for WASM, which many web developers were having an interest in.
- Its syntax is familiar enough for TypeScript developers.
- It has a good story around interior mutability, which is a common frustration among TypeScript developers, especially those familiar with React.
I think these things combined helped the language to quickly win the hearts and minds of many in the web community. So now we’re in a position where just name dropping “Rust” can be a way to quickly resonate with those developers, because they associate it with fast and reliable and portable. In principle you’re right, it should just be an implementation detail. But through circumstance it seems to have also become an expression of mindshare – ie. a marketing tool.
Finding a Webpack replacement that doesn’t use NPM at all is going to be hard, but there are certainly alternatives that don’t require the 1000+ NPM dependencies required to use Webpack.
Some alternatives you can consider are Rsbuild and Farm. Part of the reason they use so much fewer NPM dependencies is because they’re written in Rust, so they’ll have Cargo dependencies instead, but you shouldn’t notice anything of that. Of course if you want to audit everything it’s not that much easier, but at least the Cargo ecosystem seems to have avoided quite some of the mistakes that NPM made. But yes, in the end it still comes down to the extent that you trust your dependencies.
Apart from all the interesting performance characteristics and their use in databases, the reason I tend to recommend B-Tree maps over hash maps for ordinary programming is consistent iteration order. It is simply too easy to run into a situation where you think iteration order doesn’t matter, but then it turns out it does in some subtle unforeseen way.
Of course it’s the way of our trade that unforeseen things cause bugs. But if there’s one kind of bug that is particularly annoying, it’s the hard-to-reproduce ones: those introduced by timing issues or (semi-)randomness. The moment you start iterating over a hash map you risk falling prey to the second one. So I’ll just prefer to default to a B-Tree map or set instead.
Is this the rule you might be looking for? https://biomejs.dev/linter/rules/use-sorted-classes/
I’m one of the core contributors to Biome, btw, so feel free to ask questions!
First anniversary of Biome and release of Biome 1.9 that enables CSS and GraphQL formatting and linting by default, a new search command
Biome v1.9 is out!
Today we celebrate both the first anniversary of Biome 🎊 and the release of Biome v1.9! Read our blog post for a look back at the first year and the new features of Biome v1.9.
In a nutshell:
- Stable CSS formatting and linting. Enabled by default!
- Stable GraphQL formatting and linting. Enabled by default!
.editorconfigsupport. Opt-inbiome searchcommand to search for patterns in your source code.- New lint rules for JavaScript and its dialects.
Yeah, I mix them too, although I apply quite a bit of functional techniques especially at the architectural level as well. OO I use mostly for dealing with I/O and other areas where statefulness cannot be avoided.
If you’re interested, I also wrote an in-depth blog where I touch on these topics: https://arendjr.nl/blog/2024/07/post-architecture-premature-abstraction-is-the-root-of-all-evil/
Just keep in mind that inheritance is nowadays a very contested feature. Even most people still invested in object oriented programming recognise that in hindsight inheritance was mostly a mistake. The industry as a whole is also making a shift to move more towards functional programming, in which object orientation as a whole is taking more of a backseat and inheritance specifically is not even supported anymore. So yeah, take the chance to learn, but be cautious before going into any one direction too deeply.
Between Rsbuild, Farm and Mako, I wonder which one will emerge victorious. It seems Rsbuild is the most well-known at this point, but also the slowest of the three (though it could be argued at this point they're all fast enough). Farm has compatibility with Vite plugins as its ace, while Mako is supposedly the fastest of them all.
Meanwhile, Vite itself is apparently not sitting still either, investing in Rolldown to speed up and improve its own bundling. I encourage their friendly competition. It seems the main winners are the users :) (unless you bet on the wrong horse, in which case you may grumble and hope for a better pick with your next project :p)
and that burden is as far as I’ve seen being forced on those long term contributors.
This is not what is happening. The current long term contributors were asked to clarify semantics about C APIs, so the Rust maintainers could take it from there. At no point were the C maintainers asked to help maintain the Rust bindings.
I think I would put the emphasis slightly differently: I don’t feel the confusion is around the word “spawn”, but it spawns futures rather than tasks. For tasks you might indeed expect them to be picked up in the background (which is what work-stealing does), but futures only execute when polled.
I was aware that indeed the trait and lifetime bounds were an artifact of the Tokio work-stealing behavior, but Evan makes a very well-explained case for why we might want to consider stepping away from such behavior as a default in Rust. If anything, it makes me thankful the Rust team is taking a slow-and-steady approach to the whole async thing instead of just making Tokio part of the standard library as some have wished for. Hopefully this gets the consideration it deserves and we all end up with a more ergonomic solution in the end.
Async Rust is powerful. And it can be a pain to work with (and learn). Async Rust can be a pleasure to work with, though, if we can do it without `Send + Sync + 'static`.
Of course, I’m a user too, but I don’t think Linux’s UX is that bad. It may be bad in some areas, but it’s not bad across the board.
I also don’t think Linux is only for developers. It’s great for developers, but it’s also great for people with only basic needs of their computer, those that don’t need much more than a browser, an email client and maybe an office suite. The UX is totally adequate for them, as evidenced by ChromeOS.
I think where Linux lacks is mainly for the users in between, those who are not full developers or tinkerers, but do want to mess around and do so from a perspective of expectations of how things worked in the Windows world. And I won’t deny there’s a plethora of legitimate enterprise use cases for which there is no equivalent in Linux today. But those are not UX issues, those are mainly matters market support. Linux is not great there, maybe it never will be. Or if it does, it’ll take a long time.
Practical tips that allow you to build an evolving architecture
With this post I've taken a bit more of a practical turn compared to previous Post-Architecture posts: It's more aimed at providing guidance to keep (early) architecture as simple as possible. Let me know what you think!
On the implications of defining the architecture after you build the product -- part II
After my previous post introducing Post-Architecture, I received a bunch of positive feedback, as well as enquiries from people wanting to know more. So I figured a follow-up was in order. Feel free to ask questions here as well as on Mastodon!
On the implications of defining the architecture after you build the product
This post highlights my experience working with software architecture in startup environments. I think the approach is different enough from the traditional notion of software architecture that it may warrant its own term: post-architecture.
cross-posted from: https://programming.dev/post/12807878
> This new version provides an easy path to migrate from ESLint and Prettier. It also introduces machine-readable reports for the formatter and the linter, new linter rules, and many fixes.
This new version provides an easy path to migrate from ESLint and Prettier. It also introduces machine-readable reports for the formatter and the linter, new linter rules, and many fixes.
I just had a random thought: a common pattern in Rust is to things such as:
rs let vec_a: Vec<String> = /* ... */; let vec_b: Vec<String> = vec_a.into_iter().filter(some_filter).collect();
Usually, we need to be aware of the fact that Iterator::collect() allocates for the container we are collecting into. But in the snippet above, we've consumed a container of the same type. And since Rust has full ownership of the vector, in theory the memory allocated by vec_a could be reused to store the collected results of vec_b, meaning everything could be done in-place and no additional allocation is necessary.
It's a highly specific optimization though, so I wonder if such a thing has been implemented in the Rust compiler. Anybody who has an idea about this?
It's been almost two months since I originally proposed integrating GritQL into Biome. Since then a lot has happened. And a lot more remains to be done. With this post I hope to give a little bit o...
Just a progress update on a fun open-source project I'm involved with. Biome.js is a web toolchain written in Rust, and it provides a great excuse to play around with parsing technologies and other fun challenges :)
Slide with text: “Rust teams at Google are as productive as ones using Go, and more than twice as productive as teams using C++.”
In small print it says the data is collected over 2022 and 2023.
I have a fun one, where the compiler says I have an unused lifetime parameter, except it's clearly used. It feels almost like a compiler error, though I'm probably overlooking something? Who can see the mistake?
main.rs ```rs trait Context<'a> { fn name(&'a self) -> &'a str; }
type Func<'a, C: Context<'a>> = dyn Fn(C);
pub struct BuiltInFunction<'a, C: Context<'a>> { pub(crate) func: Box<Func<'a, C>>, } ```
```text
error[E0392]: parameter 'a is never used
--> src/main.rs:7:28
|
7 | pub struct BuiltInFunction<'a, C: Context<'a>> {
| ^^ unused parameter
|
= help: consider removing 'a, referring to it in a field, or using a marker such as PhantomData
For more information about this error, try rustc --explain E0392.
error: could not compile lifetime-test (bin "lifetime-test") due to 1 previous error
```
A little trick that can help make switch statements more type-safe
Today I'm sharing a little trick that I like to use to make switch statements cleaner and more type-safe. Happy to hear other ideas!
This post explores how we improved upon Bevy's out-of-the-box UI experience for our Sudoku Pi project
As part of my Sudoku Pi project, I’ve been experimenting with improving the Bevy UI experience. I’ve collected most of my thoughts on this topic in this post.
How Fiberplane Notebooks implement Operational Transformation
I wrote a post about how our Operational Transfomation (OT) algorithm works at Fiberplane. OT is an algorithm that enables real-time collaboration, and I also built and designed our implementation. So if you have any questions, I'd be happy to answer them!