Cross posted from my blog.
Background
For the last 10 years or so I have been squarely a PHP developer. From version PHP 4 around 2000 up to and including the current version 7 in 2018. From scripting, to OOP, to the modern language ecosystem it is today. This year I wanted to learn a new language, to add a different perspective on problem solving. I tried out Golang for a couple months as the concurrency and channels model is super interesting and it is a very low level language (all of which PHP is not). However, recently I was approached with a project that is currently written in Ruby (on Rails). I have wanted to learn Ruby for awhile so this provided an excellent opportunity to give Ruby/Rails a spin. After a week of spare time tutorials and reading here is my opinion about Ruby after the first 12 hours.
Good
General Community
I've been around the internet a bit. ICQ, AIM, Usenets, direct dial BBSs, Stack Overflow, Dev.to, Regional Conferences, on and on. I have never, in my experience, witnessed a community so open, friendly, and helpful as the Ruby group. If I had to pick a language to learn based on how friendly and curitouse the members are to each other; Ruby would win hands down. Not to say the community is perfect, just the nicest in general.
Language Syntax
You know, I like the short syntax. It is a dot based syntax (like JS for example), paren's are optional, and the data types ad nearly self defining.
[0 => 'value'] #array
{'key' => 'value'} #hash
1+2=3 # int + int = int
1.2 + 2.3 = 3.3 # dec + dec = dec
self.validate data #object.method parameter_date
The optional paren's was confusing at first, but quickly mentally internalized.
Package Management
After some digging around I am pleased with the ecosystem around the Ruby language. Dependency management is handled nicely by Bundler and the Gem system. While I am not a personal fan of the Gemfile syntax (being a DSL) it is very readable and easy to spot errors in. I also like that it handles system level dependencies as well. Need Postgres? Add it. Need a library for geolocation calculations? Add it. Need a SASS process for the frontend asset pipeline? Add it. Even the frameworks Rails and Sinatra are dependencies of your PROJECT, not your project being built from a specific commit of a framework. Sure, there are ways around this but Ruby does it this way by DESIGN.
Oh, and Ruby as a version manager similar to NodeJs. Called RVM (Ruby Version Manager).
- https://bundler.io/
- https://www.cloudcity.io/blog/2015/07/10/how-bundler-works-a-history-of-ruby-dependency-management/
- https://rvm.io/
Bad
Modified SemVer
For the love of everything software use normal SemVer! That means you Rub, Laravel, and anyone else who thinks they are _better_ than nearly 60 years of release management. Stop being a special snowflake.
Automagical Frameworks
Both Rails and Sinatra are both VERY opinionated about how things should be done. Want to do thing's a bit different? Nope, get lost. The language is very flexible but the top two frameworks are very opinionated. I guess this goes hand-in-hand with convention over configuration. You have to expect things to be a given way in order for convention to work properly.
Ugly
Syntax Might be a bit Too short
[A] - [B] = [C]
That is array subtraction in Ruby. If you did not know those are arrays there is minimal chance you would know what is going on. Makes sense for number math, but numbers usually do not have brackets. #confused Some languages have static function for construct manipulation. Not Ruby, nope. "Everything is an object", so everything has innate abilities and functionality. I know, 'cant please everyone everyday'. This is really just a nit-pick more than anything.
Performance
Here is where Ruby falls down. For all the short syntax, everything is an objects, neat-coll-shininess; Ruby 2.6 lags behind PHP 74.3 in all buit the binary Tree test. https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/yarv-php.html
Say what you will, but in the age of instant information every 10ms counts. In some examples Ruby is ice-age slow. the simple fix to this is caching (Redis/et al.). It adds a layer of complexity to even the most basic app but is generally desired for any scale application anyways.
Closing
So far, I am liking it. I could see myself reaching for Ruby (+Rails / Sinatra) for quick web projects for automation scripting as easily as PHP or Golang. 0 (bad) to 10 (good) I give Ruby a 8.5 overall at this time. Will definitely be sticking with it, but has room to grow as well.
What about you, have you used Ruby for an extensive amount of time? Do you have any feelings or opinions about Ruby? Any resources you found helpful while learning the language? Please share in the comments below.
Top comments (26)
If you’re just getting started a couple suggestions:
Replace rvm for rbenv. Much less intrusive to your shell.
Pay close attention to the distinct between what is Rails and what is Ruby. Rails adds a lot of nice methods that aren’t ruby. It also adds a lot of magic that isn’t specific to ruby. A good grounding in Ruby will go a long way in clearing up said magic.
The Well Grounded Rubyist is one of the best books there is on ruby. manning.com/books/the-well-grounde...
Thank you Philip! I will try out rbenv. I was not a fan of rvm changing my system Ruby version every time I wanted to change versions. I have been very aware of the Ruby VS Rails delimiter. I want to learn the language before jumping into any frameworks. Any other books you would recommend?
Probably not the best one to ask as I've been doing Ruby long enough all the books I read are years and years old. On the Rails side I hear very good things about railstutorial.org
All info. is welcome info Philip.
"The optional paren's was confusing at first, but quickly mentally internalized."
Same. I've gotten used to it now, but I still mostly only use it in tests, where RSpec matchers read more fluidly without parens.
I will say, since starting with Rails around 8 months ago, every time I think about starting a new side project I find myself sad that nothing else seems to give you as much as RoR does out of the box
It often takes tens or hundreds of hours to produce code. Ruby's big advantage is that you can write less code and get more done, it's very programmer friendly. Even if the resulting code wasn't as "fast" as alternatives, you get it working sooner and can start optimizing as necessary.
The power of Ruby's data manipulation methods like Enumerable is considerable and you can often solve difficult problems by chaining together a few of those methods with a tiny bit of glue.
Since computers are stupid fast today it's rarely necessary to get too aggressive with optimization. You can throw hardware at the problem until hardware itself becomes expensive. It's not worth spending a month shaving 5% off your runtime if you're running it on a $5/mo. server. You gain nothing. It might make sense if you can run on 25 servers instead of 40.
I tried Ruby (with Rails) for some time. I was in love with how easily and quickly I can create working applications. But I decided to go with Python in a long run, because it felt more natural, as I come from the JavaScript world.
No problem with that. Right tool for the right job. As long as the work gets done.
This is a great approach! :)
You can add "ruby" after 3 symbols to color.
Shows that the "array" there isn't really an array, but an array with a hash in it:
Point 2, performance of the core app, is actually interesting given the current shift back to server-side rendering paired with smarter CDNs/Edge. How much perf (roughly translating to "cloud provider cost") can you take on before it outweighs the gains in dev productivity? I am going to guess no one's hit that point, at least not purely because of stack choice.
Having known Ruby made me a better functional programmer.
You also make an interesting point Daniel. The industery is definatly in the grips of a 'big server, little client' trand.
"Larger the application the slower they tend to operate" was a response to "When you're working with a small- to medium-sized app, speed is often a greater concern than freedom". I think there was a miscommunication between development speed and execution speed. That's my bad.
No language overcomes I/O latency due to network. I did not mean to insinuate one could.
"o, if we're to analyze something objectively, we should consider all of the major yardsticks, right?..." 100% yes. Benchmarks are but one tool. I did not mean to sounds like I was deriding one over the other. Simply reiterating what the tool of benchmarking stated.
Can you talk a bit more about modified SemVer? How does Ruby's SemVer differ from others'?
Sure thing Micah.
Ruby's Versioning (+2.1 onward):
MAJOR: increased when incompatible change which can’t be released in MINOR
Reserved for special events
MINOR: increased every christmas, may be API incompatible
TEENY: security or bug fix which maintains API compatibility
May be increased more than 10 (such as 2.1.11), and will be released every 2-3 months.
PATCH: number of commits since last MINOR release (will be reset at 0 when releasing MINOR)
SemVer:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
So Ruby is using a
version number based on timeschema, whereas SemVer is change set based. As a developer, I don't care when a change happened; I can how bad a change is going to wreck my weekend. #my_opinionAh, yes, I see what you mean now! I thought you meant the Ruby ecosystem in general, but I understand now that you meant the Ruby language itself. I agree with you; this irks me too! Rails is also guilty of this, but getting better about it. At least almost all of the other gems in the Ruby ecosystem are good about following SemVer. :/
Exactly. I was handed a Rails project. Updated from Ruby 2.7 to 2.9 and it broke the app due to a class inheritance change. Very not expected behavior. :( . I had to roll the language version back to get the app to work again. I'm sure we will get to update the app dependencies eventually; I just did not expect a minor version update to wreck things to badly.
1st world problems right? :S