Cover image for My First 12 hours with Ruby

My First 12 hours with Ruby

david_j_eddy profile image David J Eddy ・5 min read

Cross posted from my blog.


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.


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).


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.


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.


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.


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.

Posted on by:

david_j_eddy profile

David J Eddy


AWS Certified (x4), Automated Testing / Continuous Integration / Delivery / Deployment (CI/CDs), Cloud, Containers, Dev(Sec)Ops, Software Engineer.


markdown guide

As a non-Rubyist who tried Ruby earlier, I have to disagree on almost everything. :-)

  • All frameworks in all languages are opinionated. The difference is only in degree. When you're working with a small- to medium-sized app, speed is often a greater concern than freedom, which explains the explosive popularity of Laravel in PHP, Django in Python, and so on. Even Go is seeing a Rails-style framework being actively developed -- Buffalo.
  • I can only laugh at benchmarks. This site runs on Rails. Any complaints? Last I knew, StackOverflow ran on .Net on a couple of servers only. If number crunching is your only yardstick, I feel sorry for you and recommend Fortran. And if it's memory efficiency, well, there's Rust.
  • Your reaching for PHP/Go is simply a matter of familiarity. Are you saying there are no objectively better solutions than PHP/Go when it comes to web development?
  • Syntax: Ruby tries to harmonize (and normalize) as much as possible. I see as a great reducer of mental friction once you are past the basics.
  • rvm vs npm? Please! The Ruby web ecosystem is as stable and solid as a mountain. I'd only put the Java ecosystem (maybe even Erlang) ahead of it, other things being equal.

All in all, Ruby is has the highest pleasant to annoying ratio of all the langauges I've explored (and believe me I've explored many!). That, coupled with a solid history and amazing community (like you said) makes it a wonderful choice for web apps (and maybe even some non-web stuff).


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.

  • Very valid point in regards to frameworks. However I would argue that medium to large apps performance is more of a concern than for small / meds. Larger the applicaiton the slower they tend to operate. At lteat in my experience. LArger the app, the more people and effort hours have done into to the logic the more 'quick fixes' and cluges to 'get it to work'. Not to mention to geographic distance between processing, database, etc. These leading to more and more slowness.
  • Of course benchmarks are not the only measuring stick. Simply one of many. CDN's, caching, right-sized hardware; many solutions exist. Benchmarking is simply one of many parts of the stick.
  • At you point out, the comparisons are based on familiarity. One of the reasons I want to learn Ruby is to expand the scope of experience.

You also make an interesting point Daniel. The industery is definatly in the grips of a 'big server, little client' trand.


Larger the applicaiton the slower they tend to operate

Okay, but how is this related to language benchmarks? The slowness is in the I/O, which can't be removed even if you code in Assembly. 🤔

Not to mention to geographic distance between processing, database, etc. These leading to more and more slowness.

Yes, and how does PHP overcome these problems better than Ruby?

Benchmarking is simply one of many parts of the stick.

So, if we're to analyze something objectively, we should consider all of the major yardsticks, right? If so, using just the benchmarks to denounce another language is not done. 😊

"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.


"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


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.


You can add "ruby" after 3 symbols to color.

[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

Shows that the "array" there isn't really an array, but an array with a hash in it:

[0 => 'value']
# => [{0=>"value"}]

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.


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.


Having known Ruby made me a better functional programmer.


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)

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 time schema, 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_opinion


Ah, 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


Phoenix has microsecond (!) response times o_0. Wow.


Thanks for the info, will look into.


Ah, Hanami! I knew there was a non-opinionated framework for Ruby, but the name just won't come to me. :-)

Elixir, Erlang, and Ruby. I assumed based on your comment that you enjoyed some aspect of each one. If that’s the case, I’m just curious what those aspects might be.


Thank you for the resource Aleksei, I'll check out Phoenix.


Python is harder for functional programming? Interesting. I am curious, do you have any person experience examples you would be willing to share.


What about those three languages did you enjoy?


Thank you for the perspective Aleksei, I will give Hanami a look.