About languages and tools: the walking dead and other legends

2025-05-08T13:00:00Z

I'm writing this post to react to one of the many articles and threads about the presumed death of this or that programming language, library, framework, or tool. What that article was about and who wrote it is secondary. I could synthesize my idea by citing a well-known joke by Mark Twain: "The rumors about my death are greatly exaggerated."

Let me use a synecdoche rhetorical expedient and limit what follows to programming languages. Of course, this post is not absolutely limited to them; it could be applied with little effort to libraries, tools, frameworks, content management systems, and many other tools of common use among developers.

Any developer who has been around enough knows that the death hoaxes about the end of a programming language are a common refrain that returns almost every year for most of them. The nude truth about programming languages is that developers follow trends and fashions. Job recruitments influence such trends, as well as some application categories and technologies that appear from time to time. Without any specific preference, there are currently tons of languages that still have significant (or even not so large, but still sustainable) communities that passed in the rearguard because their trendy momentum has been in the past. A lot of people mistake the end of convulse development periods (or, even worse, the absence of headlines on major tech news sites) for death. I could cite many such products that were considered dead a long time ago and still see one or more releases per year. From stability to death, it is often a matter of points of view.

I would not refer to Fortran, Cobol, Ada, Prolog, Lisp, etc., which have been around for 60-70 years. For me, all those are clearly niche languages that still have their own use in specific domains, and that has been true at least in the last 40 or 50 years. In most cases, they are not simply updated for features or even able to manage common applications or programming patterns of the modern era.

Who would try to write a web framework in Fortran or Cobol? Oh well, you probably don't know Fortran.io, an MVC web framework written in Fortran90. Or even any of the full-stack web frameworks written in Cobol. So, it is better to say that for such languages, some applications are purely intellectual challenges, drafts, and sketches that no one would seriously(?) consider in production environments. That does not imply that such products are at a dead end, but only that they are not considered for those applications (but could be for other ones).

But for them, there are even more recent languages that gained the stage about 20-30 years ago or less, such as Java, Perl, Ruby, or PHP, which are still in use in production environments but in declining popularity. A special case is C/C++ and its variants, which most consider low-level languages at a dead-end but are actively used in many application domains. Today, Rust is considered by general rumors to be their natural replacement, but again, there is no evidence that it will truly be so in the future. Often, in the past, what appeared to be an ineluctable success in a certain period revealed a pure illusion to be replaced by the next language of dreams.

So what? A dose of sane realism is genuinely required. Developers are voluble and suffer from early love like teenagers. What today seems like the way to go could only reveal a dazzle a few years (or even months) later. Being a bit conservative could help, but the whole silver bullet idea for tooling is auto-lesionism. There is not one ring to rule them all. Simply, there is not a single language to win in all fields, and the skill of being able to switch comfortably among multiple ones (possibly finding the most helpful for a specific goal or application domain) is the true superpower of a developer. That's specifically true if such languages expose different programming patterns and abstractions. All the rest is for gossip and opinions. Sometimes, a specific package or framework declares the convenience of using the language (do you remember the whole Ruby-on-Rails momentum?), as well as the existence of a very specific language feature (e.g., Erlang efficiency in concurrency). That is the true basis of a reasoned choice for an implementation.

That said, the only concrete problem nowadays is the job market. A learning plan that includes only good-but-old, as well as for the opposite, only too recent tools, could be equally wrong. The job opportunities could be equally few for both. It seems that the most convenient language is one with a vast community, but unfortunately, that could be a transient status: at the very beginning of the third millennium, it seemed that Perl was the language of choice for web applications, which became clearly not the case just a few years later. So what? Well, a grain of salt is due in any case, but what seems like the current primary choice could become a language of the past in just a few years.

A complete developer should at least know at a non-trivial level a system programming language (e.g., C/C++, or Rust), as well as Python, JavaScript, and possibly also a pure functional one (e.g, Scheme, Clojure, or Haskell). Of course, moving from a non-trivial level to the guru level is a matter of time and experience, and it could also never happen in practice for each of them. The more languages and programming paradigms you dominate, the better for you.

