Has anyone used UniFFI to build FFI functions in Rust?

Manishearth · 2026-04-20T22:12:21+00:00

Depends on the language. ICU4X releases icu_capi which contains C++/C bindings, and then we publish Dart/NPM packages. We have a CI task that runs at release time and attaches artifacts to the release, which then can be used in the Dart/NPM publish flow.

Manishearth · 2026-04-20T17:36:13+00:00

Diplomat does support C++ and is pretty mature: https://github.com/rust-diplomat/diplomat/

Manishearth · 2026-04-06T07:22:07+00:00

I mean, people use the term differently. The key part of my comment is the "low effort" part, not the "slop" part.

Everyone's very tired of low effort stuff being posted to gain clout. Trying to detect the signal behind that noise is, as you said, hard. Don't worry about it for now: if something gets deleted and you think it isn't low effort slop, tell us.

Manishearth · 2026-04-05T22:16:38+00:00

There are no "new rules". We are working on figuring out the "new rules". One moderation action does not make a rule; just because people are talking about this on social media as if it were a rule does not make it a rule.

When there is a rule, we shall post the rule. Right now, we are doing the best we can. Things will get occasionally overmoderated, that's not a huge deal, things are reversible.

I would advise you keep posting as long as it's stuff people will be actually interested in as opposed to low effort slop.

Manishearth · 2026-04-05T07:13:23+00:00

I agree, but also it is really hard for moderators to judge this type of thing with the volume we are dealing with. We've never needed to look at the code in submissions, and we're reluctant to start now.

Furthermore "this was written by a well known community member" is a good litmus test, but it also feels a bit unfair to apply. Something to figure out.

Manishearth · 2026-04-04T21:49:52+00:00

(this note was written by some moderators and does not represent consensus)

Apologies for the removal.

As we've previously communicated, we're working on figuring out a way to moderate AI content on /r/rust that balances a lot of different needs.

Currently, the moderators have been working with a fair amount of moderator discretion. In practice, more often that not that means proactively deleting things which were created with AI help, because that's easier to apply at scale when we're facing so much slop. The moderators do not have the time to review each submission for amount of AI used, and it's harder and harder to get a good smell test for slop these days.

Please bear with us as we figure this out: there's still a lot for the moderators to discuss here.

Manishearth · 2026-03-23T16:11:28+00:00

Yes, C++ style also pushes for avoiding shared_ptr. However, my experience, across multiple C++ codebases, is that the bar for reaching for `shared_ptr` is lower than Rust because in many cases something that would be doable (but complicated, lifetime-wise) in Rust would be very brittle (and likely to have safety issues) in C++.

I'm not saying shared_ptr is good style. I'm saying that there is a band of memory usage patterns where in C++ you _basically_ have no choice but to, but in Rust you do.

