# Announcing Air.jl: STM and immutable collections

**URL:** <https://discourse.julialang.org/t/announcing-air-jl-stm-and-immutable-collections/70361>\
**Category:** Package Announcements\
**Tags:** package, announcement\
**Created:** [October 26, 2021, 12:26am UTC](https://discourse.julialang.org/t/announcing-air-jl-stm-and-immutable-collections/70361 "2021-10-26T00:26:03Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![tkf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tkf/32/17635_2.png) [@tkf](https://discourse.julialang.org/u/tkf)\
**Post date:** [October 26, 2021, 4:51am UTC](https://discourse.julialang.org/t/announcing-air-jl-stm-and-immutable-collections/70361/6 "2021-10-26T04:51:46Z")

</div>

Yes, I think I know the intended use cases of STM. As I said, synchronization in transactions is arguably a bad idea. However, the usual pitch of STM is that it’s good for compositional API since nested transactions can be merged. This does not work well in general in Julia because using tasks or not is an implementation detail of a method and there’s no way to query this statically. But I don’t think it’s impossible. I sketched a design for ensuring method properties such as purity and `yield`-free: [Suggestion: Fortran-like Keyword to Assert Function is Pure - #52 by tkf](https://discourse.julialang.org/t/suggestion-fortran-like-keyword-to-assert-function-is-pure/63047/52)

For a bit of more context on my end, this is the reason why I’m interested in [https://github.com/JuliaConcurrent/Reagents.jl](https://github.com/JuliaConcurrent/Reagents.jl) which is kind of a fusion of STM and usual nonblocking programming. It can compose both nonblocking and synchronizing programs.

---

_[View the full topic](https://discourse.julialang.org/t/announcing-air-jl-stm-and-immutable-collections/70361)._