(Author here) it depends on your use case. If you need to incrementally acquire locks, then levels are helpful -- you can't do that with LockSets on their own. A place where this comes up is if you need to read a value out of one lock, and pick what to lock next based on that without releasing the first one, and then modify both. Of course you should think twice when doing this but when you need it, you REALLY need it.
Opting out of lock levels was a design goal. By default all locks are are Level1, so the level can be omitted thanks to the default type parameter filling it in for you. Levels have no runtime cost, so sidestepping them is free. This lets you live in an atomic-locks only world if you want, and if you later find that you need incremental locks, you can add more levels at that time :)
[EDIT: fixing autocorrect typos when I got back to my laptop]
(Author here). Early in development I did exactly this with a macro. It was confusing when you wanted to refactor the code to change lock orders, harder to make clear error messages, and so on. Forcing the user to assign in a level means that it's clear(er?) to users what's happening, we don't need fancy (and difficult to debug) macro magic, and users can still do the linearisation themselves. That's the HOPE at least.
IMO compile time locking levels should be preferred whenever possible... but the biggest problem with compile time levels is that they, well, check at compile time. If you need to make mutexes at runtime (eg mange exclusive access to documents uploaded to a server by users) then you need to be able to safely acquire those too (provided in surelock with LockSet).
Author here! This post was human written, LLM proofread, and edited a couple times as folks pointed out broken links and minor errors when it was posted to r/rust a few days ago. As someone mentioned lower in the thread, there's a form of what is sometimes called Bay Area Standard that both very online humans and LLMs have absorbed. I find it FASCINATING that we're in an era where we have to prove our humanity, and the downstream behaviours of things like killing em-dash use in response are interesting to watch in real time. I've made the same mistake, so it's honestly difficult to tell!
Author of the article here! I've actually come to agree with you since writing that article. I'm actually not a fan of mutexes in general and miss having things like TVars from my Haskell days. Just to shout out a deadlock freedom project that I'm not involved in and haven't put in production, but would like to see more exploration in this direction: https://crates.io/crates/happylock
An absolute banger of a paper! (Hellerstein is a coauthor, so immediately expected to be good). Definitely some stuff in here that's further out, but a very clear articulation (or roadmap!) of where distributed systems could go.
Verified lifting is very cool but needs lots of research, though I'm unclear that's a hard requirement for this vision to become reality.
> I wonder how these two cope with one another. To me, you're either not local (must connect to be sure your data have persisted) or you need something more than just browser. Otherwise you're at the mercy of browser vendor not to destroy your in-browser data with borked update.
Maybe a clarifying one-liner would be "it's local-first, not local-only" ;) There is totally a tension there from not controlling the browser itself. You're absolutely right that the browser can clear it cache pretty much whenever. In practice, this appears to happen less than advertised (the extra caution is a good default!), but it totally does happen. It's something that we've spend a bunch of time trying to figure out the balance on. We also have to recognize that we live in an online world, so there's a bunch of additional work going into making things feel instant when connected. Fission is pushing on both sides of the problem to basically get as close to "your data everywhere all the time" as possible.
The principle is that you should be able to show up to a web app and have it "just work" and not know that anything special is happening. Everything should work if you loose connectivity, or are on a plane (if we ever do that again). You should also be able to self-host your data, or have it cached in multiple places (which is a big advantage of IPFS).
Fission provides one way to automatically keep a second encrypted-at-rest copy outside of the browser while you have connectivity. There's nothing special about our IPFS nodes; they're just set up to make that smooth for the kinds of thing that you'd want to do with the SDK, and add some niceties like DNS automation so you're not always fiddling with hashes. Part of us presenting to the SIG was to try to get better access to local desktop IPFS nodes, so that those who want to turn the dial to "fully offline" can go further with that.
Hey, CTO of Fission here! It depends on what you're trying to do. We actually bootstrap a js-ipfs node directly in the browser, so you always have an IPFS node if your app uses our SDK. It's even set up to communicate across tabs, including handling the security for that use case.
If you want to publish something that other people on the internet can see, then yes, you need a path off your machine, such as WebSockets. This can be a peer IPFS node, or to Fission's servers, or your own self-hosted node to provide availability.
Part of presenting to the offline-fist SIG was to get more support for parts of this, like communicating between a desktop node (e.g. go-ipfs) and your in-browser js-ipfs instance, which doesn't work out of the box today.