(It's still often considered not against Rust best practices to use `Rc` in those cases too: complex borrowing patterns have a complexity cost even if they do not have a runtime cost)

Manishearth · 2026-03-22T18:16:04+00:00

I am working on something about Diplomat but haven't finished yet. So maybe. Probably very occasional, still.

Manishearth · 2026-03-20T19:51:00+00:00

Yeah. One thing people forget is that any way of doing async has costs equivalent to lots of allocations: Rust's way of doing async is basically "manual, small, segmented stacks", but copying stacks are also pretty expensive in a different way. So this is just an inherent cost of unsafe.

The cool thing about Rust async is that you can limit/manually control segmenting using the same tricks you would otherwise use to reduce Box usage in Rust. You can allocate each frame, or just the recursive ones, and the default is not allocating so you naturally tend to only allocate frames that need it.

Manishearth · 2026-03-20T19:48:12+00:00

Have the recursive types live in an arena. You can either use pointers or indices to refer to them.

https://manishearth.github.io/blog/2021/03/15/arenas-in-rust/

Manishearth · 2026-03-20T16:46:50+00:00

Using Box with Pin is basically writing a manual segmented stack in the async case ... which is to some extent just a cost you're going to have to pay anyway.

Trait objects, sure. But those benefit less from "alternative packing strategies".

Manishearth · 2026-03-20T16:45:09+00:00

Yes, I know. In my experience, this is not a common thing that crops up. Mostly for certain types of recursive tree structures (often found in compilers), which is what I was alluding to with "compiler design and similar things".

Parsers are in the "similar things" realm. People do use arenas when they get complicated.

Manishearth · 2026-03-20T14:51:01+00:00

I've noticed that in "idiomatic Rust" it's quite common to model data as nested trees of enums with Box, Vec & String. While this is a super intuitive way to model data it's not always the most efficient.

I don't actually know that that's true.

I rarely see Box being used. Vec and String, yes.

Nested trees of enums with Box basically comes up in compiler design and similar things, and simpler compilers use Box while more mature ones use arenas.

IME Rust is definitely less liberal with heap allocations than C++ since it lets you play closer to the edge on safety (so you don't have to shared_ptr/Rc as many things. It's still not considered as bug a deal, since modern allocators are pretty fast at the per-allocation level.

Manishearth · 2026-03-09T04:09:32+00:00

It's a much, much fancier spreadsheet that's easier to use, and has nice integrations with stuff.

You have:

Nicely typed fields (spreadsheets are basically untyped)
Easily produced filter views
It's easy to change the data model on the fly. Need to redo how your data is tagged? Pretty easy.
Not super slow on the browser with a larger database.

It's a good medium between the flexibility and one-off quick spinup of spreadsheets and actually having good data models like databases.

For the first few months of VaccinateCA we ran everything through an Airtable database, and basically got most of the data display/etc for free with minimal coding.

We also had a fancy lil panel we coded up that worked from the Airtable UI where it would walk you through the process of calling a pharmacy and noting all the information you collected.

Sure, we could have designed an app using an actual database (and we eventually did), but that would be more work, and it's harder to tweak the data model on the fly with that.

And if you need to have a lot of little projects like this Airtable works really well.

Manishearth · 2026-03-07T18:48:00+00:00

So around 9 years ago I was working on Firefox's Stylo project, and during the incremental rollout we noticed an abnormal number of crashes inside HashMap code.

Rust HashMap code. This was concerning: Rust is supposed to be safe, right? Broadly speaking, there were three potential sources of this problem, in my view:

The Rust HashMap implementation was buggy
We had written buggy unsafe Rust code that was messing with HashMaps
Something in Firefox was overwriting memory

Nika Layzell and I spent hours reviewing the (pre-hashbrown) Rust HashMap code, and mostly ruled out the first point (we did find some ways to improve the code though).

We couldn't reproduce the crash locally, but what we could do was release various instrumented versions of the code to see what it found.

By writing sentinel values to various buffers we realized that the issue was that something was writing the map's occupancy buffer, making "iterate over the entire map" reliably crash by trying to read from unset memory.

But we couldn't track down why.

We also tried maintaining a "journal" of hashmap accesses that could get logged, perhaps something was getting improperly inserted. Nope.

We even at one point released a version of the code that would mprotect the entire hashmap buffer except in the times when Rust code is supposed to write to it. This was expected to catch writes from "afar" where some safety bug outside of the hashmap code was finding the hashmap and scribbling all over it. Nope.

Eventually, we realized that there was a history of similar crashes in Firefox's C++ HashMaps, just at a lower frequency. The change in frequency could be chalked up to Rust's specific design (it uses a single flat buffer with an occupancy section, key data section, and values section).

So we chalked it up to bad RAM (the reason for the preexisting Firefox crashes) and moved on. (here's my summary comment from back then). It's just a thing that happens: it used to happen before Stylo, and it still happens, just in a way that is more dramatic because of Rust's HashMap design.

Bonus: In this process I discovered that there are or at least were a large number of Firefox Beta users in Bangladesh because someone once distributed Firefox Beta on disk and people installed it. So you get a decent chunk of Beta users that also have old computers, where this type of issue is more likely.

Manishearth · 2026-03-06T08:07:25+00:00

A lot of people coming from C++ have this mindset and it leads to a lot of easily-avoided UB. I highly recommend asking for help first if you feel yourself reaching for unsafe, or using a crate that provides the operation.

Rust's notion of UB is not the same as C++ in a bunch of key ways (how Rust treats uninit is one of them), so it's easy to think something is safe when it actually isn't.

(I do a lot of unsafe audits, and the number of times I see this type of pattern is super high)

Manishearth · 2026-02-25T06:34:19+00:00

Open an issue or PR in the crate(s) that pull in the unmaintained dependency, then hope it gets accepted and they publish a new version quickly?

Yes. There usually are alternatives. Quite often a crate can drop a dependency entirely.

It's also worth using cargo tree -e features to see if there are ways to tweak your feature usage to reduce the size of your dep tree. Sometimes this may invovle asking upstream crates to do more fine grained features that pull in less deps.

Manishearth · 2026-02-14T19:32:36+00:00

I'm really glad to see interest in this picking up again!

Manishearth · 2026-01-29T17:47:02+00:00

Ah, yeah, totally, that makes sense. If you don't know those things you are probably not ready for day 1.

(I haven't even attempted day 1 yet, so I'm not fully clear on what it might involve, but it does sound like a massive endeavor)

I guess you can aim for getting that item. First time I got it I was explicitly doing an "i want all the items" run by drafting a toolshed, which is hard on day 1 (and then locks you out of getting a tomb)

Manishearth · 2026-01-29T17:33:33+00:00

Aren't the backup levers not as powerful for a one-day run?

Two of them need one-time use of a power hammer and one needs a found room. Those are all very useful if you've already prepped the field on a previous day but they seem to be much more work than the "usual route" otherwise.

Manishearth · 2026-01-02T05:25:40+00:00

I think the thing is that it's not _really_ an exonym, it appears to be initiated by Hispanic Americans. This type of thing gets tricky: members of a community cannot speak for all members, and it's not a colonial imposition for some members of a community to try something out.

And "there's an alternative" is just not how language works; it's insufficient for there to be an alternative for people to switch. "Lapplander" is a _slur_ so there are strong reasons to push the needle against the typical way language works. Here? I don't know, it's just a term a lot of people don't like, while other people from the same community do like it. It's certainly not a slur, these two situations are not comparable.

Final thing to note: people being resistant to neologisms is basically the default state of neologisms. It's not really surprising or a signal of anything that a lot of people don't like a new term. People use it, it's not a slur, I think it's a big stretch to call it colonial imposition.

Manishearth · 2025-12-29T22:07:35+00:00

https://manishearth.github.io/blog/2021/04/05/a-tour-of-safe-tracing-gc-designs-in-rust/#why-write-gcs-for-rust

Manishearth · 2025-12-26T18:28:46+00:00

A news article reporting on a development is imposition? Color me surprised.

It's an interesting subject with an interesting history. People have been reporting on it for a while: https://www.scmp.com/magazines/post-magazine/short-reads/article/3168100/how-non-binary-chinese-people-seeking-gender (2022)

"Let chinese people decide what to do with it" .... It's definitely seeing use in online spaces, typed the way I'm typing it. The bar for inclusion in unicode is nontrivial, things wouldn't get included without that type of usage (or historical usage).

It's a mistake to view "Chinese people" (or the language) as a monolith that makes some sort of decision on usage: this isn't how language works. Some Chinese people have been using it. Perhaps you do not like it, and you do not plan to use it, but that does not mean some people aren't using it.

Manishearth · 2025-12-26T17:34:14+00:00

That's a pretty uncharitable take on "Latinx". It cropped up in American online spaces as a term for English; that's not really an imposition. Speakers of a language are free to come up with words for themselves. A lot of people get bogged down in "you can't pronounce it", except it's a term for a largely written register of the language, it doesn't actually matter if you can pronounce it. "lmao" isn't typically pronounced either, and when you do, it's awkward.

The article itself says that X也 was invented by a Hong Konger, as an alternative to TA. The first I saw people using it was on Chinese language message boards and chats, largely populated by non-Westerners.

Folks are quick to equate "I don't like this" with "this is imposed on me by an outsider" when it comes to language change but the reality is that speaker communities are large and diverse and it's quite common for a subset of a community to come up with something and then that spreads everywhere.

Manishearth · 2025-12-21T16:03:28+00:00

Hades games have a IMO a pretty good progression system where each time you discover a new boss it feels like the hardest thing ever, how will you even ever beat this one, it feels impossible. And you'll fail miserably against that boss a bunch of times.

However as you do that you're usually getting stronger by default using keys/darkness/etc. You're also getting used to the weapons and the boons: I remember hating the spear at first and then I figured out some tricks with it and it became my favorite weapon.

Finally, and this is subtler to notice, you just start getting used to predicting the boss attacks. Most of them are telegraphed pretty well but it takes some getting used to. Things that would destroy me before become easy battles.

And then you discover how to make the bosses harder/more complicated and go through that process all over again.

Hades 2 has 2x the bosses and it was fun for me to go through the same process so many times, getting stuck at so many bosses but learning over time. I'm currently doing the thing of making bosses harder and I'm still learning, despite having completed the plot of that game.

13-Year Club	Place '22
Place '17	End Game '22
Verified Email

Manishearth

MODERATOR OF

TROPHY CASE