I agree with the author: it's a shame that TVars aren't catching on in more languages. They are a great idea from the database world, that we could use in the rest of computing, too.
One thing that I think do affect things, is that language design discussions tend to be concentrated into their own communities based on the programming language itself, rather than one "programming language discussions" place where everyone can easier cross-pollinate ideas across languages. Luckily, there are some individuals who move between communities without effort, which does lead to a bit of ideas making it across, but it feels like we're missing out on so much evolution and ideas from various languages across the ecosystem.
Oh, many of these travelers spend a lot of effort!
Supercomputing is another domain that has deep insights into scalable systems that is famously so insular that ideas rarely cross over into mainstream scalable systems. My detour through supercomputing probably added as much to my database design knowledge as anything I actually did in databases.
(Speaking from the perspective of someone who simultaneously loves high-performance compute and agentic AI haha)
http://joeduffyblog.com/2010/01/03/a-brief-retrospective-on-...
> Models can be pulled along other axes, however, such as whether memory locations must be tagged in order to be used in a transaction or not, etc. Haskell requires this tagging (via TVars) so that side-effects are evident in the type system as with any other kind of monad. We quickly settled on unbounded transactions.
Snip
> In hindsight, this was a critical decision that had far-reaching implications. And to be honest, I now frequently doubt that it was the right call. We had our hearts in the right places, and the entire industry was trekking down the same path at the same time (with the notable exception of Haskell)
So basically not that TM isn’t workable, but unbounded TM is likely a fool’s errand but Haskell’s is bounded TM that requires explicit annotation of memory that will participate in atomicity.
It's the whole language, not just the TM code. Other languages have no way of opting out of the TM code, whereas Haskell does.
In Haskell it's just more economic and better integrated with the rest of the language and its typesystem.
The primary advantage of a new programming language is that there is no legacy code to be compatible with. The software ergonomics space has been thoroughly explored, but restricting programs to subsets with useful properties is still an untapped field. It's seen that way because professional programmers are not used to dealing with restrictions to expressive freedom. New languages are supposed to increase freedom.
The vast majority of new programming languages would benefit from the main language being as restricted as possible and then require you to opt into the features selectively.
Depends a lot on what you are doing. Clojure and Scala were new languages, but they had a lot of legacy code to stay compatible with. C++ falls in a similar camp.
Is easy, or hard?
Demand a new paradigm at large, or is only a inconvenience in the few places is used?
Because if the answer is "turns the language into Haskell" then is a big NOPE!
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n44...
To nicely support TVars, it's good if your language can differentiate between pure code and code with side-effects. Haskell's type system is one way to get there; but eg something like Rust could probably also be coerced to do something appropriate.
Apart from that, you probably don't even need static typing to make it work well enough (though it probably helps). You definitely don't need laziness or Haskell's love of making up new operators or significant whitespace.