I think with the slowing progress of single threaded performance modern languages require three essential features if they want to be "main branches" of the language evolutionary tree.
1. easy parallelism
2. easy networking
3. managed memory
1. easy parallelism
2. easy networking
3. managed memory
As such, I don't think we'll literally program computers in 100 years so much as think about problems whilst connected to some sort of cybernetic system. The now obsolete act of programming itself will be abstracted away in the same way a language like Python abstracts way assembler, cache, and memory management today. 50 years ago code was still being submitted with punch cards. In 1971, my father got a 110 baud model 33-ASR teletype that drastically simplified coding and provided paper tape for offline storage. Compare and contrast with today.
In such a system your wetware and the hardware will collaborate in the same way that groups of people brainstorm ideas, resulting in code that just seems to write itself driven by one's thoughts. What AI will have become by then will be more then capable of running such a program through bajillions of chaos monkey simulated scenarios instead of a hand-crafted set of unit tests.
As to what that language actually is, just what kris-s said: easy parallelism, easy networking, and easy access to storage in a way that the HW itself does all the management implicitly and emergently. But I doubt humans will write this code, I think the compiler guys will finally win this by building something like the above, where hand-coding such a widget would be insanely tedious for mostly meager performance gains (unless you're an infinitely patient machine that can go arbitrarily parallel). The current DL ASIC war combined with the framework compiler arms race just beginning now ought to give us an early preview of what's to come.
We still use UNIX/C (1970) and the command-line is still very much a teletype.
That said, I'm also seeing Rust really start to boom and it trades managed memory for very powerful tools for managing it manually.
I agree with the claim in the essay that there will always be a need for full throttle performance, which rules out a GC or ARC.
Those are 1/100th or less of the type of code people write everyday, in startups, enterprise, cloud apps, even regular desktop and mobile apps...
>When I think Java, what comes to my mind is something like LibreOffice.
That's written in C++
But still a tiny slither on what most programmers do. Most programmers (the overwhelming majority) do neither video games nor real time.
> When I think Java, what comes to my mind is something like LibreOffice.
You should probably revise that thinking, since it is not written (at least in substantial ways) in Java. Moreover, desktop applications are probably not really the main use case for it (or any language other than web technologies) these days.
Java running on server processes or any long-lived computation sits in the top tier of performance. Not as fast as C/C++ but in the same ball-park.
Real time requires predictability, something that was solved in GCs by mid-1990s and had workarounds (which are required in C/C++ as well, and widely used by games etc.) by 1980s - when real-time GC'ed programs started to be used. Including hard-realtime in telephone switches.