[Olreich]

STM is about hardware, not programming languages, but is decently recent so maybe someone will actually try it in hardware and see if it provides a good benefit for the increased complexity of the chip.

Region based memory management was first conceived in 1967 and is achievable by any programming language that lets you manage memory yourself.

Mutable value semantics in native code have been available since at least 1980 with Ada.

Lifetimes in Cyclone seem the best example of PL research in the last 50 years you have there, as it’s only 20 years old.

Overall, I’m still unsure if this list proves the point that there is active useful research in the PL space or if it proves that there’s very little in the PL space to research. More research is probably required.

[justinpombrio]

> STM is about hardware, not programming languages

As others have pointed out, there's STM research in PL, it's not entirely about hardware. (The link I gave wasn't great, sorry.)

> Mutable value semantics in native code have been available since at least 1980 with Ada.

Could you link to the relevant docs? I wasn't aware Ada had anything like this.

Is this implemented under the hood with deep copying? Because if so, that would explain why it hasn't started to catch on anywhere until now. Swift and Hylo have much more efficient implementations that "copy all the time".

https://www.jot.fm/issues/issue_2022_02/article2.pdf

> Region based memory management was first conceived in 1967

There's active research in this general space. I met someone who was working in it on a train, though I forget the details.

> and is achievable by any programming language that lets you manage memory yourself

Sure. I mean Rust lifetime discipline is "achievable" in C too, so long as you're very very careful.

> Lifetimes in Cyclone seem the best example of PL research in the last 50 years you have there, as it’s only 20 years old.

It typically takes 10+ years for PL research to go from papers to research languages to being incorporated into"real" languages.

> More research is probably required.

Always.

[Jtsummers]

> STM is about hardware, not programming languages

STM is not about hardware, it's literally "software transactional memory" and is meant to be implemented in software without hardware support (beyond a CAS instruction or a similar set of instructions, perhaps). As a software component it could be part of libraries or part of a programming language as part of that language's general concurrency model.

[Kranar]

The paper that OP linked to is indeed about hardware transactional memory, but STM is a variation of transactional memory that is implemented entirely in software.