The UK certainly does have continuous demand, our overall energy demand has rarely fallen below 25GW in the past couple of years. Right now gas makes up for much of that, the goal here is to replace gas with nuclear, using gas as baseload generation isn’t wise long term.
I’m sorry I struggle to understand your comment, but I’ll have a go.
> Saying “nuclear can handle the easy part” doesn’t help.
That’s literally how baseload works, look at France’s energy mix for an example, they have nuclear handle the bulk of their demand (at least the very minimum it will ever be) and renewables + transfers handle the rest, if renewables goes up they export it or lower their nuclear output (yes, their nuclear output can be modulated).
> You still need 20GW of extra capacity to cope
The goal isn’t to replace the entire energy mix with Nuclear, the goal is to add enough nuclear in the mix so that we don’t need gas being generating all year round (gas sets the price in the merit order so we don’t want it on 24/7). If you added just 6GW of nuclear you’d be achieving that on some days.
> gas sets the price in the merit order so we don’t want it on 24/7
I never quite understood the logic for this. Sure, if you overlay a simple upward sloping cost curve on a downward sloping demand-price curve, the market-clearing price is where they intersect, and that in practice much of the time is a gas generator.
But there must be a million other aspects that can affect what price needs to be paid to secure the capacity below that point. Surely only part of the total area under that market-clearing price needs to accrue to the generators?
And if generators are getting windfall profits, can't the market rules be adjusted so more of it can given to the consumers in the form of lower energy prices?
Can someone explain this? Maybe that is what actually happens, just it is too complex for the mass media.
First of, the UK are investing in battery storage, there’s already a rollout of grid-level battery systems across the country*.
None of them hold capacity for longer than 2 hours before they need to start discharging. In fact, the record breaking duration is 6 hours. This is great as a short buffer, but it’s not “storage”.
To put this in perspective, last year the UK went 2 weeks without any significant wind, so a 2 hour buffer is nothing. This is why Hydrogen is still being kept as an option for long term storage.
That said, today Boa has a whole team of maintainers who I’m sure will answer some questions here.
Yes the name does invoke the sense it’s a Python project but I liked it and stuck with it, I saw a Boa snake at a zoo once and knew I wanted to name my next project after it, I was also inspired by Mozilla at the time who named their projects after animals.
Speaking of Mozilla, Boa’s existence came to be because at the time I was working on Servo and wanted to include an all-rust JS engine, one didn’t really exist so I set about making one as a learning exercise, after around 2 years more joined me on that journey and today Boa is around 8 years old. It is not browser grade (although at 94.12% it is more compliant than some browser engines) but that doesn’t matter, plenty of Rust projects have found good use for it as they find it easy to embed and use, so we’re happy.
Another recent thing which we’re very proud is seeing our implementation of Temporal be used in V8 and other engines, so we’re also helping the wider ecosystem and raising all ships! (More here: https://boajs.dev/blog/2025/09/24/temporal-release)
We do hope to improve performance over the next year or so, hopefully that answers some of the Qs here.
Do you see catching up on performance with v8-jitless as a goal or is conformance the primary goal right now? Any plans on doing a JIT? I was always impressed by the idea of Truffle where you implement the language semantics once and you get both interpreter and JIT safely out of it which is a huge source of vulnerabilities in traditional JIT systems
Hi, I'm another one of the maintainers on the project.
In general, we are shifting more to performance now than conformance. We currently sit at around 94% conformance, so there's not really that much more to go conformance-wise. The remaining conformance gains are a couple of the newer specification features and Intl related features. Our current conformance can be found at https://boajs.dev/conformance.
Regarding performance, we are already making some gains, with hopefully more to come. The best example of this was probably the updates to script-bench-rs with our most recent release (which can be found at this commit https://github.com/khvzak/script-bench-rs/commit/d9635de77d2...). We still obviously have more to improve on, but we have already made some pretty steady progress from where we were.
EDIT: I forgot to answer your question about v8-jitless. Obviously in the future it would be nice to be able to be more competitive with v8-jitless, but at least for me, I'd just like to focus on improving the Boa overall.
Long answer: first, `fetch` is a runtime feature, and Boa is first and foremost an engine. So `boa_engine` -- the core project crate -- does not support `fetch` out of the box.
That being said, we do have a `boa_runtime` crate. This crate is not currently a full runtime, but it is a collection of runtime features that have been implemented and can be registered onto the context. `fetch` is one of the features that has an implementation completed in `boa_runtime`, and it does use reqwest if I'm remembering correctly. If you're interested to see some example code of registering features, you can look at our CLI code as an example :)
The past year has been huge for conformance for us, not only we caught up with the top engines but we surpassed them when working on Temporal and having all tests pass for that.
We hope to wind down some of the conformance priority now and focus on performance, we need to work on a new GC, refactor some parts of the engine, and improve various areas.
The idea of a JIT has been raised and we’re not against it, but it’s not on our plans right now (because of the above), that being said there is an open discussion.
You might want to look at the way the BEAM guys implemented their JIT in a slightly simplified and less performant (but obviously in way that is easier to reason about and extend and build upon) should you go down this road! Interesting project, I will take a look.
Right now, we use a forked and modified version of the `gc`. We definitely need to update it. Admittedly, I've been hoping to work on it but got a little distracted with temporal ...
I don't think I've actually heard of rsgc before. It's definitely interesting to see playXE put it together. I know that they'd been working on starlight at one point, so it'd be interesting to see takeaways from it.
To get to your question on the existing GCs, so far the answer is we don't truly know. We really need to do some GC experiments and test different options in Boa with JavaScript. There are not really that many GC crates out there of which I'm aware. There rust-gc's `gc` crate, dumpster, and `arena-gc` (tack on rsgc). But of those, the `gc` crate truly has the best API that we've used in Boa, but the performance is not ideal amongst other optimizations. It would be nice to preserve that API while improving the performance as well. But that remains to be seen.
I have no experience with them. In any case, it would be advisable to make the GC implementation swappable so that the language is gc-implementation-agnostic.
Congrats in general! The Temporal in rust release happening in Chrome & others is so cool! So exiting to see such a core piece of work being done & then shared widely among browsers. Speaks well to Rust, the trust folks have in it, and the ability to use Rust from a variety of projects.
There's also a very lovely talk
Cross-Engine Contributions at Scale: How newcomers accelerated Temporal and Upsert in SpiderMonkey, V8, and Boa that goes deep in depth in how technically Temporal was used across engines.
https://www.youtube.com/watch?v=WieD_9BswAE
Thanks! Temporal_rs has been a really fun project to work on, and it's been great to see that it's useful for other engines!
Hopefully, there will be more chances in the future for projects like temporal_rs. Beyond just temporal_rs, I think the Temporal integration in V8 and Kiesel was a good proof of concept for Rust based libraries over FFI using Diplomat.
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`.
We're looking into the next release potentially being a v1.0, so maybe that option is a bit more possible after that release. But at the same time, I think Servo spends a decent amount of time maintaining the `mozjs` crate, so who knows.
I can't speak exactly for the other maintainers, but for me, I mostly enjoy working on Boa and Boa related things (I've spent the better part of the last year and a half on the temporal implementation). I think it would be cool to have a highly performant and conformant Rust JavaScript engine. So that's my goal :)
Servo would be difficult, becuase it uses the SpiderMonkey to manage it's entire DOM implementation (not just JS objects). Blitz would be much easier I think, but it would need to some work to allow JS objects to keep DOM objects alive.
Transmission is a real problem and just like Nuclear, we haven’t improved it in the past 30 years.
So both eastern green link projects (offering more capacity) are due to be finished in 2029, “ok” I think “but surely we’re doing some work onshore to improve the existing network in the meantime..”
> Due to ongoing project work for increased power flow from North to South across two Transmission Owner (TO) regions and the interaction of the outage plans, increased capacity across the boundary will be limited and intermittent till 2029
So basically no transmission, onshore or offshore is going to be improved until 2029, but we’re still green lighting wind farms in Scotland. I’m amazed someone has the foresight to increase generation but not transmission until now, how were these green lit in the past knowing full well this bottleneck existed.
Maybe it’s controversial, but id argue for stopping more generation until transmission or storage is sorted, otherwise curtailment is going to be even higher in the next few years.
I suspect part of the foresight was exactly to create this situation, where the problem is framed as lack of transmission capacity. Because the alternative - building transmission capacity before it was needed - is even less politically feasible. Public money can only be spent when the need is so blatant it can no longer be ignored, and then everyone sits around and says "well why didn't we do that sooner".
Of course, the same arguments killed the construction of onshore wind in England, which would have prevented needing the new powerlines (or at least not so much).
From the article, it looks like the problem is partially caused by significant parts of the transmission network being temporarily shut down due to ongoing upgrades. These could probably have been started slightly sooner, but they are already underway, so I don't think your point is weel supported.
Except that if those upgrades had been started 10 years earlier then there would have been lower demand (10 years less growth in demand). The reductions in capacity would have had a much lower effect on prices.
The real problem isn't curtailment but misaligned incentives that subsidize curtailment. In short, wind providers are being payed royally (many billions) to NOT produce wind energy. There's no incentive for them to be more efficient. Worse, because of the incentives, energy companies are just installing wind wherever they can without regard for the local infrastructure and demand. They get guaranteed pricing regardless of whether their energy is used. Not their problem if they have to throw double digit percentages of their energy away. They get paid anyway.
It's not a question of "efficiency"; as the original article points out, they're at the mercy of the transmission market. It's not their problem because .. it really isn't their problem and they can't solve it.
> installing wind wherever they can without regard for the local infrastructure and demand
Alternatively, installing it where the energy and topography is, and the local planning environment allows it. We wouldn't be in quite such a bad position if the Tory government hadn't banned onshore wind in England.
There is no such thing as a transmission market. The grid is a regional monopoly, and it doesn't "market" its capacity.
The issue here is that when too much power runs through a line, if you don't turn it off, it does [1]. Building more lines isn't exactly fast, or cheap, and it wasn't really a major focus of the people setting up subsidies for new production.
> It's not their problem because .. it really isn't their problem and they can't solve it.
It's not their problem because their subsidies scheme means they will get paid anyway.
> just like Nuclear, we haven’t improved it in the past 30 years.
That's plain wrong.
Transmission system have massively evolved compared to what they were 30 years ago. Typically, at the TSO I know, the way people work looks nothing like it was 30 years ago.
Nowadays, every 5 minutes, we simulate the whole network for each of the consumption forecasts we have (one per 15 minutes) in the next two hours, plus the effect of every network loss, plus we simulate whether the planned workarounds fix the situation.
There are also newer generations of automated protective mechanisms on the lines, new automata, a new SCADA, etc. The network has also been expanded significantly with several new interconnections, more interactions with our neighbours, etc.
On the "market" side, we have plenty of new tools that allow us to do what's explained in the article's introduction, since the system didn't work like that before Europe's electricity market reforms.
And that's just a very small part of what changed.
> Maybe it’s controversial, but id argue for stopping more generation until transmission or storage is sorted
It doesn't work like that. Transmission evolves over time according to needs. It makes no sense to "freeze" for a time to let TSOs adapt. What needs to be done, however, is maybe give the market a little bit less deciding power, and give the TSO a little better feedback loop to force market operator to provide workable solutions.
Also maybe the political forces pushing renewables with LCOE analysis need to understand that generation build cost is only a fraction of what's paid for an electric system.
The german economic ministry has recently proposed exactly that. Slow the addition of more generation while the grid catches up. As expected this proposal did not go over super well.
> Even if you’ve been doing JavaScript for a while, you might be surprised to learn that setTimeout(0) is not really setTimeout(0). Instead, it could run 4 milliseconds later:
I think it's still the case. The 4ms happens if you call setTimeout nested several times. I don't know the exact limit. But it's 5-ish times where that kicks in IIRC.
One aspect I haven’t seen anyone mention contributing to the decline is GitHub (part of your “improved tooling”)
These days you can go to the repo and there’s usually already an issue open with the problem and a workaround. Or if someone has a question on how to use the tool/software they ask there.
This, and first party developer forums. iOS questions will go directly to Apple's community forums. Same for SalesForce, or Elastic search etc.
There's just a higher noise/signal ratio, a real chance to get answers from experts, and it makes for a stepping stone if the issues needs to be bumped to paid support.
I really think you’re trying to use the wrong tool for the job here. Joplin isn’t designed for your notes to be modified outside of the ecosystem, the notes themselves are markdown so you can export or transfer them, but you can’t simultaneously edit them outside of Joplin. For that you’re better off with a folder of markdown files which you can push to Git.
Joplin is essentially an open source version of Evernote and a great alternative for people who enjoyed that style of application.
> Joplin isn’t designed for your notes to be modified outside of the ecosystem, the notes themselves are markdown so you can export or transfer them, but you can’t simultaneously edit them outside of Joplin.
With that feature the external editor is launched via Joplin, so the editing is still happening in the ecosystem. You can’t just open the notes from outside Joplin.
I don’t doubt for a second Ballmer would also be jumping onto the AI hype train if he was still running the show.
reply