jmtd → log → Backing the wrong horse?
I started using the Ruby programming in around 2003 or 2004, but stopped at some point later, perhaps around 2008. At the time I was frustrated with the approach the Ruby community took for managing packages of Ruby software: Ruby Gems. They interact really badly with distribution packaging and made the jobs of organisations like Debian more difficult. This was around the time that Ruby on Rails was making a big splash for web application development (I think version 2.0 had just come out). I did fork out for the predominant Ruby on Rails book to try it out. Unfortunately the software was evolving so quickly that the very first examples in the book no longer worked with the latest versions of Rails. I wasn't doing a lot of web development that at the time anyway, so I put the book, Rails and Ruby itself on the shelf and moved on to looking at the Python programming language instead.
Since then I've written lots of Python, both professionally and personally. Whenever it looked like a job was best solved with scripting, I'd pick up Python. I hadn't stopped to reflect on the experience much at all, beyond being glad I wasn't writing Perl any more (the first language I had any real traction with, 20 years ago).
I'm still writing Python on most work days, and there are bits of it that I do really like, but there are also aspects I really don't. Some of the stuff I work on needs to work in both Python 2 and 3, and that can be painful. The whole 2-versus-3 situation is awkward: I'd much rather just focus on 3, but Python 3 didn't ship in (at least) RHEL 7, although it looks like it will in 8.
Recently I dusted off some 12-year old Ruby code and had a pleasant experience interacting with Ruby again. It made me wonder, had I perhaps backed the wrong horse? In some respects, clearly not: being proficient with Python was immediately helpful when I started my current job (and may have had a hand in getting me hired). But in other respects, I wonder how much time I've wasted wrestling with e.g. Python's verbose, rigid regular expression library when Ruby has nice language-native regular expression operators (taken straight from Perl), or the really awkward support for Unicode in Python 2 (this reminds me of Perl for all the wrong reasons)
Next time I have a computing problem to solve where it looks like a script is the right approach, I'm going to give Ruby another try. Assuming I don't go for Haskell instead, of course. Or, perhaps I should try something completely different? One piece of advice that resonated with me from the excellent book The Pragmatic Programmer was "Learn a new (programming) language every year". It was only recently that I reflected that I haven't learned a completely new language for a very long time. I tried Go in 2013 but my attempt petered out. Should I pick that back up? It has a lot of traction in the stuff I do in my day job (Kubernetes, Docker, Openshift, etc.). "Rust" looks interesting, but a bit impenetrable at first glance. Idris? Lua? Something else?
Comments
I don't think you've backed the wrong horse - Ruby and Python seemed to have remained constant over the past few years (IME, Ruby has lost ground in web development but gained some ground via Puppet and Chef).
Go will be around for a while, if for no other reason than Google has invested heavily in it. I'm not sure the current fad for functional languages such as Haskell will last though.
Personally, I'm focusing on PHP (web development), Python (scripting and Ansible) and C (systems). I think all three will be around for the foreseeable future.
I'd say pick the right tool for the job.
I learned PHP about twenty years ago and it served me well back then: it was easy to deploy and we built great things with it. I now hate it with a passion - I realized it corrupted my brain and as its inconsistencies drove me madly rushing to the documentation all the time. But as much as I hate the language now, I still run PHP apps here and there.
After using shell scripting and bash a lot, I've also switched to Python for most things now: it just works and yes, you can target Python3 now - most distros ship it (as you mentioned) so unless you are targeting really old platforms (Debian squeeze maybe??) you will probably have a Python3 interpreter running. And while Python3 has been historically slower than Py2 in benchmarks, the gap is shrinking and it's actually faster on many. It's my default go-to language for most projects.
After getting schooled by Stapelberg when he beat me to the manpages.d.o rewrite with a golang implementation, I gave Golang another try and loved it. It's great to have a language with a spec you can read in a day or so. Static compilation is good for embedded environments and that's why I used it for my first golang project. It's great to have native constructs in the language for parallelism: I wrote another "downloader"-type project in Python after... What a mistake! I couldn't get the new Py3 asyncio stuff going: it was still in flux so some bits (like https + requests) were missing, but even now I find it utterly confusing. In comparison, golang is much more elegant. But static compilation is a weird match for Debian. Security updates require all dependencies to be rebuilt, for example. I would still start with golang for everything but GUI projects or things that need user-writable plugins right now.
But then I'm also forced to write Javascript every once in a while, to talk with browsers and that growing community of (younger?) developers building awesome things in the VMs that are becoming web browsers. I don't like it much - it's like PHP without the docs - but it works and I will use it when relevant.
There's Haskell in my toolbox somewhere: I try and try again to use it because I find it so elegant but it's hard. It eerily reminds me of the "write-only" nature of Perl... There's so much "syntactic sugar" in Haskell that it's hard to understand what's actually going on sometimes. And the ecosystem is limited, compared with Python. But some things I use (git-annex, previously xmonad, pandoc) use it extensively, so I have to understand it.
Considering you're comfortable with Haskell, I think you'd have more facility than me learning Rust, which seems to be pretty popular right now. Thee language has nice promises for lower-level stuff, but I'm not sure I'll ever need that level of performance in my projects to justify the effort. Golang and Python are sufficient for my needs right now.
And I understand the attraction of Ruby: been there, done that. But like you, I found the ecosystem was moving too fast. Maintaining Ruby infrastructure (Redmine, in particular) was especially difficult and having went through many LTS security updates on Ruby stuff makes me feel I was right in staying away from the ecosystem after all.
That was way too long, but I hope it helped!
I find perl's unicode handling really good. I definetely prefer it to what python is doing.
Perl before 5.10 had sharp edges.
@Pete: I suggest reading the debian wiki page I linked to, which explains that yes, they are worse than Python modules or CPAN modules. CPAN modules in particular can be very easily packaged, I think the Perl team automates nearly all of the work. I believe the same is true for Haskell cabal modules. From what I remember (and it's been 10 years since I last looked properly) the issue is that a Gem can execute arbitrary code as part of the install process, meaning it's hard to reason about what a gem will do / needs to be done to install the software, short of running the code.