What will be the next dead language in the near future that still seems to be the current Big Thing? I have some suspicions, but I keep them to myself.

A silly benchmarking of some programming languages

2024-09-09T19:00:00Z

I lately wrote some silly benchmarking code inspired by a brief article of Halim Shams, just to perform some quite dumb performance tests with multiple languages. The whole set of test code snippets is available here and includes C, Rust, Guile, Java, Perl, Tcl, Python, R, Octave, and Ruby programming languages, as available on Debian 12 (bookworm) distribution.

The home workstation used for the trials is not too recent, so slightly better results could be obtained (and expected). Of course, that code is just a long do-nothing loop, which is not for sure the most helpful type of code, but anyway, some interesting considerations can be made on the results.

The resulting running times are the following ones:

Lang: user time
---------------
C: 0m0,001s
Java: 0m0,038s
Guile: 0m2,644s
Rust: 0m4,639s
R: 0m14,065s
Ruby: 0m21,022s
Perl: 0m31,190s
Octave: 1m38,300s
Python: 1m39,374s
Python-range: 0m45,752s
Tcl: 13m54,620s

First of all, it appears evident that one does not need any particularly refined benchmarking code to get general trends on programming language performances, which are perfectly aligned with known performance tests, as obtained by well-stated benchmarking code. So, C and Java snippets are the clear winners, while Guile and Rust have both very respectful performances (see the Update section). Note that while C is built in an ELF binary, Java is running a VM, and its resulting performance reveals that the JVM is highly optimized. Not bad at all, guys. One aspect which is not evident at all is the requirement of using full-optimization for the C compiler; otherwise, the running time would be not too far from that of Guile. Even, note that both Guile and Python use a JIT implementation.

Other languages results reveal some expected slowness, but some of them could be a surprise for someone. The terrible result of the old glory Tcl, for instance, is only overtaken by the disappointing performance of Python 3.11 (but 3.12 is even a bit slower). Note that it strictly could depend on constructs used in the code snippet, as the alternative use of range() for Python reveals.

Some conclusions about this silly benchmarking experiment for dummies could be:

Never take the performance of (your) code for granted.
Interpreted languages can be performance hogs, but it is not necessarily so, and the reason could be looking at you in front of the mirror in your bathroom.
Some languages can be better than others for performances, but it is rarely an easy take.
Never, never, never think that the constructs in a language you are using are the best ones for that language. Maybe they only could be more readable for you.
The one-language-fits-all is a belief for fools only.
Some old glories (Scheme Guile docet) can reveal unexpected speeds, but that's not necessarily true for any of them (Tcl docet).

Update

Jean Simard pointed out after publication the missing optimization for the Rust code generation, which is similar to the C one, and indeed, that works for Rust too, so that performances of C, Java, and Rust become quite comparable. In the meantime, I added Go and a couple of other Scheme implementations to the list of benchmarked languages. Not bad at all, so the resulting times are now the following ones:

C: 0m0,001s
Rust: 0m0,000s
Java: 0m0,046s
Go: 0m0,607s
Chez Scheme: 0m2,203s
Guile: 0m2,643s
Racket: 0m6,278s
R: 0m17,463s
Ruby: 0m20,803s
Perl: 0m36,111s
Octave: 1m40,700s
Python: 1m50,594s
Python-range: 0m45,106s
Tcl: 13m56,178s

A final observation. As others have noticed, the optimized versions of C, Rust, and Java are too good to be true. Indeed, I checked the assembly translation of the C binary and found that nop-loops are simply detected at compile time and cut away. I'm quite sure the same is true for the JVM translation, and maybe Go. Again, the devil is in the details...

frankie-tales

About languages and tools: the walking dead and other legends

A silly benchmarking of some programming languages

Update