[vinkelhake]

This felt like a blast from the past. At a few times reading this article, I had to go back and check that, yes, it's actually a new article from the year 2025 on STM in Haskell and it's even using the old bank account example.

I remember 15 or 20 years (has it been that long?) when the Haskell people like dons were banging on about: 1) Moore's law being dead, 2) future CPUs will have tons of cores, and 3) good luck wrangling them in your stone age language! Check out the cool stuff we've got going on over in Haskell!

[lmm]

Yeah, remember when we used to care about making better programming languages that would perform faster and avoid errors, instead of just slapping blockchains or AI on everything to get VC money. Good times.

[doliveira]

Only half-joking: maybe Java was a mistake. I feel like so much was lost in programming language development because of OOP...

[exasperaited]

Java is most of why we have a proliferation of VM-based languages and a big part of why WASM looks the way it does (though as I understand it, WASM is the shape it is in some measure because it rejects JVM design-for-the-language quirks).

I would also not blame Java for the worst of OO, all of that would have happened without it. There were so many OO culture languages pretending to that throne. Java got there first because of the aforementioned VM advantage, but the core concepts are things academia was offering and the industry wanted in non-Ada languages.

I would say Java also had a materially strong impact on the desire for server, database and client hardware agnosticism.

Some of this is positive reinforcement: Java demonstrates that it's better if you don't have to worry about what brand your server is, and JDBC arguably perfected ODBC.

Some of it is negative: a lot of the move to richer client experiences in the browser has to do with trying to remove client-side Java as a dependency, because it failed. It's not the only bridged dependency we removed, of course: Flash is equally important as a negative.

[lmm]

> I would also not blame Java for the worst of OO, all of that would have happened without it. There were so many OO culture languages pretending to that throne. Java got there first because of the aforementioned VM advantage, but the core concepts are things academia was offering and the industry wanted in non-Ada languages.

Really? Were there other major contenders that went as far as the public class MyApp { public static void main( nonsense?

[bluGill]

OOP is very useful/powerful, don't throw the good parts out. Java messed up by deciding everything must be an object when there are many other useful way to program. (you can also argue that smalltalk had a better object model, but even then all objects isn't a good thing). Functional programing is very powerful and a good solution to some problems. Procedural programing is very powerful and a good solution to some problems. You can do both in Java - but you have to wrap everything in an object anyway despite the object not adding any value.

[igouy]

> everything must be an object when there are many other useful way to program.

Perhaps you would prefer a multi-paradigm programming language?

http://mozart2.org/mozart-v1/doc-1.4.0/tutorial/index.html

[kragen]

Java was derived from C++, Smalltalk, and arguably Cedar, and one of its biggest differences from C++ and Smalltalk is that in Java things like integers, characters, and booleans aren't objects, as they are in C++ and Smalltalk. (Cedar didn't have objects.)

[bluGill]

Right. Everything a user can do is object, but there are a few non-object built ins. (they are not objects in C++ either, but C++ doesn't make everything you write be an object)

[kragen]

In C++ integers and characters are objects. See https://en.cppreference.com/w/cpp/language/objects.html, for example, which explicitly mentions "unsigned char objects", "a bit-field object", "objects of type char", etc.

[mrkeen]

And it's all still true, although I would offer the usual argument that concurrency!=parallelism, and if you reach for threads&STM to try to speed something up, you'll probably have a bad time. With the overhead of GC, STM-retries, false-sharing, pointer-chasing, etc you might have a better time rewriting it single-threaded in C/Rust.

STM shines in a concurrent setting, where you know you'll multiple threads accessing your system and you want to keep everything correct. And nothing else comes close.

[exasperaited]

To be maximally fair to the Haskell people, they have been enormously influential. Haskell is like Canada: you grow up nicely there and then travel the world to bring your energy to it.

[VBprogrammer]

Yeah, I wrote an essay on STM in Haskell for a class back in 2005 I think.

[dist-epoch]

I think Intel x86 had some hardware support for STM at some point. Not sure what's the status of that.

[PhilipRoman]

Disabled on most CPUs, plagued by security issues. I haven't used it but I assume debugging would be extremely painful, since any debug event would abort the transaction.

[kragen]

That's not software transactional memory, it's hardware transactional memory, and their design was not a good one.

[gpderetta]

Well, HTM was not useful per se, except accelerating an STM implementation.

[kragen]

It isn't very useful for that, but you can use it to implement other higher-level concurrency primitives like multi-word compare and swap efficiently.

[gpderetta]

True. At some point in the now distant past, AMD had a proposal for a very restricted form of HTM that allowed CAS up to 7 memory locations as they had some very specific linked list algorithms that they wanted optimize and the 7 location restrictions worked well with the number of ways of their memory.

Nothing came out of it unfortunately.

[kragen]

I'd like to see what kind of hardware acceleration would help STMs without imposing severe limitations on their generality.

To me, the appealing things about STMs are the possibility of separating concerns of worst-case execution time and error handling, which are normally pervasive concerns that defeat modularity, from the majority of the system's code. I know this is not the mainstream view, which is mostly about manycore performance.