I find his earlier works a bit too bizarre and quirky. Although Snow Crash is the essence of cool.
Seveneves is probably my favourite, I guess I prefer harder scifi. Fall; or, Dodge in Hell and The Rise and Fall of D.O.D.O. were pretty good too, although less so. I want to like the Baroque Cycle but I haven't managed to get into it so far.
I don't understand why, that is not HBM nor a real GPU. Fine the model might fit in RAM, kinda. And it a bit like a server that you can keep on all the time, which must feel nice if you only ever had a MacBook.
But it can still not run truly capable coding agents at reasonable speeds right?
That doesn't make sense for the cost of quite a nice new car. If you want to spend that much, build yourself a proper workstation at least. Clearly a computer with the form-factor of an Apple TV is not going to be ideal for getting the highest performance for your buck.
Is it just wannabe vibentrepreneurs with too much spare money hyping each other up?
Frankly, it sounds like you are being a bit short-sighted with the whole endeavour.
The lowered production costs enabled by AI should to a degree insulate you from the usual financial risks, and should allow you to be more authentic. It might seem risky to make niche content, but I think it could help attract a real initial audience, never underestimate the demand for true authenticity.
It might sound strange talking about authenticity when it comes to AI, but I do agree with your perspective, that it can empower creative thinkers to produce content with real authorial intent directly, and without the compromises inherent to large production teams.
You seem to be operating like a corporate production company with large costs that needs to appeal to the lowest common denominator to get ROI, but you are doing it without the benefits of the higher production budgets.
You are wasting your advantage. Do the things they cannot afford to do because they are too risky or too niche. If you say that AI allows you to empower your writers, don't waste their talents on brainless content!
That’s a good visualization, although I am a bit mistrustful of Arena’s scores. It does get around the fact that models are getting trained for the benchmarks, but the methodology of letting random people compare outputs side-by-side is a very shallow judgement method in my opinion.
EDIT: Indeed looking at the overall rankings for text again, the list is rather strange, a lot more about writing style than intelligence.
I was confused too, but I believe that it refers to the Pareto Frontier: the best set of solutions to a multi-objective problem.
Look it up, it’s a bit difficult to explain concisely in words but it is intuitive visually.
If we are thinking of intelligence and price, a model will be in the Pareto Frontier if there’s no cheaper model of the same or higher intelligence. Or if there’s no more intelligent model for that price or lower.
So for example DeepSeek V4 Pro can be considered a frontier model because there's no cheaper model that is as intelligent.
For any solution in the Pareto Frontier, there no "no-brainer" alternative, in the sense that there's no other option that is better in some way without giving up something else. It's the best of its "weight-class".
You can use tokio::spawn_blocking to separate compute-heavy stuff, it gets handled in a separate thread pool. You shouldn’t need two tokio runtimes, that sounds problematic.
> How do you properly mix IO/compute (in any language)?
Good question, it’s a really hard problem.
In principle you are meant to use threads, the OS will automatically switch to other work while you are waiting for IO, like with async. But there are difficulties with threads too: memory overhead, switching overhead, thread limits… Although I am getting the feeling that they have a much worse reputation than they deserve. More projects should try switching to threads and actually measuring the difference.
That does clarify some things, but still. Say you have an Isolate pinned to a core and it's doing some long compute. In the meantime some background IO finished and an Isolate in the same core needs to handle the result. That will not happen until the long compute is done.
Isn't it just like in async and any other cooperative concurrency model? At least in multi-core async, that message can be handled in a different core so it's not completely stuck. But sure the author doesn't like that work-stealing cost happening automatically outside of their control, fair enough.
Yes I do agree. It's not that Tokio has taken over just due to community momentum. There's a certain subtle lock-in that happens due to how the Rust type system and dependency system work together. It's a hard problem to address.
Regarding mixed IO/compute and preemptive scheduling, well that's what threads are. They are not as lightweight, but they are there and they are quite ergonomic to use in Rust.
I could even imagine an async executor that simply starts a thread per task, so that you can keep the nice syntax, but that's obviously not ideal from a performance standpoint. Tokio already dispatches tasks to a thread pool, it is not completely cooperative, it's the sensible way to do this. And there's always tokio::spawn_blocking too.
PS: Actually, it is underrated how well designed classic threading is in Rust. It was just going out of vogue when they did it, but they addressed so much of the complexity that was around for years in Java, C++ and the like. They did actually mostly achieve the holy grail of fearless concurrency and with a more ergonomic design.
I was looking forward to checking out Project Tina until I realised it was a completely different language. Classic story. Surely you can build a thread-per-core message passing concurrency framework in Rust, the language is designed to allow such alternatives.
Is Project Tina a bit like the Actor Model, but having actors pinned to cores?
And I don't understand how Tina deals better with the problem of compute-heavy tasks blocking the thread. It looks to me like it is also cooperative concurrency per core, and if one Isolate runs for a long time the other Isolates in that core will not be able to handle their messages.
I agree that a request-response model can be quite ergonomic for concurrency. I've used this pattern in quite a few Rust projects in a somewhat ad-hoc manner.
It's a bit like having a system composed of microservices (nanoservices?) that communicate via function calls.
It sounds a lot like the actor model, but I always found the classic architecture too limiting: requiring every actor to be a single-threaded message processor, instead of being able to handle requests concurrently. It's not too different from classic object-oriented design either, with singleton services.
In some project I've called my concurrent services Gods just to have a bit of fun with it :)
To be fair, the Rust async model itself was intentionally designed not to be prescriptive in the way you describe. You can build, and there exists, different task executors that can handle things like priority and many other execution models.
Async is just a way to describe a tree of concurrent tasks that may depend on (wait on) each other at certain points. It is mostly declarative.
Tokio has taken over as the default choice, but there's a reason why it's not part of the standard library, it is not meant to be the only choice.
We are creating an AI for science and engineering: https://vicena.ai
It's connected to all papers of course, and all kinds of scientific simulators and specialised models. But I'm currently in Shanghai talking to labs to join a CloudLab (and hopefully setting up our own robotic labs), so that AI can actually order real physical experiments that are executed cheaply, efficiently and seamlessly as tool calls.
Through experiments like autoresearch we have seen that AI is already, if not always smarter, at least more systematic than humans at following the scientific method relentlessly (hypothesis-experiment loop). Let's see what we can do by connecting it to the real-world :)
I initially quite liked it, particularly when the references are a bit more obscure, generally from classic scifi/fantasy. You can end with a nice sounding name and a small wink to fellow nerds.
But it is such a shame that it has started to become the brand of dark-side (militaristic/authoritarian) Silicon Valley: Palantir, Anduril, this… Tolkien would be so very sad.
PS: Palantir is at least rather fitting and honest, it’s literally an evil crystal ball (at least the one shown in the movies).
As a founder who has gone through scaling processes, I am quite impressed at Zuckerberg's ability to remain relatively competent and relevant at the top role throughout the whole journey. The skillset required changes quite a lot in each phase.
There are very few cases where the archetypical young garage-founder has stayed on top in the long-run.
I’m sure there will be a ton of unexpected complexities that arise only when you are trying to push the limits, like in all engineering domains. And it’s all a highly interconnected system, you cannot expect to dramatically change the water flow without impacting others aspects.
I know it is quite distant, but from my experience in large-scale data engineering, 90% of the time goes in addressing subtle issues that can only be observed hours into a job, the rest of the issues are quickly resolved earlier. I am assuming that such complexities will be so much harder in physical systems, and even more so in biological systems.
Seveneves is probably my favourite, I guess I prefer harder scifi. Fall; or, Dodge in Hell and The Rise and Fall of D.O.D.O. were pretty good too, although less so. I want to like the Baroque Cycle but I haven't managed to get into it so far.