I've previously worked on mainframes (building business software, and worked quite low level with crypto libraries on them), and now do some of the same but for "cloud" based software instead.
Mainframes are such a weird subject to me, on one hand, the results we got out of the mainframes were pretty amazing, but the experience was painful, absolutely, painful. The tooling is some of the worst you've ever seen, official tools feel like something people dreamed up in winforms. I worked mostly with PL/1 which was a great language, stuck in the 80s but great nonetheless, I actually prefer it to C.
What killed it for me was the restrictions, you had to either dynamically or statically link programs, but do it in the IBM flavor and build system. Which made it extremely cumbersome to do, so files were 20k SoC with a single entry (main) and function calls, because creating files was a pain. Line limits of 72 characters, we even had to send in our programs to get syntax checks because the IDEs weren't capable enough (this was in 2018), now I could whip up something to emulate it in docker and neovim, but the people that taught me had no idea there was something better out there and neither did I. We had to release once a week on saturday mornings because the execution model used had to have downtime during the deployment.
Mainframes are cursed because of the lack of tooling, and the restrictions. I think Mainframes and the execution mode it uses could be useful in a bunch of other places, but IBMs business model just continuously tightness the screws and scared people away. It doesn't have wide spread appeal either, it is "Business machines" after all.
It should be said that I worked in IBMs version of Serverless (not what it was called but it was pretty much what it was), mainframes support Linux, Java, etc, etc. But you give up a lot of benefits and performance if you move off, of the native way of doing things.
I'd also argue that with todays tooling and hardware you can get comparable performance to a mainframe, the only reason that mainframes are as performant, and was so dominant, is because of the restrictions it places on the developer. You have to write low level C, PL/1 or Cobol, so often by proxy your software is just fast. Kind of like Rust or C++ is nearly always quite performant out of the box. Most business software just don't need that level of latency control and performance today.
The fact that it sorta forces you to a lower level of abstraction is actually a very interesting topic and something I think about a lot in the context of how mainframes have remained relevant.
If there were a way to restrict non-mainframe ecosystems in a similar way, I think it could provide a lot of value. Especially for large organizations where standardization and prevention of IT churn is a serious problem.
I just don't see how you do that in an open platform, and so I don't really think it's viable outside of the mainframe space (although it certainly explains part of why a lot of orgs still choose mainframes despite knowing all of inherent difficulties the platform presents). It's a people problem not a technical one at the end of the day.
I'll add that a lot of the tooling deficit has been resolved in the mainframe space, but often in a way I'm not comfortable with. It's normal these days for mainframe developers to not use the old school ISPF development environments, but the thing about the awful old tooling, is that it was brutally efficient. Now you are likely to be giving up a significant amount of that efficiency because you've replaced it with a bunch of JVMs running web services.
There is in some sense an unavoidable tradeoff between modern conveniences and efficiency that I don't think there are any easy ways to get around. We can't have our cake and eat it too, and you cannot have mainframe level performance without it just being a bunch of COBOL and C.
This applies just as much to Linux servers as it does mainframes. I'm not really even commenting about the architecture. There are similar tradeoffs involved in how we choose Linux distributions, although perhaps a little less extreme.
Mainframes are such a weird subject to me, on one hand, the results we got out of the mainframes were pretty amazing, but the experience was painful, absolutely, painful. The tooling is some of the worst you've ever seen, official tools feel like something people dreamed up in winforms. I worked mostly with PL/1 which was a great language, stuck in the 80s but great nonetheless, I actually prefer it to C.
What killed it for me was the restrictions, you had to either dynamically or statically link programs, but do it in the IBM flavor and build system. Which made it extremely cumbersome to do, so files were 20k SoC with a single entry (main) and function calls, because creating files was a pain. Line limits of 72 characters, we even had to send in our programs to get syntax checks because the IDEs weren't capable enough (this was in 2018), now I could whip up something to emulate it in docker and neovim, but the people that taught me had no idea there was something better out there and neither did I. We had to release once a week on saturday mornings because the execution model used had to have downtime during the deployment.
Mainframes are cursed because of the lack of tooling, and the restrictions. I think Mainframes and the execution mode it uses could be useful in a bunch of other places, but IBMs business model just continuously tightness the screws and scared people away. It doesn't have wide spread appeal either, it is "Business machines" after all.
It should be said that I worked in IBMs version of Serverless (not what it was called but it was pretty much what it was), mainframes support Linux, Java, etc, etc. But you give up a lot of benefits and performance if you move off, of the native way of doing things.
I'd also argue that with todays tooling and hardware you can get comparable performance to a mainframe, the only reason that mainframes are as performant, and was so dominant, is because of the restrictions it places on the developer. You have to write low level C, PL/1 or Cobol, so often by proxy your software is just fast. Kind of like Rust or C++ is nearly always quite performant out of the box. Most business software just don't need that level of latency control and performance today.