1. I am Shopify or another huge Ruby shop with a lot of existing engineering knowledge, libraries, team members etc.
2. I am interested in building something with Rails
Otherwise I cannot think of a compelling reason to choose Ruby.
The red flag here is that you dislike Python and JS for personal reasons which makes me think that any reasonable advice will not be important to you.
If you really hated the way pencils smelled and you're trying to get into sketching, and everyone always says "use pencils", could get frustrating. It's the best tool for the job, but you can probably also get pretty far with a pen.
You can certainly be a successful engineer while never learning specific languages.
That being said, a specific language can be the best tool for the job, and there are many things for which python and js are the best tools.
The quicker a young engineer can table that kind of unsubstantiated bias the better. Then again that could go for all aspects of life!
I totally agree. I have to remind myself often, I may not like the tool, but if I allow myself to get competent with it, I can complete any job. The more I sit around and hate it, the less effective I am.
I used to be infatuated with Lisp and Haskell and their sheer elegance. But now that I’m more experienced I’ve learned that picking a language comes down to practicality and maintainability as well as interoperability with other humans (library ecosystem, labor pool, stack overflow solution searchability).
For me the compelling reason to choose Ruby is that I could hack those things together quickly on my own in a few thousand lines of code and have an enjoyable experience both writing those tools and using them (I've done all my editing in my own editor for the last 6+ years, including editing the editor itself). The rest is newer.
(The whole "stack" above takes up fewer lines of code than the "st" terminal emulator and less than 10% the size of xterm; the truetype renderer was a 1 day conversion from a small C renderer, and weighs in at about 500 lines of code - that is why I love Ruby)
I'm 48. I've been writing code for 43 of those. I have no intention of spending time on Python more than absolutely necessary, because where Ruby is enjoyable to me, Python is absolutely not. I frankly find the notion of talking about people "growing out of this" quite condescending. There's nothing unreasonable about having preferences and being prepared to prioritise happiness.
For my part I've easily been able to make my living in a mix of (mostly) Ruby and JS for the last 18 years without making any sacrifices for it (I've not avoided looking for jobs that requires other languages, including Python - I have experience with more than a dozen different languages so I'm not afraid of using far worse things than Python when I've had to).
I've been in my field long enough to have seen many languages vax and vane in popularity, and I stopped caring about whether a language was popular 20+ years ago. My happiness is far more important.
I'd say as a young developer being willing to at least pick up the basics may be worth putting aside the distaste. But soon enough you get to a career stage where it doesn't matter and where you have the flexibility to pick jobs where you can pick your tools.
We didn’t have a lot of entertainment back then.
We have easy access to so much amazing technology for free in today's day and age, but we IMHO really lost a lot from the glorious days of "38911 Basic Bytes Free - Ready."
But to me happiness comes from achieving the ends — eg training a model, deploying code that impacts millions of people. I’ve done that with Python and I can honestly say I couldn’t have done the same with Ruby because the Ruby ecosystem and tooling didn’t support such impact size in my (and many similar) domains.
I don’t think it’s wrong to tell younger folks to see th big picture and focus on impact before personal preference. Everyone can choose their own path of course but I’ve generally found that focusing on impact has led me to take on more meaningful projects.
> I can honestly say I couldn’t have done the same with Ruby because the Ruby ecosystem and tooling didn’t support such impact size in my (and many similar) domains.
But did you give it an honest try, or is that an assumption? While no ecosystem I at python's level in the ML space, Ruby's contributions are not necessarily non-existent, and you'll find a few options when you actually look for it (sidenote: the pgvector extension for postgresql has been created by a prominent ruby ML developer)
I did give Ruby an honest shot, the maturity of the ecosystem around numerical computation and machine learning (my field) is nowhere near Python’s. That is to say, it’s not that Ruby was bad, but that Python was so far ahead of everything else that to deviate from that would mean spending an inordinate amount of time reinventing the wheel. I’ve certain fallen into this trap in the past (which caused to me extend my graduate school tenure by a year because I wanted to use a niche language which was cool but ended up having to spend time working around corner cases, which were solved problems in more popular and meticulously maintained libraries in other languages). Sometimes going with the mainstream means you get a lot solutions for free and can focus on your problem.
Programming language choice is partly aesthetic —- some languages are more elegant than others —- but if you want to be employed and want to create real impact in the world, it has to be tempered with hard nosed pragmatism as well. You’re paid to deliver solutions to problems, not to optimize your preferences. Sometimes you can do both, but when you can’t, solving the problem must take precedence.
I'd strongly argue that irrespective of your preferred language (ok, almost, before someone brings up Intercal or something) if you in any domain think it doesn't support what you want to do, what it actually means is that you don't understand how to achieve it with that tool. That's fine, and maybe it's not the right tool for you, but it's not the fault of your tools
And if you're not happy with what you're working on, you're unlikely to stick with it long enough to have any impact. And even you do, if the result is being miserable it's not worth it.
You can insert direct linux command inside `` and they are executed inside.
For me this simplicity and power is hard to beat.
For sure. Ruby gives me warm fuzzies a lot more than Python simply because I first started "seriously" programming in the era when Ruby, Rails, and TextMate dominated back end web development and was on board the RoR train.
Preference of this sort can also be driven by little things that some might consider inconsequential… those bits and pieces can be what makes the difference for someone in determining if a language is enjoyable to write or not.
If I were to pick web dev back up though, there's a good chance it'd be with Ruby+Rails or Elixir+Phoenix.
Any language is fine for a beginner.
Anything you can accomplish in one language you can accomplish in any other language. The concepts you learn as a beginner in one language will transfer over to other languages.
There are a lot of caveats to the above, but the exceptions don't apply until you're very experienced or working on advanced projects.
> (Please don't recommend Python/JS, I dislike them for personal reasons)
There's absolutely nothing wrong with either of these languages. Python and JS are _very_ widely used. You might want to consider why you're avoiding these languages.
JavaScript (and to a much lesser extent, Python) are disliked, but they aren't "bad" languages. JavaScript has quite a few very interesting ideas, and is very easy to build interesting things with. Python is very popular for a large range of tasks from scripting to data analysis to building entire applications.
I like to recommend https://natureofcode.com/book/introduction/
The author also has a YouTube channel, but the book is quite fantastic.
Most of the knowledge is transferrable, you don't have to be a "${language} developer", you'll learn whatever is most useful to you as you explore.
[0] https://rubyonrails.org/doctrine
Edit: I think you're pretty young, good for you for just wanting to dive into making stuff! Welcome to an amazingly fulfilling passion + career in engineering should you want to keep with it :)
What makes you think you wouldn't also dislike Ruby? I don't deny there are probably things Ruby does better than either Python or JS, but they aren't so dissimilar that if you have some sort of semi-rational "personal reason" for disliking Python and JS, that you wouldn't also dislike Ruby.
And if you're a beginner who wants to be employable, why be so picky and turn up your nose at two of the most popular languages?
The founder, Tobi, is a Rubyist and was around the Rails world in its earliest days, so there's a sense of personal preference (plus a huge amount of existing code) at play beyond the technical merits.
Can't say it better than Mr Jobs himself on this subject.
For getting a job - probably no, but depends on your local job market.
Finding a job with ruby isn't too bad. Keep in mind that just because there aren't as many ruby jobs that also means competition may be less because fewer people know ruby. 9/10 (probably higher) jobs will be rails jobs. Rails is an outstanding web framework. There is a reason rails is still one of the most popular web frameworks after 20 years.
For learning to program, choose something you enjoy. If you pick a tech that doesn't agree with you, learning is going to be an uphill battle. I don't love JS, and I don't find python enjoyable either. Pick something that clicks for you. Once you learn one, other languages will be easier to pick up. Disclaimer, ruby is my favorite language.
Blocks are cool, and Ruby makes them so easy to use which is neat, but global namespacing, lack of types, and a general "I'll do it for you" attitude has made it frustrating for me to learn. Not having a reliable go-to-definition in my IDE is driving me insane as well.
I'm less than a year into a new job at a Rails shop though, so obviously a grain of salt with the above, but I've had several peers of mine echo the same frustrations I've had so I don't feel TOTALLY nuts.
I don't understand what you mean the global namespacing. Ruby has namespacing, and adding to the global namespace should be avoided except for adding new class definitions. Maybe you're referring to inheritance, and how much stuff can sneak into the current scope from class inheritance.
While convenient, it's made it very hard for me to reason about each module's dependencies and interconnections to other bits of the code.
But I know people who love it, as you seem to, which is great...but not a universal sentiment.
Also the "last statement evaluated is what's returned" behavior leads to super not obvious data flows sometimes which is similarly frustrating.
A lot of ruby's philosophy seems rooted around doing away with what looks like redundant code at a severe cost to readability / adding significant cognitive load, in the name of "elegance," and that drives a LOT of my frustrations with my org's ruby codebase.
If you see ! on a method it means one of two things:
1. The method modifies the object in place in and may return nil if no change is made. This is what the Ruby standard library does.
2. The method throws an exception when there’s an error. Usually there’s a non-! version that returns nil or false instead. Rails made this a popular option.
Ruby likes to provide everything so there are methods that return new objects and there are methods that modify objects in place.
And there are a lot of methods to do almost everything you can think. Which tends to make Ruby code more compact.
But you have to keep the documentation handy until you’ve learned them because the method names are odd. The designer of the language it’s not a native English speaker.
The if keyword returning a value takes some getting used to.
You never see a for loop because you pass code blocks to iteration methods. This kind of thing is all over the language.
You don’t need parentheses on method calls, which means you need to know if you’re dealing with a local variable or an instance method.
Another thing is Ruby allows code to be far more compact. Doing the same thing in python may require two to ten times the amount of lines. But if you can’t read Ruby code quickly and follow what happening, any advantage compactness might have becomes an exercise in frustration.
All in all Ruby a bit of an odd language. I personally find it an absolute joy to work with, but a lot of people very justifiably do not have the same opinion. :)
> Another thing is Ruby allows code to be far more compact
Yes, this I've definitely noticed, and I do really like. The block syntax and proliferation of functional-style stuff is an absolute joy... most of the time. It fits the style of how I like to think about problems, and lets me move very quickly for writing code, but I often find myself confused about what existing code does, and it takes me a while to load the context into my mind when I'm working on something.
I think that's because while other languages (like Python) tend to be more verbose, that verbosity leaves room to explain what's going on more clearly. I'm not saying verbosity is always a good thing--I've written enough Java to know that, but I do sometimes find myself wishing there were more 'clues' in the ruby code I deal with to help understand what's going on.
Not needing parenthesis and general strangeness around value returning doesn't help, either. Again, I see how it makes code more compact, and that can be a good thing (fitting more relevant code on the screen at the same time), but inasmuch as understanding what's going on quickly, sometimes I wish there were a few more markers :)
10.times do
puts 'Hello, World!'
endWhat does the code Ruby code above do? Pretty Obvious. Is very readable.
I really need to prepare an article on that, but although it is a bit weird and different initially (functional roots are less classic for most developers), I find that the « usage surface » of Elixir is much wider than Ruby’s, today.
You can do pretty much everything you can do with Ruby (web apps, API, scripting…) but more trivially scalable (including things like real-time chats), and more: machine learning, computer vision, embedded, and soon mobile apps…
Its interop story with Rust is fairly good and this allows interesting extensions (see Explorer, with integration with the fast Polars data frame library).
Maintenance is overall good as well (for multiple reasons including core design), the churn is lower than Javascript, and the developer experience is improving on a regular basis.
I am starting to meet with CS schools to see how to put this in the good hands of students :-)
Conversely, I hardly never see Elixir advertised from anywhere I pay attention to, including in several years working at a VC evaluating the technology of potential investments.
I suspect we're both stuck in bubbles.
I agree that it remains a niche language at the moment, something I am trying to change at my level.
Note that I'm not trying to convince you, just sharing my experience :-)
I've used over a dozen languages professionally over the years, so when I have a reason to I pick another one, but Elixir has never felt compelling to me - I just don't see it offering enough new/different stuff to be worthwhile.
I've built large-scale distributed systems, and so on one hand the features of the Erlang VM are appealing and I've enjoyed reading papers on it. On the other hand I know how to - and have - built similar concurrency, restart and auto-updating/hotswapping functionality in other languages (including Ruby, where it's fairly easy) and it doesn't require enough code to compel me to pick a language based on that.
In my case the main appeal is not the scalability/concurrency story (although it's great), nor the hot-swapping (I've done it with Ruby, C# and a couple more) or pluggability, it's more the increased number of scenarios where I can keep this single language (from scripting to "regular code" to embedded to, recently, machine learning).
But if you do not feel compelled, well there is no reason to force!
Compare to Ruby specifically, I find that the concurrency story is quite different (I have used concurrent-ruby, JRuby etc, and find the built-in tools in Elixir quite amazing, including Task.async_stream).
As for concurrency, my default assumption in any language is to go multi process unless there is a measurable reason why that is too costly, because it means I can then generally scale seamlessly to multiple physical servers too when needed with nothing more than fork(), spawn(), and DrB or TcpServer once you want to farm it out across machines.
I used to render map tiles in Ruby that way, for example, and it scaled effortlessly to hundreds of cores.
Or to take another example: My text editor is fully concurrent and in Ruby - the buffers reside in a separate process and multiple concurrent processes, be it viewers/editors or utility scripts can simultaneously operate on the same buffer via DrB.
TS/Node is gaining my favour, but a good rails dev will out-ship a TS dev any day of the week. It's an amazing startup language.
I agree with you about Python, but I've come to appreciate JS much more than I once did (it helps that some of the major pain points have gone away in recent versions).
These days, Elixir just makes just so much more sense.
Read the other comments: people who work with ruby usually love it.
In every HN ruby related post, there's always some post like "ruby is dead". I've been hearing that since I started my career 10 years ago.