Ruby is basically a less popular but more elegant Python. It’s a solid general purpose language, but especially good at shell scripting, data munging, etc.
If you’re fluent in Node and Python it should be quite easy to learn. The downside is it’s not going to do anything fundamentally new for you coming from those languages. The upside is mostly aesthetic, Ruby offers and encourages really beautiful ways of expressing code, and it’s neat to experience that.
Having tried to use Ruby for text processing specifically, I'm not sure I agree it beats Python at that particular task. Maybe I'm just used to the Python way of doing things, but I found it difficult to work with the lack of first-class functions and iterators/generators, as well as the general iteration protocol.
> but I found it difficult to work with the lack of first-class functions and iterators/generators, as well as the general iteration protocol.
Ruby has iterators/generators. It doesn't have first-class functions because it doesn't have functions at all, but blocks/procs serve the same purposes.
No, blocks are not first class (procs are, and procs are the closest thing Ruby has to functions, and a method definition can bind convert the block passed to the function to a proc if a first-class value is needed.)
Blocks are a syntactically special single argument to a method that can either be yielded to (a Ruby construct similar to a function call but which only applies to the block passed to the current method) or converted to a proc (but the latter only as part of the method definition, since they aren't first class and thus cannot be manipulated or referred to directly.)
No, in Ruby lambdas are lambdas (and are a special type of proc); the longhand way to create a lambda is to call Kernel#lambda and pass it a block (though modern Ruby has a special shorthand syntax for lambdas, as well.)
Blocks are sort of like anonymous function literals that are not first class, one (but no more than one) of which may be attached to a function call.
I think you may just be used to Python still relying on functions for string processing, where Ruby has methods on the String class for manipulating strings.
It seems to me that Python still has these holdovers from when it was not fully object-oriented, where a lot of string and data structure manipulation is done with language-level functions rather than methods on the objects, which can be quite confusing.
As I said, claiming that ruby doesn't have first-class functions isn't "meaningfully true". Ruby does not have functions, only methods. But that's mostly irrelevant.
> The identifier of a regular "function" in Ruby (which is really a method) cannot be used as a value or passed. It must first be retrieved into a Method or Proc object to be used as first-class data. The syntax for calling such a function object differs from calling regular methods.
> Ruby doesn’t have first-class functions, but it does have closures in the form of blocks, procs and lambdas. Blocks are used for passing blocks of code to methods, and procs and lambda’s allow storing blocks of code in variables.
> but especially good at shell scripting, data munging
Add to this also Shopify, Github, Gitlab, Basecamp and some others and you will see that Ruby can be use for more than shell scripting and data munging. Yes they are Rails but Rails is written in Ruby so they are Ruby.
I think Ruby is much better at shell script like tasks and interactive / exploratory programming for system tasks compared to Python or Node. Use it as “better bash” or
“better Perl” and it’s worth it. I primarily work in a Typescript codebase, but regularly reach for it as a tool to wrangle log data, semi-structured text, or do regex rewrites of a bunch of files.
Ruby is also very fun, probably the most fun language I’ve used regularly. That makes it its own reward.
This is very intriguing, could you please elaborate? I have been looking for a better bash for scripting stuff without all the bash and sh-isms and gotchas.
Some of the most enlightening books I’ve read when I was first learning Ruby were Text Processing in Ruby, and Building Awesome Command Line Apps in Ruby 2. They each reveal certain features and perspectives that work towards this end, such as text parsing moves, Ruby flags to help you build shell 1-liners you can pipe against, and features with stdio beyond just printing to stdout.
Then add in something like Pry or Irb, where you are able to build castles in your sandbox.
Most of my data exploration happens in Pry.
A final book I’ll toss out is Data Science at the Command Line, in particular the first 40 or so pages. They highlight the amount of tooling that exists that’s just python shell scripts posing as bins. (Ruby of course has every bit of the same potential.) I had always been aware of this, but I found the way it was presented to be very inspirational, and largely transformed how I work with data.
A good practical example I use regularly is: I have a project set up that keeps connection strings for ten or so SQL Server DBs that I regularly interact with. I have constants defined to expedite connections. The [Sequel library](https://sequel.jeremyevans.net/) is absolutely delightful to use. I have a `bin/console` file that sets up a pry session hooking up the default environment and tools I like to work with. Now it’s very easy to find tables with certain names, schemas, containing certain data, certain sprocs, mass update definitions across our entire system.
```
# Something failed, and not everything loaded as you expected
# explore explore explore…
Just like with work in the shell, you have a really easy time iteratively exploring the problem and building up your answer. The ability to serialize your data you’ve found, and keep your favorite tools in your pocket feels extremely productive. And of course, all of this can be written in ruby 1-liner shell scripts, or more complex shell scripts to pipe in and out of other tools if desired.
The most interesting part IMO is how it's so similar to Python along many categories, but also so different.
Biggest example is how Ruby just loves Blocks. They're all over the place in the std lib, tons of syntax sugar for them, and countless DSLs built around them. All the standard functional stuff is there in the std lib and has been from very early on, so doing functional-style stuff is really smooth and reads well. In Python, you can technically do most of the same stuff, but it all seems a lot more awkward to write and to read (though maybe just my opinion from doing Ruby first). Python has lambdas, but it doesn't seem to like them much for more than trivial things. But instead functions are first-class everywhere.
I worked with ruby, ruby in rails(RoR) more specifically, a bit more than ten years ago(2011-2013). At that time it was already the afterglow of RoR, the framework for web development that had come to life in 2005 and raged between 2007 and 2009. The latest-technology-addicted crowd was jumping into the boat of node.js, that was crazy fast compared to anything done RoR, and API oriented development with angularjs. In 2013 RoR already showed its age as the standard ways of doing things with it was still the monolithic way and the framework was not transitioning very well to the new paradigm of frontend/backend development.
This introduction about a framework built with ruby and not ruby itself was necessary because even today, I would guess that 95% of all development with ruby is RoR applications. It's my understanding that ruby rose to prominence mostly because of ruby on rails, now that RoR is in a downward trend I think ruby will follow the same trend until it's reduced to a small community of enthusiasts in the same way that happened to perl.
As for the language itself I can't think of a single reason to opt for ruby over python or typescript. Ruby doesn't do anything better both in terms of language or platform than its already better established competitors.
Even Python's choice of naming and syntax to use these basic functions just hasn't been thought through as much as Ruby's implementation. There's a reason it's called the language of Developer happiness.
Ruby's community I've found is more focused on best engineering practices (like testing) than others, which is perhaps why RSpec and MiniTest are fantastic frameworks. The likes of PyTest doesn't even compare to what those two offer.
Plenty of reason above to use Ruby, and we haven't even got to Rails yet.
Kitchen sink isn't the best design imho. I see many of the additions are regexp functions. While I do use them it's rare because they quickly become unreadable. Agree with the python design to decouple and discourage them by requiring an import.
With the recent additions of the prefix/suffix methods I have no desire for any more.
Ruby and Ruby on Rails are not in a downward trend. There were maybe some year where the interest was decreased but in the last 2 years a lot of things happened: Ruby has a lot new features, Rails 7 is out and comes with a new approach to web apps like for example Horwire with the just released Turbo 8.
And there is a lot more: new conferences, new books and new gems.
(Shameless plug: I curate a newsletter called Short Ruby that covers news from Ruby world every week).
Maybe Ruby is not at the level where is was in 2007-2009 but it is also NOT in a downward trend.
This is only an article, but you will find the same point of view in many other places. The decline of ruby and RoR is obvious for anyone doing web development. Python is only getting stronger, Typescript the same, not to mention the statically typed competitors like Java with Spring Boot.
I wouldn't doubt that even languages like Go and Rust might surpass ruby soon in web development because as general purpose languages they are already more relevant.
I'm a former RoR developer and I took off the keywords ruby and ruby on rails from my curriculum because for me professionally it makes no sense to invest time in them.
There are some points from that article that are false: there are podcasts, there are collection of good Ruby gems, and analysis the unicorn companies that were started with Ruby (or Rails) is a biased analysis.
So, if you decide to switch, it is only logical for you to believe that the Ruby community does not bring anything new to the table. I am not saying it as a bad thing. I decided to stay with Ruby, so of course, I am looking for clues that my decision is still reasonable.
One point about your last phrase: the market for Ruby developers - especially seniors - is active. At least in my own corner of the internet.
Google trends says there's a decline. Admittedly this is interest from the general public, not the feature set or the active developer community, but still, it reflects something.
I admit that Google Trends shows a decline from 2004-2007 era.
It could be my optimism, or it could be that I am biased, but I have seen at least a flat line since 2022 in that graph.
As I said, I see an increase when I look at the number of conferences, books, or gems started. That is a strong signal for me that the community is growing, or at least the community thinks it is growing.
Ruby got nothing else bigger than Rails unfortunately no matter how people in that community is hyping Ruby out.
It's okay if Ruby and Rails on a downward trend it might pick up again in the future.
C'mon now, we all know that our industry is like a Fashion industry.
The only reason why Rails is making a comeback is because we're in tough time: no more VC money to hire tons of Engineers to build a web-app.
When money was flowing, folks tend to build over-engineered solution (microservice, mesos, container, k8s, cloud-y orchestration), when money is tight, folks tend to build simple stuff because of lack of resources.
But now there is another complication to an eventual reemergence of ruby on rails: the competition defeated the initial comparative advantage - i.e. the simplicity - of the RoR platform. The premises that justified RoR in the past are too weak today in my opinion. The framework was sold on how easy and no-nosense it was setting it up and start prototyping your commercial solution in a time where the competitors were awkward and epitomized by J2EE, where setting up and developing the most basic application was time consuming and complicated.
Today with Spring Boot, for instance, you can bootstrap and develop your app as quickly and easily as any other cool and alternative framework but with the advantage of using a really popular and fast language.
Technologies don't die quickly and COBOL and Perl are the living proof, but it's really hard to see a bright future for RoR and ruby and I think that most of their contribution was already given.
Spring Boot has been there for ages. It changes nothing really.
Spring Boot was created solely for spinning up Microservice quickly. This is a different segment than Rails.
Spring Boot was overtaken by Golang in the microservice arena in US hi-tech scene. There's just way too may Go-based infrastructure that boosted Go ascend to the Microservice arena from 2016/2017-today. My experience might be just anecdotes but I worked for multiple companies that used to be Java based shop and they all moved away from Java/Scala to Golang and build tons of microservices (whether that strategy is the right thing to pursue or not is a different discussion altogether).
Yeah, Spring Boot might eventually decided to "tack" on the UI option (thymeleaf) but it's too late. Hi-tech already jumped to the latest fashion: Go, docker, k8s, with some sprinkle of ELK and Prometheus for monitoring.
> It's really hard to see a bright future for RoR and ruby and I think that most of their contribution was already given.
They're going to sit nicely in the corner where they belong: web-app. Nothing more, nothing less.
I'd argue the one trending down is Spring, especially after they joined VMWare and now VMWare is part of Broadcom.
Take this with a lot of grain of salt from someone who was a staunch defender of Java during the Spring (DI, MVC), DropWizards, Hibernate=>JPA2 era, skipping Ruby/Rails hype. I moved on from Java to Golang in 2018-2019 and haven't looked back despite switching multiple companies. Prior to that, I was swimming in Java world with multiple companies.
Now that I'm back in the market for my own webapp (side project, fun), I'm not going to use Golang for good reason and I'm not planning to go back to the Spring world either. Rails it is for me...
> Today with Spring Boot, for instance, you can bootstrap and develop your app as quickly and easily as any other cool and alternative framework but with the advantage of using a really popular and fast language.
Looking at the Spring Boot guides, the amount of setup, complexity and lines of code just to get an application running with MySQL doesn't support this statement: https://spring.io/guides/gs/accessing-data-mysql/
Even 20 years ago this would be easier in Rails.
Or try building the blog demo that's build on the Rails homepage video in Spring Boot.
35 minutes to build a blog with rich text (including image uploads), live comments, notification mails and tests. And after changing the database to PostgreSQL, deploy it to production.
https://rubyonrails.org/
If you're productive in Node or Python, then learning Ruby would just be educational in that it's something else to use. Personally, I've found Ruby to be a great language in which I can be productive quickly, which is why I stick with it, but I've written Ruby code off and on for the last 15 years in various forms of production code. I think it's great to learn, but I wouldn't switch to it (or anything) if you're already productive elsewhere.
I’d genuinely love to hear more about what you find difficult about Ruby coming from a heavier Python or NodeJS background.
For me, coming from more of a Ruby background, I found Python and Node to not be too hard to understand, and my only nitpick would be on how eggs/packages were managed and dealing with dependancies.
In particular, Python dependancies compared to Ruby dependancies were more challenging initially for me. I’ve grown to appreciate Python indents and find it nice to read, but that was also annoying at first.
I’m primarily a Ruby dev, but still find most languages easier to work with.
Ruby itself is not the issue. The way people and frameworks (looking at you Rails) abuse its mechanics in pursuit of “clean code” drives me crazy. An incredible number of things are downright challenging to debug because of the insane flexibility of Ruby.
Not op but compared with Python it's heavier in the syntax department. You would have an easier time going in the other direction and encounter less situations where you have to stop and think about what to use in which situation while learning.
The biggest problem with NodeJS ecosystem is the type of crowd that gets excited over NodeJS: JS developers, some web folks.
NodeJS does not attract the kind of people who build ElasticSearch, Kafka, Hadoop, Spring Framework, etc so the quality of the libraries reflected of that the Web Developers crowd: the short-term Do-ers (need it today, let's build it, and let's move on to the next interesting stuff).
If you’re fluent in Node and Python it should be quite easy to learn. The downside is it’s not going to do anything fundamentally new for you coming from those languages. The upside is mostly aesthetic, Ruby offers and encourages really beautiful ways of expressing code, and it’s neat to experience that.