Shopify seems to love Ruby. Ruby doesn't seem to be all too popular now, if I'm a beginner would Ruby be a good language to look into?
(Please don't recommend Python/JS, I dislike them for personal reasons)
Not sure it's a red flag- I bet they're just young. I'm sure they'll grow out of it. We all had unreasonably strong opinions about arbitrary things at one time or another.
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.
I hear you there. I actually used to be an out of control Ruby hater - until I read Eloquent Ruby (fantastic book, my all time fav programming book) and started to understand it from first principles and all the beauty of message passing. I was Ruby-only for a few solid years of my career.
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 haven't been a Ruby programmer for 10 years but I totally agree on Eloquent Ruby. I sure did love that book. I still pick it up sometimes and thumb through it. I did a reading group for Getting Clojure (another book by Russ Olsen) just because I knew he wrote it.
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.
Yeah. I avoided Typescript for the longest time because years prior, I'd had a hell of a time converting a bunch of Coffeescript back into JS. When that project was done I thought "never again will I use a language that tries to 'fix' JS." It was unreasonable and emotional, but also understandable.
Completely agreed. Personally I hated JavaScript too a long time ago, until one afternoon I decided to read JavaScript the Good Parts by Douglas Crockford. That one book alone was able to completely change my mind.
I’ve written Python for 18 years now and I’m certainly not unaware of its warts but its sheer usefulness and productivity makes it worth it. I see languages as a means to an end — some means fit people’s brains better — but at the end of the day you gotta get the work done. Python is definitely a tool that I’ve treasured.
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).
My text editor is written in Ruby. My terminal is written in Ruby, including the truetype renderer and X library, and the syntax highlighting uses the Rouge Ruby-based highlighter, extended with some more Ruby to read GtkSourceView themes. My desktop manager is written in Ruby.
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.
One of the greatest things of 80s micros were built-in BASIC interpreters. Turn it on and program immediately. Combined with source code listings to type in from magazines, you almost had to resist picking up some programming skills. Even the command to load a game was a form of programming already, even though 6-year old me didn't "get" it until a bit later.
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."
Same for me on not immediately “getting it.” I started with an Atari 800XL and wrote some small stuff but didn’t realize I was programming until a few years later. It was fun tho. I miss that simplicity.
I like both Python and Ruby and aesthetically Ruby is better and I can see why people are happier writing on Ruby.
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.
It sounds like programming is a "means to an end" and you don't cate that much about the plumbing as you do about the outcome, so you use python out of convenience and not out of taste? If that's so, fine, but you don't seem to have much "stake" in the discussion.
> 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’m advocating for seeing the big picture. It’s not that I don’t care about programming, but I try to care for it in proportion to achieving impact, which I feel is the more important thing (most seniors and higher would agree).
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.
Machine learning is one area where it takes a bit more imagination to do it in Ruby, but you can easily wrap both compiled code and Python for that matter and still do your own work in Ruby if that's what you want to do.
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.
It could be more positive than despise for another language. The preference for a language might be out of emotional attachment at the specific workflows in which that toolchain allowed creativity to flow. And if you have an AI coder LLM that gave you good output with one training and performed poorly with another, would you say that the one with good output is worthless because was good at {{insertYourLeastFavouriteTechHere}}?
> It could be more positive than despise for another language. The preference for a language might be out of emotional attachment at the specific workflows in which that toolchain allowed creativity to flow.
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 you're a beginner, Ruby is as good a language as any. Fundamentals are what you should focus on. Pick anything reasonable that appeals to you. Ruby is well inside the boundary of reasonable choices, regardless of popularity metrics.
If you're just starting with programming, start with a high level language and work on something interesting to you. Doesn't really matter what language it is. What matters is working on something that will keep you interested.
It's interesting to see "there are no Ruby jobs" comments while working at a company that hires from outside the country because we can't find enough developers locally.
Don't worry so much about languages. If you specifically like web apps and Rails' ideals [0] then it's an obvious choice to look into. A lot of Ruby is Rails. But it's also worth looking into if you just like how it looks.
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.
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 :)
I love Ruby. As the saying goes, It was developed with programmer happiness with mind. Once you learn more than hello world, you start to see there is actual joy to be had in programming in Ruby.
It was developed with the happiness of a particular type of programmer in mind. No matter how much Ruby I learned, my experience had more irritation than joy. I had many experiences where a Ruby fan would condescendingly explain why a friction point that I was experiencing was actually a good thing, with the implication that I was apparently too stupid to see the light. Now I never write Ruby unless I can't avoid it.
But I know people who love it, as you seem to, which is great...but not a universal sentiment.
I've come to really loathe how there's ! and not-! versions of otherwise similarly named methods. It's such a sneaky, small difference and it's caused several bugs in the codebase I work on.
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.
There’s a method to the madness. Which I’ll explain a little for others. :)
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. :)
This actually helps me understand some aspects of the language that have been frustrating me, thank you!
> 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 :)
Ruby's a great language. It wouldn't hurt to spend a month on using it. But the key is some motivation for using it. For many tasks it will get the job done.
> if I'm a beginner would Ruby be a good language to look into?
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.
> (Please don't recommend Python/JS, I dislike them for personal reasons)
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?
They're dissimilar enough that there are plenty of people who love one but dislike one or both of the other. I don't see any reason why they'd be certain they'll feel differently, but they're not going to find that out without giving it a try.
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.
All the fun and productive parts of Ruby, but much better concurrency story (great for realtime stuff), functional language, nice pattern matching, and much faster (cheaper to run).
I am a long-time rubyist (since 2004 and still using it) but I do not think it is a safe bet of your time.
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 :-)
> I find that the « usage surface » of Elixir is much wider than Ruby’s, today.
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.
Then I find it an even stranger claim. I've done everything from statistics amd financial modelling, via web apps, image and sound processing to desktop apps in Ruby. For a few things people are best off using ffi to wrap compiled libraries, but there's never been anything I've wanted to do that I haven't been able to.
I was in the same boat as you until recently. I have done everything I can imagine with Ruby! But it turns out I can do them better & "more broadly" with Elixir.
Note that I'm not trying to convince you, just sharing my experience :-)
I'm mostly curious, because I've not run into limits with Ruby that'd make me look elsewhere.
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.
It's perfectly fine :-) I've also used a lot of languages either professionally or not (ranging from assembly/bytecode to much higher level, c#, java, c++, bits of rust etc etc), but I can perfectly see why you wouldn't find it appealing.
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).
I find that interesting because I've not run into a single scenario where I can't keep Ruby, so I'm curious where that's an issue for you. I suspect part of it is a different level of tolerance for wrapping tools instead of switching to their native languages. E.g. faced with "having" to use a Python project I'd be more inclined to wrap it in Ruby than writing Python.
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.
Ruby is a great language. It is very expressive and often quite readable. Ruby has a strong standard library, and the ruby gem ecosystem is great. Ruby is a highly productive language for devs to use as it makes prototyping easy. In terms of benchmark performance, I would say it is probably closest to python. One thing I stress when comparing CPU performance of languages is to not get hung up on that too much. Most web apps I work on get hung up on IO and database interactions and not CPU. I've been working with ruby for 17 years and the number of times ruby's performance has got in my way are too few for me to mention.
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.
Ruby might be readable, but I've really come to hate working in a Rails codebase. So much of what happens is 'magick' that's not obvious, and I constantly hate not having typechecking backing me up.
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've been working with rails for a long time, so it doesn't feel like magic to me, but I can understand that concern. I highly discourage metaprogramming unless there is an obvious win. Rails/Ruby, especially in the beginning really leaned in hard on metaprogramming, but I've seen that be less of a trend with ruby. From my perspective, the metaprogramming trend has been going down. Ruby makes writing DSLs easy, and that can appear as magical too. In general, if a rails project follows convention it is easy to find what you're looking for.
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.
Yeah, our rails codebase by default has everything in the global namespace. It's possible to add namespacing with modules, which we do all over the place, but it took some getting used to for me to learn that everything was automatically "available" without any import statements anywhere.
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.
It may not be as employment-friendly as it once was, but it sure is pleasant to use. I like it better than anything except Scheme, personally.
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).
Strong or weak typing doesn't have an impact type safety.
TypeScript is statically typed which guarantees type safety.
TypeScript is often used in web environment which often leads to developers defeating the type system. For example, applications often cast some user input, API response, or local storage to an expected type, but that is not a limitation of TypeScript, and would not necessarily be solved by using some other language like Go or Rust.
TypeScript is an unsound type system [0], but in practice this doesn't have any real impact on most web applications.
This looks to be a lift of the Ruby MRI interpreter via emscripten and targeted at non-browser runtimes, using linear memory rather than GC. Would be cool to see a non-emscripten Ruby for WASM GC.
90 comments
[ 2.9 ms ] story [ 160 ms ] threadFor getting a job - probably no, but depends on your local job market.
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.
I like to recommend https://natureofcode.com/book/introduction/
The author also has a YouTube channel, but the book is quite fantastic.
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.
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 :)
10.times do
endWhat does the code Ruby code above do? Pretty Obvious. Is very readable.
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 :)
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.
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.
[0] https://www.youtube.com/watch?v=oeqPrUmVz-o
These days, Elixir just makes just so much more sense.
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.
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.
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).
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.
Disclaimer: I am a Rust developer who targets the web.
TypeScript is statically typed which guarantees type safety.
TypeScript is often used in web environment which often leads to developers defeating the type system. For example, applications often cast some user input, API response, or local storage to an expected type, but that is not a limitation of TypeScript, and would not necessarily be solved by using some other language like Go or Rust.
TypeScript is an unsound type system [0], but in practice this doesn't have any real impact on most web applications.
[0]: https://www.typescriptlang.org/docs/handbook/type-compatibil...
The web isn't a hellscape, but I'm still hyped about WASM on here!
^ With opt-in memory leaks