8 ms·

Project Verona: Fearless Concurrency for Python

166 points by ptx 1y ago

fmajid 1y ago
Microsoft laid off the Faster CPython lead Mark Shannon and ended support for the project, where does this leave the Verona project?
- pjmlp 1y ago
  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.
  - tmpz22 1y ago
    > Microsoft Research sites tend to be based in collaborations with university research labs. Oh that should help with the project's stability and funding.
- sitkack 1y ago
  Boycott Microsoft. Don't work there, don't use their products.
  - 90s_dev 1y ago
    Why?
    - megous 1y ago
      [flagged]
      - robocat 1y ago
        > happily Anthropomorphising a corporation is fanciful. A manipulative writing technique given that it appears you're hallucinating an emotional state that you have no way to know! > have taken on a state in court You are suggesting Microsoft should get involved politically? That would also condone that they should get involved in subjects you wouldn't support. Trying to fix symptoms is a losing battle: the cause needs fixing.
        megous 1y ago
        MS is a group of people, led by people and people have emotions. Corporation is a legal abstraction/concept through which states views MS, for legal purposes and whatever. I don't have to, I can view it for what it is. An organized group of people doing stuff for both money and other reasons. Saying "MS does something" is a shortcut for "decision makers at MS doing something". I'm not suggesting anything other than that MS are boycot-worthy for their past decisions and actions, incl. recent ones. I'm not interested in "fixing" MS, it's much easier just to try to avoid it and its products. Yes, I don't know for sure whether this particular decision was done happily by someone in MS. It doesn't matter much, either in the end.
    - computerthings 1y ago
      [dead]
  - smt88 1y ago
    How does using their Python tools help Microsoft?
    - hilsdev 1y ago
      Embrace, extend, destroy
      - loloquwowndueo 1y ago
        Extinguish! Mind the alliteration! :)
        hilsdev 1y ago
        My apologies! That makes it that much better
    - akkad33 1y ago
      At the least telemetry and recognition in the software community. At worst training their AI
    - lucianbr 1y ago
      It's a large corporation. I'm certain someone asked that question and got an answer before starting producing Python tools. It's management's job to ask that question and get answers, you know.
  - davesque 1y ago
    Would be helpful to know why you think this. Even if there are common reasons that others could point to (and please don't; it won't be helpful), your comment doesn't make any sense without that context.
kubb 1y ago
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.
- fastball 1y ago
  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.
  - procaryote 1y ago
    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
pjmlp 1y ago
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.
zenkey 1y ago
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.
- oivey 1y ago
  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 1y ago
    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.
    - logicchains 1y ago
      Isn't garbage collected Rust without a borrow checker just OCaml?
      - johnisgood 1y ago
        Pretty much, I would say, in fact, I like OCaml better if we put the borrow checker aside.
Findecanor 1y ago
The filename of the formal paper[1] reveals the internal codename: "Pyrona". 1: https://www.microsoft.com/en-us/research/wp-content/uploads/2025/04/pyrona_camera_ready.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...
deleted 1y ago
[deleted]
throwaway81523 1y ago
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.
- pansa2 1y ago
  Python’s core developers don’t even seem to care about other Python implementations (only about CPython). There’s no way they would move to, say, PyPy as the official implementation - let alone to a VM designed for a completely different language.
  - throwaway81523 1y ago
    At the time of the original Py3 release, PyPy was not ready for wide use. Otherwise maybe there could have been a chance of it replacing CPython. They were in too big a hurry to ship Py3 though. Tragedy.
  - pjmlp 1y ago
    Which is a pity, Python ends up being the only major dynamic language, where for all pratical purposes there is no JIT support, because while there are alternative implementations with great JIT achievements, the comunity behaves as if all that effort was for nothing other than helping PhD students doing their thesis.
