[Peeks into misbehaving macro] You can give a man a token stream but you can’t stop him from turning it into a string and using regular expressions on it. #rustlang

This is an excellently written postmortem from fly.io:

"You’re reading a 3,000 word blog post about a single concurrency bug, so my guess is you’re the kind of person who compulsively wants to understand how everything works. That’s fine, but a word of advice: there are things where, if you find yourself learning about them in detail, something has gone wrong."

https://fly.io/blog/parking-lot-ffffffffffffffff/

#rustlang #postmortem #software #engineering

@drmorr I really feel these guys should give papaya a try: https://github.com/ibraheemdev/papaya

It is exactly designed for use cases such as these, where you have incredibly high read contention, and you don’t want to have deadlocks at all.

It’s a relatively young library, so I can understand they may want to do very careful testing, but an API that cannot deadlock is absolutely worth it IMO.

#Rust #rustlang #concurrency

We’re excited to announce that version 3 of the Biome extension for VS Code is now available!

This release includes a range of new features and improvements to make your development experience even better:

- 🗄️ Support for multi-root workspaces
- 📝 Support for single-file mode
- 👻 Support for unsaved files
- 🔄 Automatic reload after updating Biome
- ⚙️ Automatic reload after configuration changes
- ✨ Improved status indicator

Read more about it here: https://biomejs.dev/blog/2025-05-29-biome-vscode-v3/

Asking the important questions 😏
https://users.rust-lang.org/t/simplifying-iterator-method-implementations/130027

#Rust #rustlang #bikeshedding

@jenesaisquoi @Ordoviz It’s a gray area, legally. What you say is theoretically correct, but there’s practical issues once you’ve looked at the code that will open you up to legal liability anyway.

For instance, what if you need a utility function during your reimplementation for which there is really only one obvious implementation? You can no longer claim to have come up with it by yourself.

I doubt the FSF would sue over it, but companies are known to avoid the risk.

@dolanor @JoshuaKGoldberg Yeah, I don’t think it’s entirely impossible, but it’s sufficiently hard/hacky that it’s infeasible for a production project.

@JoshuaKGoldberg @jfmengels @tseslint oh, that’s interesting. Potentially Biome should be able to create an API like that.

We have a `useExplicitType` rule to mandate annotations, and I’ve thought about whether it might make sense to have an autofix for it. Main problem I saw is that users I don’t think users would like to see fixer suggestions with complex compound types. But maybe you have ideas to solve that?

@JoshuaKGoldberg @jfmengels Yeah, that's fair. Personally I lean quite a bit more towards making intention explicit, and thus having more explicit types as well, but I can see how for internal use some won't bother :)

And true, even if we may stick to Isolated Declarations across modules, for inference within a file I think we very well may want to do return type inference as well.

@JoshuaKGoldberg @jfmengels Huh, that’s an interesting perspective! How would the types be better than what you’d type out? And wouldn’t that imply the calling code is becoming very dependent on implementation details of the functions it calls?

@JoshuaKGoldberg FFI doesn’t work very well for calling Go code because Go has a runtime and doesn’t follow the C calling convention, which is effectively the “gold standard” if you want your code to be calleable through FFI. So there seem to be solutions for calling Rust from Go but not really the other way around.

#Rust #RustLang #Go #GoLang

@jfmengels And as an implementor, we may very well end up supporting TypeScript’s Isolated Declarations mode only, simply refusing to do full inference on functions that don’t have return type annotations. At least it doesn’t appear to be a high priority to go further than that right now, but who knows…

@jfmengels wrote:

> Since type annotations make type inference easier, how much do you hate the common TS advice to not annotate the return type at the moment? 😄

Ha! Yeah, not a fan. Even as a user of the language, I generally think it’s just lazy to leave the return type off. For a few characters extra you get a free type assertion, added readability, and you avoid unexpected action at a distance in case of bugs.

Over the weekend, I wrote an overview of Biome's type architecture, including our motivation and a discussion of the constraints that led to this architecture: https://arendjr.nl/blog/2025/05/biome-type-architecture/

Reply to this post to comment!

#OpenSource #WebDev #Tooling #JavaScript #TypeScript #Rust #RustLang

@JoshuaKGoldberg Do you mean like this? https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come/

It’s an older post, but it shows the basic design of error messages quite well.

@JoshuaKGoldberg @tseslint It would provide for an inventory of where we’re currently falling short (I can think of a few things, but an outside perspective is certainly useful!) as well as give very valuable exposure so we get more eyeballs (and who knows, collaborators) on our efforts. Happy to help write such a post!

@JoshuaKGoldberg @tseslint Thanks, that’s a great question!

Best I can think of right now: Awareness is a killer feature. I don’t know how you intend to finish this blog series, but an entry with reflection on how your ideal architecture could map back to what Biome’s architecture provides would be very valuable I think.

@JoshuaKGoldberg You know we’d happily collaborate on enabling TypeScript rules in Biome 😉

We just released a new beta version of v2. It contains many fixes and enhancements.

https://github.com/biomejs/biome/releases/tag/%40biomejs%2Fbiome%402.0.0-beta.2

Looks like your migration went well 😉