frankie-tales

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.

Sharing configurations and data among multiple boxes

2025-05-04T23:00:00Z

Following a post detailing my email setup across multiple personal boxes, I'll summarize an outline of my approach for managing data across multiple workstations and individual profiles in this post. This system (or collection of tools and workflow) has evolved over time and continues to adapt to various needs and scenarios, offering high flexibility and control for my use cases.

First of all, it is mandatory to use git to manage multiple configurations with branches for almost every box or family of boxes (e.g., home vs. work, personal vs. shared). Some people tend to use git for the whole home, but in my honest opinion, it is inappropriate for performance reasons, even if Joeyh's git-annex and LFS mode are helpful in those regards. In many cases, it is not required to version all data files, and even if this time-machine-like solution is considered the ideal one for user's homes, it could negatively impact storage requirements and long-term performances. Also, having a mono-repo for all your own stuff could be challenging. In my case, I deal with multiple private and public Git repositories, including GitHub, Gitlab, and others all around, and maintaining a single repo is not a good idea for me.

The good news is that it is generally possible to limit the use of git to a subset of the whole home, specifically the dotfiles used to configure common tools and programs, a helpful set of scripts for personal use, and a few other sparse things. In many cases, some useful scripts to synchronize and update everything is more than enough. Part of my automation workflow is based on Ansible rules, so the whole thing is easily integrated into such management.

It's important to note that I strongly advise against using git for sensitive information, such as credentials and keys. Even with a personal git server, copying such information via directly attached media storage is safer, ensuring they are not exposed on a permanently internet-connected repository. For such cases, specific solutions like Vault/OpenBao could provide an extra layer of security for workgroups, giving you peace of mind and confidence in the system's security measures. That said, the whole topic of the management of passwords, credentials, and other private information would require another post for completeness because it is not straightforward when privacy and security need to be fully conjugated with long-term goals.

Dot files and other stuff maintenance

That said, I currently use at least a couple of different git repositories, one for my dotfiles and one for helpful scripts for personal productivity. These repositories are branched, at least in home/office flavors, and based on multiple languages, including shell, Perl, Python, awk, and others.

I found it helpful to clone such repositories immediately, install them via the GNU stow utility, and install pure symlinks under my $HOME and personal binaries directories. However, for some specific cases (notably the Vim stuff), I prefer maintaining a separate git repository that I update separately: this is partially for historical reasons, but even because, in some cases, the whole stuff is a fork of other repositories.

In the past, I adopted a bare repository for dotfiles and a custom git call to maintain all dotfiles directly in place instead of symlinking them, which is a slightly different approach. Something like the following snippet of shell code:

    $ echo 'alias dotfiles="/usr/bin/git \
         --git-dir=$HOME/.dotfiles.git/ \
         --work-tree=$HOME"' >> $HOME/.bashrc
    $ source $HOME/.bashrc
    $ echo ".dotfiles.git" >> .gitignore
    $ git clone --bare <my_git_host>:/opt/git/dotfiles.git \
            $HOME/.dotfiles.git
    #
    # clean up current dotfiles (with directories) 
    # available in the common repository and backup
    #
    $ mkdir -p .dotfiles-backup && \
    	  dotfiles checkout 2>&1 | egrep "\s+\." | awk {'print $1'} | \
    	  xargs -I{} dirname {} | sort | uniq | xargs -I{} mkdir --parents \
          .dotfiles-backup/{} && dotfiles checkout 2>&1 | \
          egrep "\s+\." | awk {'print $1'} |  \
  		  xargs -I{} mv {} .dotfiles-backup/{}
    $ dotfiles checkout
    $ dotfiles config --local status.showUntrackedFiles no

can be used with a proper alias to maintain all registered dotfiles in each box's HOME. Of course, the previous stow-based approach is much more immediate.

Gnome configuration

My dotfiles repository does not include the main desktop configuration, specifically my Gnome settings, including the few extensions I use. Not all my personal boxes include a desktop, but it is much more immediate to maintain a single dump of a finalized configuration based on the main Gnome version in use instead of branching and following its internals properly (which can largely change from one version to another).

    $ dconf dump / >gnome-settings.dump 	# on the source workstation
    $ tar czvf gnome-shell.tgz .local/share/gnome-shell

    $ dconf load / <gnome-settings.dump 	# on the target workstation
    $ tar xvf gnome-shell.tgz

Data syncing and backups