- toast0 1y ago
  I'm a big BEAM person, but python 3.0.0 was released december 2008. At that time, I believe OTP R12 was current, and it only gained SMP support in R11. [1] In 2008, I don't know that it would have been clear that the BEAM would be a good target. And I don't know how switching to BEAM then would have addressed what I think is the core issue python 3 was working on, unicode strings; BEAM didn't start taking on unicode until R13 and IMHO, is kind of on the slow end of unicode adoption (which isn't always bad... being late means adopting industry consensus with less of the intermediate false steps) [1] https://erlang.org/euc/08/euc_smp.pdf https://erlang.org/euc/08/euc_smp.pdf
froh 1y ago
I'd rather love to see confluent persistence in python, i.e. a git-like management of an object tree. so when you create a new call stack ( generator, async sth, thread) you can create a twig/branch, and that is modified in-place, copy on write. and you decide when and how to merge a data branch,there are support frameworks for this, even defaults but in general merging data is a deliberate operation. like with git. locally, a python with this option looks and feels single threaded, no brain knots. sharing and merging intermediate results becomes a deliberate operation with synchronisation points that you can reason about.
- traverseda 1y ago
  This is achievable with deepdiff today: https://pypi.org/project/deepdiff/ https://pypi.org/project/deepdiff/ Maybe not as performant as if you designed your data structures around it. But certainly achievable.
  - froh 1y ago
    interesting project thanks for the pointer however it's not what I have in mind the point is not being able to dog and patch object graphs the point is copy on write of data that isn't local to the current call stack, automatic immutability with automatic transients per call stack. a delta will then guide the merge of branches. but the Delta emergency from the CoW, instead of being computed as in deepdiff.
bgwalter 1y ago
This is the true Python concurrency effort! I know, I have followed many! (Life of Brian) So they sounded out the Faster CPython team, which is now fired (was van Rossum fired, too?): "Over the last two years, we have been engaging with the Faster CPython team at Microsoft as a sounding board for our ideas." And revive the subinterpreter approach yet again.
- zem 1y ago
  this will work very well with free threaded python you don't need sub interpreters. I agree that it's the most promising approach I've seen yet.
OutOfHere 1y ago
Microsoft just fired 3% of its staff, more than it ever did before. I would stick with type-checked free-threaded Python with locks and queues. Someone should be able to enhance the type checker to also check for unsafe mutation of variables.
- surajrmal 1y ago
  Only 3%. Hard to say this effort was affected
  - pansa2 1y ago
    3% of the whole company - but a lot of Python specialists were in that 3%. Including, apparently, the entire "Faster CPython" team.
akkad33 1y ago
"fearless concurrency" reminds of the buzzword for another language
- codr7 1y ago
  Yeah, programming used to be performed by programmers. Being afraid of concurrency, or pointers or whatever; makes no sense. Being aware, on the other hand, is a very good idea.
  - throwaway48476 1y ago
    Sometimes it's just really useful not having to worry about circular references.
    - codr7 1y ago
      I agree, but being afraid of them?
mgraczyk 1y ago
Is anyone familiar with Instagram's cinder? https://github.com/facebookincubator/cinder https://github.com/facebookincubator/cinder cinder includes changes for immutable module objects. I wonder if the implementation is similar? Or is cinder so old that it would be incompatible with the future noGil direction?
- zem 1y ago
  I work on cinder, it is primarily a JIT compiler, and does not have this sort of concurrency construct (which looks extremely exciting and well thought out, props to the verona team!). cinder is actively developed (we recently upgraded it to 3.12) and is definitely going to be compatible with free threaded (nogil) python.
ashf023 1y ago
If I understand it correctly, this is only catching ownership violations at runtime, so it doesn't actually prevent writing/shipping the bug? But it does seem to be able to improve the detection rate and determinism, and also help with diagnosing the bug when it's discovered. If this does let simple unit tests in CI discover concurrency bugs, that's a big improvement, even if it's not as strong as static analysis. I imagine there are still cases where the ownership violation is not deterministic though, e.g. depending on the data or the app's configuration, and maybe will not be caught until production

166 points by ptx 1y ago

Microsoft laid off the Faster CPython lead Mark Shannon and ended support for the project, where does this leave the Verona project?

pjmlp 1y ago
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.
- tmpz22 1y ago
  > Microsoft Research sites tend to be based in collaborations with university research labs. Oh that should help with the project's stability and funding.
sitkack 1y ago
Boycott Microsoft. Don't work there, don't use their products.
- 90s_dev 1y ago
  Why?
  - megous 1y ago
    [flagged]
    - robocat 1y ago
      > happily Anthropomorphising a corporation is fanciful. A manipulative writing technique given that it appears you're hallucinating an emotional state that you have no way to know! > have taken on a state in court You are suggesting Microsoft should get involved politically? That would also condone that they should get involved in subjects you wouldn't support. Trying to fix symptoms is a losing battle: the cause needs fixing.
      - megous 1y ago
        MS is a group of people, led by people and people have emotions. Corporation is a legal abstraction/concept through which states views MS, for legal purposes and whatever. I don't have to, I can view it for what it is. An organized group of people doing stuff for both money and other reasons. Saying "MS does something" is a shortcut for "decision makers at MS doing something". I'm not suggesting anything other than that MS are boycot-worthy for their past decisions and actions, incl. recent ones. I'm not interested in "fixing" MS, it's much easier just to try to avoid it and its products. Yes, I don't know for sure whether this particular decision was done happily by someone in MS. It doesn't matter much, either in the end.
  - computerthings 1y ago
    [dead]
- smt88 1y ago
  How does using their Python tools help Microsoft?
  - hilsdev 1y ago
    Embrace, extend, destroy
    - loloquwowndueo 1y ago
      Extinguish! Mind the alliteration! :)
      - hilsdev 1y ago
        My apologies! That makes it that much better
  - akkad33 1y ago
    At the least telemetry and recognition in the software community. At worst training their AI
  - lucianbr 1y ago
    It's a large corporation. I'm certain someone asked that question and got an answer before starting producing Python tools. It's management's job to ask that question and get answers, you know.
