jkelleyrtp

On the new FrontierCode [1] benchmark (ie graded from an OSS maintainer's perspective of "would I merge this code?")

- Opus 4.7 xhigh: 5.2%

- Opus 4.8 xhigh: 13.4%

- Fable 5 xhigh: 29.3%

Seems like a huge jump.

[1] https://cognition.ai/blog/frontier-code

I agree in principle with the math. But I believe that in reality if revenues don't show up quickly, then lenders will just restructure the debt and defer the payback period. Similar to SF commercial real-estate; many buildings should've come due during the depressed covid market, but lenders (banks) were willing to delay payment until the market picked up again.

The scale of these investments put the lenders at substantial risk, so the lenders will do anything to make it work. If the current lenders will be damaged by extended payback periods, they can simply sell the debt to someone else who won't be.

Dario (the founder) has a phd in biophysics, so I assume that’s why they mention biological weapons so much - it’s probably one of the things he fears the most?

claude swe-bench is 80.8 and codex is 56.8

Seems like 4.6 is still all-around better?

@deno team, how do secrets work for things like connecting to DBs over a tcp connection? The header find+replace won't work there, I assume. Is the plan to add some sort of vault capability?

I needed Mac / win/ Linux / iOS / android for dioxus dev, so I built my own in rust.

https://skyvm.dev/

I started building something for the dioxus team to have access to mac/linux persistent and ephemeral dev envs with vnc and beefy cpu/mem.

Nobody offered multiplatform and we really needed it!

https://skyvm.dev

WGPU for render, winit for window, servo css engine, taffy for layout sounds eerily similar to our existing open source Rust browser blitz.

https://github.com/dioxuslabs/blitz

Maybe we ended up in the training data!

I work on Dioxus (Rust WASM framework).

WASM for frontend, at least, has been held back by fundamental tools like bundle splitting, hot-reload, debugger symbols, asset integration, etc. We spent a lot of 2025 working on improving this. Vite and friends are really good!

I've been working on a big Dioxus project recently and am pretty happy with where WASM is now. The AI tools make working with Rust code much faster. I'm hopeful people gravitate towards WASM frameworks more now that the tools are better.

https://blog.cloudflare.com/incident-report-on-memory-leak-c...

better to crash than leak https keys to the internet

The browser UI will likely be more of a cool demonstration of the project instead of the end goal. We want blitz to exist to help make it easier to build stuff like lightpanda. There's a whole world of interesting browser forks that could exist but don't, and being able to easily remix the browser opens the door to new stuff like AI automation, hybrid native gui frameworks, better accessibility tools, etc.

That's why Rust was introduced into Firefox piece by piece. The goal wasn't to rewrite firefox in Rust - just to migrate the scary bits over to a memory safe lang. You can feel a lot of that in the servo codebase, weird pointer semantics as a result of needing to be API compatible with the C++ adapters.

If I were building a company around a new browser, I'd reach for the solid stuff that can be pulled in. Our whole blitz project is designed to be modular exactly for that use-case.

I mean you can opine about how Rust isn't suited for browser development, but as someone building a browser in Rust, I think it's just fine. If anything, Rust has been really shining in this project since Rust was designed to build a web browser.

https://github.com/dioxuslabs/blitz

Also I think it's a little ridiculous to build yet another new browser in a new language when so many amazing pieces are just sitting around ready for someone to use. Come contribute, we're already much further along :)

https://github.com/DioxusLabs/blitz/pull/292

It seems like the economy is on a “K” shaped flywheel. How much worse can the economy get for the regular worker before the systems just pops? We’ve put so much speculation into an AI/tech salvation that seems premature, especially when you look at ROI vs depreciation timelines.

I’m not sure what timeline to place on that but there has to be a floor for how bad it can get for the regular man.

Shit is just expensive. Young people can’t buy houses, good jobs are drying up, and inflation isn’t stopping.

I think a hallmark of 2025 is a resounding lack of empathy and compassion from people. Maybe's it's smartphones, social media, or some sort of existential doomerism.

