COBOL is not dead, but it's difficult to get access to, because there is almost no open-source tooling around it for Linux. We (OCamlPro) have created a project, called SuperBOL, to create an open-source environment around the GnuCOBOL open-source compiler (that is now very mature and used by companies). We have already released the VScode extension with an LSP for COBOL to get a modern IDE, and we are working on other tools, mostly depending on our customers.
The problem is not so much access to tooling, but access to mainframes. I can learn COBOL in a day or two, and I would love to work on a "boring" COBOL job, but I have no experience with mainframes.
The goal of SuperBOL (https://superbol.eu) is to allow companies to migrate from mainframes to Linux workstations, to get a "modern" experience of development and deployment.
Indeed, mainframes are hard to get access to, and require a training by themselves, I have worked on Linux and Windows for years, and development on a Mainframe has nothing in common :-)
I think the problem of COBOL is not only the lack of COBOL developers, it is the lack of expertise in COBOL environments, because they have become obsolete (both on mainframe and proprietary tooling for Linux/Windows). By providing a modern environment on Linux for COBOL, our goal is to solve the hardest part of the problem, as learning COBOL itself is not so hard for existing open-source developers...
Is there anything particularly different about mainframes compared to working on a server besides it probably being a different operating system? I assume it has a command line and you ssh into it somehow (or something similar)? Or are they still running punch cards or something?
It's a very different (and foreign) environment. Job control language, how data is stored... if you come from a typical modern server environment you'd be pretty lost in the mainframe world.
In 1996 I took a TCP class in Chicago for which it turned out I was overqualified; it was mainly how to use tools like telnet and FTP.
But what I remember most: the two other students were mainframe programmers, and they were just as baffled by my world as I was by theirs. It really was an entirely different computing paradigm, although 30 years later I probably have enough experience to make more connections than I could then.
You can find videos on Youtube, it's like an IDE where you would do everything in a user interface with menus, but the interface is a 25x80-char screen only :-) Everything is "almost" similar to a Unix system, but with different names, files are called "datasets", there are very few tools, but every one of them has a language to do very complex tasks...
I know two people that spend some of their time writing COBOL for a major bank. They do find that part of the job pretty boring, it is basically just writing down SQL queries in a COBOL file and then trying to get passed their 50 year old development workflow (merge to master, then do testing in a testing environment, then get code review..).
We are among the major contributors to GnuCOBOL, we use https://github.com/OCamlPro/gnucobol to review our contributions before pushing them on the SVN of Sourceforge.
Cobolworx is indeed working on a gcc frontend for COBOL. It's an impressive work (that was presented at FOSDEM this year), but less mature than GnuCOBOL, and tied to gcc, whereas GnuCOBOL can work with any C compiler (llvm, msvc, etc.) by translating COBOL to C.
Though we desig SuperBOL to work with GnuCOBOL, it could also be used with GCOBOL when it will be officially stable.
We recently worked on a project to build a binary installer for OCaml, inspired from RustUp for Rust. We had to build binary packages of the distribution for every OCaml version since 4.02.0, and we were surprised to discover that their (compressed) size grew from 18 MB to about 200 MB. This post gives a survey of our findings...
You are comparing different things. OCaml strength is safety, it verifies at compile time that your program is safe, correct apart algorithmic errors. Once it compiles, you are almost sure it is going to work. Go does not give any such guarantee.
And among "safe" languages, OCaml is probably the most efficient, generating fast code running with a small memory footprint.
Moreover, although its development was a little slow in the last years, they have recently restarted working on it, on optimizations and soon multicore support, so I would wait a little before making more comparisons.