- davesque 1y ago
  Would be helpful to know why you think this. Even if there are common reasons that others could point to (and please don't; it won't be helpful), your comment doesn't make any sense without that context.

kubb 1y ago

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.

fastball 1y ago
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.
- procaryote 1y ago
  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

pjmlp 1y ago

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.

zenkey 1y ago

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.

oivey 1y ago
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 1y ago
  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.
  - logicchains 1y ago
    Isn't garbage collected Rust without a borrow checker just OCaml?
    - johnisgood 1y ago
      Pretty much, I would say, in fact, I like OCaml better if we put the borrow checker aside.

Findecanor 1y ago

The filename of the formal paper[1] reveals the internal codename: "Pyrona". 1: https://www.microsoft.com/en-us/research/wp-content/uploads/2025/04/pyrona_camera_ready.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...

deleted 1y ago

[deleted]

throwaway81523 1y ago

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.

pansa2 1y ago
Python’s core developers don’t even seem to care about other Python implementations (only about CPython). There’s no way they would move to, say, PyPy as the official implementation - let alone to a VM designed for a completely different language.
- throwaway81523 1y ago
  At the time of the original Py3 release, PyPy was not ready for wide use. Otherwise maybe there could have been a chance of it replacing CPython. They were in too big a hurry to ship Py3 though. Tragedy.
- pjmlp 1y ago
  Which is a pity, Python ends up being the only major dynamic language, where for all pratical purposes there is no JIT support, because while there are alternative implementations with great JIT achievements, the comunity behaves as if all that effort was for nothing other than helping PhD students doing their thesis.