While code and configurations are better managed via git, I also deal with many generic data files (up to dozens of GBs per file or more) and documents that I synchronize automatically or on demand. Two tools I use intensively — syncthing and unison — can cover both goals. They require at least one master copy to be reachable, and having one master host per site is the best idea.

Finally, my primary backup tool for years has been the venerable borg tool, which allows planning incremental backups and rotation plans of master hosts. At least one encrypted backup is stored on an external cloud for convenience. This is an aspect where I'm still looking for a definitive solution far from the usual big companies for personal stuff (a fight lost at work, unfortunately), specifically for what is attaining the mobile ecosystem and family. That's because, but for strictly FOSS requirements, I'm also interested only in a self-hosted, long-term, and stable solution that I could directly maintain for a lifetime. Currently, I'm simply using rclone to sync third-party cloud storage when required. Of course, the 3-2-1 rule for backup is fully respected, thanks to the use of multiple sites and devices, even without using cloud providers, but I would prefer taking in the loop additional encrypted copies of some stuff (mainly videos and photos) even for sharing with others.

My geeky email setup explained to humans

2025-02-16T11:00:00Z

Being an ancient mariner in the virtual ocean of the Big Network, I started using emails at the very beginning of the Internet era (at least here in Italy) on a SunOS pizza box, which I used at the time as my primary workstation. That was a giant step ahead for me because my first serious use of email in 1991 was on a Digital VT220 terminal under VMS OS and its MAIL client (who remembers the old times of DCL?). At that time, I started using Elm as my Mail User Agent, a software that stopped being developed in the first few years of this millennium.

In 1995, a new attractive MUA started to be developed, and it fascinated my geek inclination: as any smart enough reader can well imagine, it was Mutt, and as anyone knows, it still sucks less as a MUA, and it is nonetheless being developed after almost thirty years. Nowadays, colleagues and friends are always perplexed when they see me still reading and answering emails on a terminal in text mode, but I never found serious motivation to change my email workflow and prefer a graphical MUA instead. I occasionally use a smartphone with K-Mail (now Thunderbird), but I like reading and writing emails on one of my GNU/Linux PCs.

First of all, my mailboxes are read by or received in a single box (let's call it the Collector, with appropriate local backup), permanently connected to the network. It also provides SMTP/IMAP services and a last-resort spam filtering capability, thanks to Spamassassin+Razor and Procmail rules. Mailboxes are provided by third-party services, including (but not exclusively) a series of GMail and MS accounts, and that box is able to communicate with each of them to regularly read new messages, thanks to Fetchmail. Any of my PCs can then connect with the Collector to read remotely archived emails via IMAP and send answers and new messages through any of the legitimate SMTP servers associated with each email account I use: that is because of the SPF/DKIM specs used for all email boxes nowadays.

The Collector archives and rotates multiple mailboxes monthly and yearly, including the main one, where all urgencies are automatically routed when they arrive. I use multiple email accounts for mailing list subscriptions, so many messages are automatically routed off the main track on purpose. For ages, many bad MUAs out there only send HTML emails, so I occasionally use some graphical helper to browse some of them. The result is a long period archive of emails over the last 30 years that I occasionally purge of the mailing list messages to reduce the storage load. Eventually, I use Notmuch to dive into tons of Maildir mailboxes accumulated on the Collector, and that is more than enough because an ancient message is rarely required in my experience.

Thirty years of using Fetchmail, Procmail, Dovecot, Exim, and Mutt seem more than enough to explore new ways of managing emails, but my laziness prevents me from keeping an eye on my second choice, which would be Emacs with mu4e and offlineimap or sync to read emails in disconnected mode when required. Note that Mutt has caching capability, so the initial load of the mailboxes is a fast enough experience.

Finally, I found it helpful in my setup to use other interesting tools, such as lbdb, to collect senders' addresses automatically and have them at my fingertips. Recently, the Collector and all clients started using Simon Robinson's nice email-oauth2-proxy as an intermediate service to access 2FA-enabled email accounts, a reasonable complication of the original setup.

That said, any sane geek should rigorously use a personal domain and email account to avoid being locked in the use of a third-party domain and storage limitations: there is nothing worse than having to change tons of personal contact emails registered in dozens of services because of the dropping of someone else domain (or even worse, being exposed to their changes in policies, features, and limitations). That has been my way in the last 30 years or so. For the same reason, using any webmail system to manage emails is neither practical nor scalable.

Yes, I know, I'm a damn old fashioned geek, but this is the Way.