To reframe your scenario: imagine you went to a school and some of your classmates came from poor families and couldn't afford clothes, food, or a laptop etc. To help those students, the teacher used class funds to buy them new shoes and get them a nice laptop to get their work done. Do you still think it's unfair that you don't get new shoes, laptop, or cookies?

The solution to your original question is to understand why the teacher is giving girls 4 cookies and then just be happy that more people get a fair shot at life.

In high school, I ran a robotics team that did lots of STEM outreach. We went to community centers, after school programs, and worked with other similar orgs like "girls who code."

I think we played an important role in the community. In our mission we stated we wanted to help bring "equity to STEM education."

In 2025, according to the current admin's stance on "DEI," my robotics team would not be able to receive grants without risk of being sued. It's plainly obvious the line is not drawn at restraining "overly progressive policies" - it's just arbitrarily placed so the govt can pick and choose the winners based on allegiance.

It's a shame that folks with a strong moral fiber are now punished for wanting to help their communities.

Gotta fetch images and stylesheets from the network!

Yeah not sure why someone's first reaction to seeing 150ms Rust hot-patches is to call it BS and a "pain-in-the-ass." Tough crowd.

We could aim lower, or make it entirely automatic. The first prototype was entirely automatic, but I realized that you definitely need to signal to the program to hot-reload.

For code like:

```rust

while true {

    let msg = io.poll();

```

you're now stuck because the program is hung on a syscall. Doesn't matter if you hot-patch the loop, the program is stuck. My first prototype used the exception tables to unwind the program, but that didn't work on WASM and led to weird issues with cancellation and effects.

Similar issues with one-time initialization code at the beginning of the program. You could just hot-patch from `main` - basically restarting the program - but the whole point of hot-patching is that you can keep as much state around as possible while also changing its behavior.

For most apps, you just need one `subsecond::call()` and it works. The bevy folks wrote a `#[hot]` macro which we might integrate, but I'm also keen for frameworks to just adopt it and/or distribute a simple universal adapter.

It’s a developer tool to speed up rust iteration, not a production tool like erlang.

That being said, bevy is using bevy-reflect to implement proper struct hot-reloading between hot-patches.

The challenge is that if the program is busy in a spin loop, there's no way to preempt it and modify it. Things like malloc, spin loops, network requests, syscalls etc.

I looked into liveplusplus a lot and their unreal integration also requires a broker to get the most out of it. If you're building a game engine and want to support struct layout and alignment changes, you'll need to do some re-instancing. Hiding a `subsecond::call` deep in the bowels of the host framework hides it from the user and lets the framework handle any complicated state management it needs during hotpatches.

I wouldn't say it's purity - the first version of subsecond actually did do in-process modification - but after playing around with it for a while, I much preferred the light runtime integration. The dioxus integration was about 5 lines of code, so it's quite minimal.

You basically need to wrap your program's `tick()` function. Otherwise you might be in the middle of malloc, hot-patch, and your struct's layout and alignment changes, and your program crashes due to undefined behavior.

The goal is that frameworks just bake `subsecond::current` into their `tick()` function and end-users get hot-patching for free.

There's a custom `axum::serve` equivalent we built that wraps the router construction in a hot-patchable function. When the patches are loaded, we reset the TCP connections.

It's a little specific to how dioxus uses axum today, but we plan to release an axum-only integration in the future.

Creator here - you only need one `subsecond::call` to hook into the runtime and it doesn't even need to be in your code - it can be inside a dependency.

Currently Dioxus and Bevy have subsecond integration so they get automatic hot-patching without any end-user setup.

We hope to release some general purpose adapters for axum, ratatui, egui, etc.

Creator here - haven't had a chance to write up a blog post yet! Stay tuned.

The gist of it is that we intercept the Rust linking phase and then drive `rustc` manually. There's some diffing logic that compares assembly between compiles and then a linking phase where we patch symbols against the running process. Works across macOS, Windows, Linux, iOS, Android, and WASM. On my m4 I can get 130ms compile-patch times, quite wicked stuff.

