Hi Mika. I still use Java for a number of reasons - not just because I wrote Sun Microsystems's enterprise Java book and the first Java magazine column and built a company around our Java expertise LOL. But because:
1. The Java ecosystem is so incredibly rich, the language is full-featured, and the features all work. E.g.., there is no "global interpreter lock" to keep threads from working.
2. The Java community puts a high value on backward compatibility - in contrast to many others, so one's stuff does not break every time a new Java version comes out.
3. Java is high productivity. It is not the highest by any means, but it is good.
4. Java is highly maintainable: it is relatively easy to reverse engineer someone else's code.
5. It is reasonably fast.
I dabbled in Scala but it is sophisticated and I did not have time to learn it properly.
I spent a year working in Go, and enjoyed it, but was very disappointed with the language in many respects. I think it is a poor choice for an organization.
I am very interesed in Rust. It solves a problem that I have been writing about for years - have mentioned in at least two books: the alias problem. That problem is also sovled by ArchJava (in a better way, IMO), which is a fantastic language, but it not widely used.
I am not a fan of functional programming languages. I feel that threy solve the alias problem in a clumsy and bizarre way.
I was on the team that designed the VHDL language, and I wrote the first VHDL hardware synthesis compiler. I am a big fan of data flow languages, but there are none that are mainstream. That is a shame, because I feel that paradigm is the very best one of all.
VHDL was designed for defining hardware systems, which are - inherently - concurrent. But VHDL actually can be used for a wide array of things.
A language I still use from time to time is C. Not long ago I had to write a ~300 line utility program. I started in Ruby but then decided to write it in C. It took me about an hour, even though I had not written a C program in more than ten years. The program worked the first time. That is only the second time that has happened in my career. It was completely correct from the first execution. And it only took me an hour to write.
The most productive I have every been, by the way, was programming in C on a Sun workstation in the late 80s. On one occasion I wrote ~1000 lines of tested code in one day. So I am not impressed by today's claims of high-productivity languages. My code was very maintainable, fast, small, and I was really productive.
One thing that has really damaged the ecosystem is the programming community's preference for dynamic binding - particularly via reflection. Dynamic binding has bloated everything. A C program linker can determine which functions are not used and strip them out. That is why the Unix "make" program is on ~30K, yet it has a massive amount of functionality. A similar program written in a "modern" language would be many Mb, if not Gb. That is because "modern" languages support dynamic binding, and so the executable needs to include every references library in its entirely; and each library might reference other libraries, which reference others. As a result, it is really hard to create, say, a non-trivial Java program that is less than 500Mb. But if you use, say, GrallVM, you can get that down to a tenth the size or better, but only because GraalVM requires you to not use reflection; or if you do, you must declare which methods you actually call.
Recently I have defined a new data flow language called "Flow", and have been working on a compiler for it in my spare time. Not only is it data flow oriented, but it includes features that are valuable for machine learning (e.g., the ability to define a runtime computational graph). Here is a link: https://gitlab.com/cliffbdf/flow-poc
