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 ...
For further actions, you may consider blocking this person and/or reporting abuse
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 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_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
Thank you for the perspective Aleksei, I will give Hanami a look.
Thank you for the resource Aleksei, I'll check out Phoenix.
Thanks for the info, will look into.
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.
Phoenix has microsecond (!) response times o_0. Wow.
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?