Project Verona: Fearless Concurrency for Python
37 comments
·May 15, 2025zenkey
pjmlp
I think people are still fooling themselves about the relevance of 3GL languages in an AI dominated future.
It is similar to how Assembly developers thought about their relevance until optimising compilers backends turned that into a niche activity.
It is a matter of time, maybe a decade who knows, until we can produce executables directly from AI systems.
Most likely we will still need some kind of formalisation tools to tame natural language uncertainties, however most certainly they won't be Python/Rust like.
We are moving into another abstraction layer, closer to the 4GL, CASE tooling dreams.
albertzeyer
4GL and 5GL are already taken. So this is the 6GL.
https://en.wikipedia.org/wiki/Programming_language_generatio...
But speaking more seriously, how to get this deterministic?
pjmlp
Fair enough, should have taken a look, I stopped counting when computer magazines buzz about 4GLs faded away.
Probably some kind of formal methods inspired approach, declarative maybe, and less imperative coding.
We should take an Alan Kay and Bret Victor like point of view where AI based programming is going to be in a decade from now, not where it is today.
Wowfunhappy
Assemblers and compilers are (practically) deterministic. LLMs are not.
pjmlp
Missed the part?
> Most likely we will still need some kind of formalisation tools to tame natural language uncertainties, however most certainly they won't be Python/Rust like
zenkey
Yes I agree this is likely the direction we're heading. I suppose the "Python 4" I mentioned would just be an intermediate step along the way.
kryptiskt
I'd think LLMs would be more dependent on compatibility than humans, since they need training data in bulk. Humans can adapt with a book and a list of language changes, and a lot of grumbling about newfangled things. But an LLM isn't going to produce Python++ code without having been trained on a corpus of such code.
johnisgood
It should work if you feed the data yourself, or at the very least the documentation. I do this with niche languages and it seems to work more or less, but you will have to pay attention to your context length, and of course if you start a new chat, you are back to square one.
procaryote
100% coverage won't catch 100% of bugs of course
pseudony
Ownership models like Rust require a grester ability for holistic refactoring, otherwise a change in one place causes a lifetime issue elsewhere. This is actually exactly what LLM's are doing the worst at.
Beyond that, a Python with something like lifetimes implies doing away with garbage-collection - there really isn't any need for lifetimes otherwise.
What you are suggesting has nothing to do with Python and completely misses the point of why python became so widely used.
The more general point is that garbage collection is very appealing from a usability standpoint and it removes a whole class of errors. People who don't see that value should look again at the rise of Java vs c/c++. Businesses largely aren't paying for "beautiful", exacting memory management, but for programs which work and hopefully can handle more business concerns with the same development budget.
pjmlp
While I go into another direction in a sibling comment, lifetimes does not imply not needing garbage collection.
On the contrary, having both allows the productivity of automatic resource management, while providing the necessary tooling to squeeze the ultimate performance when needed.
No need to worry about data structures not friendly to affine/linear types, Pin and Phantom types and so forth.
It is no accident that while Rust has been successful bringing modern lifetime type systems into mainstream, almost everyone else is researching how to combine linear/affine/effects/dependent types with classical automatic resource management approaches.
oivey
I mean, why not just write Rust at that point? Required static typing is fundamentally at odds with the design intent of the language.
trealira
A lot of people want a garbage collected Rust without all the complexity caused by borrow checking rules. I guess it's because Rust is genuinely a great language even if you ignore that part of it.
Elucalidavah
> a garbage collected Rust
By the way, wouldn't it be possible to have a garbage-collecting container in Rust? Where all the various objects are owned by the container, and available for as long as they are reachable from a borrowed object.
logicchains
Isn't garbage collected Rust without a borrow checker just OCaml?
coolcase
Is Go that language?
fmajid
Microsoft laid off the Faster CPython lead Mark Shannon and ended support for the project, where does this leave the Verona project?
pjmlp
They belong to Microsoft Research not DevDiv, so while that doesn't protect them from layoffs, certainly gives them some protection being under different management.
Microsoft Research sites tend to be based in collaborations with university research labs.
throwaway81523
I wish Python had moved to the BEAM or something similar as part of the 2 to 3 transition. This other stuff makes me cringe.
Findecanor
The filename of the formal paper[1] reveals the internal codename: "Pyrona".
1: https://www.microsoft.com/en-us/research/wp-content/uploads/...
kubb
Sounds like a fun job, I’d love to do something like this in my 9 to 5.
It’s also amazing how much work goes into making Python a decent platform because it’s popular. Work that will never be finished and could have been avoided with better design.
Get users first, lock them in, fix problems later seems to be the lesson here.
materielle
Python is about 35 years old at this point. It was the better language that had the better design and the fixed problems at some point in time.
Sure, maybe a committee way back in 1990 could have shaved off of some the warts and oopsies that Guido committed.
I’d imagine that said committee would have also shaved off some of the personality that made Python an enjoyable language to use in the first place.
People adopted Python because it was way nicer to use compared to the alternatives in say, 2000
darkwater
> Get users first, lock them in, fix problems later seems to be the lesson here.
Or with a less cynical spin: deliver something that's useful and solves a problem for your potential users, and iterate over that without dying in the process (and Python suffered a lot already in the 2 to 3 transition)
kubb
2 to 3 was possibly precisely because of user lock-in and sunk cost. This kind of global update was unprecedented, and could have been totally avoided with better design.
legends2k
Isn't this so common in computer science, haven't you heard of Worse is Better [1]?
fastball
Imo it is less about locking anyone in (in this case) and more about what Python actually enables: exceedingly fast prototyping and iteration. Turns out the ability to ship fast and iterate is actually more useful that performance, esp in a web context where the bottlenecks are frequently not program execution speed.
kubb
I agree that fast iteration and the „easy to get something working” factor is a huge asset in Python, which contributed to its growth. A whole lot of things were done right from that point of view.
An additional asset was the friendliness of the language to non-programmers, and features enabling libraries that are similarly friendly.
Python is also unnecessarily slow - 50x slower than Java, 20x slower than Common Lisp and 10x slower than JavaScript. It’s iterative development is worse than Common Lisp’s.
I’d say that the biggest factor is simply that American higher education adopted Python as the introductory learning language.
procaryote
Python has compounding problems that make it extremely tricky though.
If it was just slow because it was interpreted they could easily have added a good JIT or transpiler by now, but it's also extremely dynamic so anything can change at any time, and the type mess doesn't help.
If it was just slow one could parallelise, but it has a GIL (although they're finally trying to fix it), so one needs multiple processes.
If it just had a GIL but was somewhat fast, multiple processes would be OK, but as it is also terribly slow, any single process can easily hit its performance limit if one request or task is slow. If you make the code async to fix that you either get threads or extremely complex cooperative multitasking code that keeps breaking when there's some bit of slow performance or blocking you missed
If the problem was just the GIL, but it was OK fast and had a good async model, you could run enough processes to cope, but it's slow so you need a ridiculous number, which has knock-on effects on needing a silly number of database/api connections
I've tried very hard to make this work, but when you can replace 100 servers struggling to serve the load on python with 3 servers running Java (and you only have 3 because of redundancy as a single one can deal with the load), you kinda give up on using python for a web context
If you want a dynamic web backend language that's fast to write, typescript is a much better option, if you can cope with the dependency mess
If it's a tiny thing that won't need to scale or is easy to rewrite if it does, I guess python is ok
johnisgood
Or Elixir / Erlang instead of Java / Kotlin, and Go instead of Python, for this use case.
meindnoch
The JS playbook.
null
pjmlp
This looks like a pivot on the Project Verona research, as there have not been much other papers out since the initial announcement, regarding the programming language itself.
I've been programming with Python for over 10 years now, and I use type hints whenever I can because of how many bugs they help catch. At this point, I'm beginning to form a rather radical view. As LLMs get smarter and vibe coding (or even more abstract ways of producing software) becomes normalized, we'll be less and less concerned about compatibility with existing codebases because new code will be cheaper, faster to produce, and more disposable. If progress continues at this pace, generating tests with near 100% coverage and fully rewriting libraries against those tests could be feasible within the next decade. Given that, I don't think backward compatibility should be the priority when it comes to language design and improvements. I'm personally ready to embrace a "Python 4" with a strict ownership model like Rust's (hopefully more flexible), fully typed, with the old baggage dropped and all the new bells and whistles. Static typing should also help LLMs produce more correct code and make iteration and refactoring easier.