toast0 1y ago
I'm a big BEAM person, but python 3.0.0 was released december 2008. At that time, I believe OTP R12 was current, and it only gained SMP support in R11. [1] In 2008, I don't know that it would have been clear that the BEAM would be a good target. And I don't know how switching to BEAM then would have addressed what I think is the core issue python 3 was working on, unicode strings; BEAM didn't start taking on unicode until R13 and IMHO, is kind of on the slow end of unicode adoption (which isn't always bad... being late means adopting industry consensus with less of the intermediate false steps) [1] https://erlang.org/euc/08/euc_smp.pdf https://erlang.org/euc/08/euc_smp.pdf

froh 1y ago

I'd rather love to see confluent persistence in python, i.e. a git-like management of an object tree. so when you create a new call stack ( generator, async sth, thread) you can create a twig/branch, and that is modified in-place, copy on write. and you decide when and how to merge a data branch,there are support frameworks for this, even defaults but in general merging data is a deliberate operation. like with git. locally, a python with this option looks and feels single threaded, no brain knots. sharing and merging intermediate results becomes a deliberate operation with synchronisation points that you can reason about.

traverseda 1y ago
This is achievable with deepdiff today: https://pypi.org/project/deepdiff/ https://pypi.org/project/deepdiff/ Maybe not as performant as if you designed your data structures around it. But certainly achievable.
- froh 1y ago
  interesting project thanks for the pointer however it's not what I have in mind the point is not being able to dog and patch object graphs the point is copy on write of data that isn't local to the current call stack, automatic immutability with automatic transients per call stack. a delta will then guide the merge of branches. but the Delta emergency from the CoW, instead of being computed as in deepdiff.

bgwalter 1y ago

This is the true Python concurrency effort! I know, I have followed many! (Life of Brian) So they sounded out the Faster CPython team, which is now fired (was van Rossum fired, too?): "Over the last two years, we have been engaging with the Faster CPython team at Microsoft as a sounding board for our ideas." And revive the subinterpreter approach yet again.

zem 1y ago
this will work very well with free threaded python you don't need sub interpreters. I agree that it's the most promising approach I've seen yet.

OutOfHere 1y ago

Microsoft just fired 3% of its staff, more than it ever did before. I would stick with type-checked free-threaded Python with locks and queues. Someone should be able to enhance the type checker to also check for unsafe mutation of variables.

surajrmal 1y ago
Only 3%. Hard to say this effort was affected
- pansa2 1y ago
  3% of the whole company - but a lot of Python specialists were in that 3%. Including, apparently, the entire "Faster CPython" team.

akkad33 1y ago

"fearless concurrency" reminds of the buzzword for another language

codr7 1y ago
Yeah, programming used to be performed by programmers. Being afraid of concurrency, or pointers or whatever; makes no sense. Being aware, on the other hand, is a very good idea.
- throwaway48476 1y ago
  Sometimes it's just really useful not having to worry about circular references.
  - codr7 1y ago
    I agree, but being afraid of them?

mgraczyk 1y ago

Is anyone familiar with Instagram's cinder? https://github.com/facebookincubator/cinder https://github.com/facebookincubator/cinder cinder includes changes for immutable module objects. I wonder if the implementation is similar? Or is cinder so old that it would be incompatible with the future noGil direction?

zem 1y ago
I work on cinder, it is primarily a JIT compiler, and does not have this sort of concurrency construct (which looks extremely exciting and well thought out, props to the verona team!). cinder is actively developed (we recently upgraded it to 3.12) and is definitely going to be compatible with free threaded (nogil) python.

ashf023 1y ago

If I understand it correctly, this is only catching ownership violations at runtime, so it doesn't actually prevent writing/shipping the bug? But it does seem to be able to improve the detection rate and determinism, and also help with diagnosing the bug when it's discovered. If this does let simple unit tests in CI discover concurrency bugs, that's a big improvement, even if it's not as strong as static analysis. I imagine there are still cases where the ownership violation is not deterministic though, e.g. depending on the data or the app's configuration, and maybe will not be caught until production