Hi! I am one of the maintainer of rquickjs and llrt.
Are you looking to build node-like modules anytime soon? I think we could easily port most of the modules I wrote for llrt to your engine.
If we could get rid of the C code in our app, that would make me very happy.
I'm not aware of any plans to build node-like modules, but I think we have the basic support to potentially build them out ... but I could be overlooking or missing something. I'm not personally familiar with them. But defining and using a macro should hopefully be fairly straightforward in Rust with the macros from our latest release (https://boajs.dev/blog/2025/10/22/boa-release-21#boa_module). If we're missing something, feel free to let us know.
Any runtime functionality that has been implemented is available in `boa_runtime`. I've mentioned this elsewhere in the thread, but this crate is not a runtime itself (yet). Currently, it's a collection of runtime features like `console` and `fetch`.
- It works and does the job. I appreciate that we got this piece of tech for free when we needed with quickly.
- The doc is clearly written in a way to steer you toward their cloud (fair enough everybody needs to eat). Setting things up is not straight forward even after years of using it.
- Backend driven UI is just weird.
- The founder used to be very opinionated on some things but let bigger issues "rot", better now that they have grown as a business.
- The fact that they wont do SAML in kratos cause its part of their cloud thing and they bought another business speaks volume to me. OSS for ory is a growth strategy, their enterprise version cloud is also not the same as the OSS one.
For OAuth2 we considered Hydra but decided to build it ourselves since we want to host on prem and want to reduce moving parts. We will also likely end up replacing kratos eventually.
TLDR it is a good tech to consider instead of building it yourself. It makes sense for B2C freemium products since all other providers charge per seat. But its not the easiest to setup.
Oh my. The list of supported things is so long I just assumed it would obviously support SAML. That’s a big blind spot and possibly a deal breaker if somebody is looking for a versatile option.
Ory Kratos itself doesn't support SAML that is correct.
However the newest addition to the Ory ecosystem, called Ory Polis (formerly known as BoxyHQ) does close that gap.
It is also Apache2 licensed, do check it out here: https://github.com/ory/polis
In the end when supporting the non tech people in the family, what I would really like is to setup their device so they can install anything on Fdroid but nothing from the play store (unless approved by me) nor direct from an apk.
On the contrary, we need to drop all tariff but enforce a % of manufacturing in Canada. That way we can kick out the American manufacturers and the Chinese can take over those factories. This is the same strategy that the US did with Japanese car compagnies.
I am wondering if there is a larger RFC for Rust to force users to not hold a variable across await points.
In my mind futurelock is similar to keeping a sync lock across an await point. We have nothing right now to force a drop and I think the solution to that problem would help here.
I’m not convinced that this can help in a meaningful way.
Fundamentally, if you have two coroutines (or cooperatively scheduled threads or whatever), and one of them holds a lock, and the other one is awaiting the lock, and you don’t schedule the first one, you’re stuck.
I wonder if there’s a form of structured concurrency that would help. If I create two futures and start both of them (in Rust this means polling each one once) but do not continue to poll both, then I’m sort of making a mistake.
So imagine a world where, to poll a future at all, I need to have a nursery, and the nursery is passed in from my task and down the call stack. When I create a future, I can pass in my nursery, but that future then gets an exclusive reference to my future until it’s complete or cancelled. If I want to create more than one future that are live concurrently, I need to create a FutureGroup (that gets an exclusive reference to my nursery) and that allows me to create multiple sub-nurseries that can be used to make futures but cannot be used to poll them — instead I poll the FutureGroup.
(I have yet to try using an async/await system or a reactor or anything of the sort that is not very easy to screw up. My current pet peeve is this pattern:
data = await thingy.read()
What if thingy.read() succeeds but I am cancelled? This gets nasty is most programming languages. Python: the docs on when I can get cancelled are almost nonexistent, and it’s not obviously possible to catch the CancelledError such that I still have data and can therefore save it somewhere so it’s not lost. Rust: what if thingy thinks it has returned the data but I’m never polled again? Maybe this can’t happen if I’m careful, but that requires more thought than I’m really happy with.)
Note that forcing a drop of a lock guard has its own issues, particularly around leaving the guarded data in an invalid state. I cover this a bit in my talk that Bryan linked to in the OP [1].
I agree. It seems like this bug arises because one Future is awaited while another is ignored. I have seen this sort of bug a lot.
So maybe all that is needed is a lint that warns if you keep a Future (or a reference to one) across an await point? The Future you are awaiting wouldn't count of course. Is there some case where this doesn't work?
The ideas that have been batted around is called "async drop" [1]
And it looks like it's still just an unaddressed well known problem [2].
Honestly, once the Mozilla sackening of rust devs happened it seems like the language has been practically rudderless. The RFC system seems almost dead as a lot of the main contributors are no longer working on rust.
You also get a similar effect in multi-threaded runtimes by not arbitrarily making everything in your object model Send and instead designing your architecture so that most things between wake-ups don't become arbitrarily movable references.
In fairness, if you're a layman to the rust development process (as I am, so I'm speaking from personal experience here) it's damn near impossible to figure out the status of things. There tracking issues, RFCs, etc which is very confusing as an outsider and gives no obvious place to look to find out the current status of a proposal. I'm sure there is a logic to it and that if I spent the time to learn it would make sense. But it is really hard to approach for someone like me.
If you want to find out the status of something, the best bet is to go to the Rust Zulip and ask around: https://rust-lang.zulipchat.com/ . Most Rust initiatives are pushed forward by volunteers who are happy to talk about what they're working on, but who only periodically write status reports on tracking issues (usually in response to someone asking them what the status is). Rust isn't a company where documentation is anyone's job, it's just a bunch of people working on stuff, for better or worse.
To be fair, this information is hard to come by in companies as well, unless it's being tracked and reported by program managers. I wonder if it would be sensible for the rust foundation to use some funds to pay folks to help track and organize efforts which the wider community is deeply interested in better. I care about a lot of the things mentioned in this thread, but the cost of paying attention or needing to bother folks on chatrooms to get status prevents me from really staying abreast of the latest.
> I think "practically rudderless" here is fairly misinformed and a little harmful/rude to all the folks doing tons of great work still.
That great work is mostly opaque on the outside.
What's been noticeable as an observer is that a lot of the well known names associated with rust no longer work on it and there's been a large amount of turnover around it.
That manifests in things like this case where work was in progress up until ~2021 and then was ultimately backburnered while the entire org was reshuffled. (I'd note the dates on the MCP as Feb 2024).
I can't tell exactly how much work or what direction it went in from 2021 to 2024 but it does look apparent that the work ultimately got shifted between multiple individuals.
I hope rust is in a better spot. But I also don't think I was being unfair in pointing out how much momentum got wrecked when Mozilla pulled support.
The language team tends to look at these kinds of challenges and drive them to a root cause, which spins off a tree of work to adjust the core language to support what's required by the higher level pieces, once that work is done then the higher level projects are unblocked (example: RPIT for async drop).
That's not always super visible if you're not following the working groups or in contact with folks working on the stuff. It's entirely fair that they're prioritizing getting work done than explaining low level language challenges to everyone everywhere.
I think you're seeing a lack of data and trying to use that as a justification to fit a story that you like, more than seeing data that is derivative of the story that you like. Of course some people were horribly disrupted by the changes, but language usage also expanded substantially during and since that time, and there are many team members employed by many other organizations, and many independents too.
While the Mozilla layoffs were a stressful time with a lot of uncertainty involved, in the end it hasn't appeared to have had a deleterious effect on Rust development. Today the activity in the Rust repo is as high as it's ever been (https://github.com/rust-lang/rust/graphs/contributors) and the governance of the project is more organized and healthy than it's ever been (https://blog.rust-lang.org/2025/10/15/announcing-the-new-rus...). The language certainly isn't rudderless, it's just branched out beyond the RFC system (https://blog.rust-lang.org/2025/10/28/project-goals-2025h2/). RFCs are still used for major things as a form of documentation, validation, and community alignment, but doing design up-front in RFCs has turned out to be an extremely difficult process. Instead, it's evolving toward a system where major things get implemented first as experiments, whose design later guides the eventual RFC.
All major projects need to be done this way. Upfront design without any concrete feedback from a real implementation of that design will always be flawed unless incredibly simple. If anything, the next evolution of this is a process to determine which experiments are worth running to get to a point where you can come up with a sensible design. In organizations I've worked in, the first phase is known as problem framing, which quickly evolved into requirements gathering. From there you come up with several possible loosely defined designs which you pursue in parallel and then at some point, with data in hand you come back and decide on a path forward, possibly needing a few more iterations of experiments based on what you've learned. Reaching agreement early on the problem and requirements really does help the rest of the process move forward, and makes deciding on a final choice much simpler and less political.
That guy is taking a couple of data points and running with them. The US could not AT ALL freeze 2.5T of Chinese assets without major consequences. They froze 300B of russian assets and all other central banks are running away from the dollar. The share of reserve currency in USD is now at its lowest in many decades at 40% and gold is soaring.
Complex puzzle, I feel a key part is that the financing / financial sustainability of free software has not been solved. The author touches on it a bit by saying "when you sell hardware..." which kinda means no hardware == no revenue since you can't sell the software. I don't discount that Redhat is a thing, but it is the exception not the norm.
I do see it on exactly same way. A lot of people are conflating opensource with free. That model is not really sustainable if you want to do it for living.
I recently had to deal with Entra ID for the first time to setup Microsoft OAuth for our site and my god why is it so badly designed.
Just creating a tenant is a PITA and you get a default tenant you can't change without paying for Microsoft 365? Then you have subscriptions, Microsoft partners, Enteprise vs individual accounts, etc. All mixed with legacy AD naming and renaming, documentation with outdated screenshots, Microsoft Partners bullshit.
You literally cannot change your tenant ID and the form by default picks a random for you. There is a hidden form I found on reddit that lets you pick a tenant ID but wtf. Also by default you can't create a tenant without an existing Microsoft account, which everybody acknowledge is a chicken and egg problem.
Why would you ever want to change the tenant id? Thise are problems amateurs create for themselves that professionals dont care abouz at all.
I agree needing an account to create a tenant is not ideal. But that's nothing more than a minor inconvenience. If these are the big problems you make out with M365, then I think I can just shrug your opinion away.
There ist a whole industry clustered around this FUBAR that makes its living by helping companies navigate this shit. It has small and big players and they have no incentive to tell you that there is anything else you could use. The monthly Service fee is too tasty.
It takes like two minutes to create a tenant. Click Next a bunch, enter a credit card, you're done.
And yes they have different types of accounts and methods of billing. Their customer base is probably in the hundreds of millions. People are going to want options. I don't really see the issue there.
reply