We handle the hard parts that the traditional dylib-reloading doesn't including TLS, statics, constructors, etc.

I've been posting demos of it to our twitter page (yes twitter, sorry...)

- With bevy: https://x.com/dioxuslabs/status/1924762773734511035

- On iOS: https://x.com/dioxuslabs/status/1920184030173278608

- Frontend + backend (axum): https://x.com/dioxuslabs/status/1913353712552251860

- Ratatui (tui apps): https://x.com/dioxuslabs/status/1899539430173786505

Our unfinished release notes are here:

https://github.com/DioxusLabs/dioxus/releases/tag/v0.7.0-alp...

More details to come!

The author's blog is a FANTASTIC source of information. I recommend checking out some of their other posts:

- https://mcyoung.xyz/2021/06/01/linker-script/

- https://mcyoung.xyz/2023/08/09/yarns/

- https://mcyoung.xyz/2023/08/01/llvm-ir/

`make myfile.mk` -> pwned

I do share the sentiment - and complain about this frequently - but any environment with build scripts can wreck your computer. Encrypt what you can, I guess, but software engineering is an extremely dangerous job wrt security.

I think this might be the “it” moment for AI/LLMs. I was hiking with a friend recently and we talked about this at length.

The arc-AGI results from O3 are apparently a result of chain of thought given enough time to explore a solution space. Reasoning might be simply a higher dimensional form of rubix cube solving. BFS, search, back-tracking, etc. It seems unlikely that humans think in “tokens” so why do LLMs?

By staying in latent space, the models are free to describe an “idea” in higher resolution than what language allows. English is coarse, granular. Latent space is a much finer representation of ideas and their interplay.

Latent space is also much cheaper to execute in. The model can think without the language encoding/decoding step. This lets it branch out hundreds of ideas and explore only the most useful ones in a fraction of time that reasoning “out-loud” would take.

The states also don’t need to be tied to language. Feed in a robot’s state, time series data, or any abstract data. Reason in category theory or linear algebra or complex analysis. Humans are hard wired for one set of math - an abstract latent space can represent anything.

I’m a bit disappointed OpenAI didn’t stumble on this first. I’ve been skeptical of LLMs since their big debut last year. LLMs seem like a great way of solving language, but reasoning is much more complex. Once you grok the math behind the current models, you immediately question why the encoding/decoding step is there. Diffusion models are incredible but it felt that LLMs lacked the same creativity. Encoding/decoding forces a token-based discretization and therefore a loss of complexity.

With the byte-latent paper it was quite clear we’d see this paper. This truly might be the “it” moment.

This version fixes a lot of inconsistencies in our hot-reload. We can't reload all Rust code, but we can reload some simple Rust expressions and way more RSX.

So you have a DOM, but if the target renderer is not webview or browser, you create a DOM in some other way?

Yes - we have a project called Blitz which is trying to emulate just the DOM without the browser. It's built on Servo/Firefox tech.

https://github.com/dioxusLabs/blitz

The browser is already there, and called webview on all major platforms. I'd say Electron is popular for maturity reasons, that architecture makes limited sense even if you are using web. Tauri would be a better comparison.

The default dioxus desktop/mobile renderer uses the system's webview for exactly this reason. The blitz stuff is still young but is planned to eventually replace the webview renderer. Fortunately, webviews are on many platforms already.

.. That also means users have to come up with the cross-platform API surfaces themselves, right?

Yes, but this is a challenge in every cross-platform framework. Flutter has pub.dev, react-native has expo modules, etc. In 2025 this will be a huge focus for us, and in all likelihood we'll just find a way to bind to existing widgets in the respective ecosystems. Easier than to try and bootstrap a pure-rust ecosystem (though it would be nice). Projects like our SDK do this, but the surface area is quite small when compared to what we eventually want to support.

http://github.com/dioxusLabs/sdk

It's very much inspired by Jetpack Compose and SwiftUI.

At the end of the day we just use the Rust Struct parser!

It's very similar to JSON or RON if you're familiar.

https://github.com/ron-rs/ron