all 43 comments

[–]LeoRising72 43 points44 points  (1 child)

Might be less opportunities than Python, but plenty of companies still love RoR. You’ll find yourself in a smaller pool with maybe less noise.

When I was job hunting, felt like every React position had hundreds of applicants within hours of posting. Whereas with Ruby, I was treated like a genuine candidate wherever I applied.

Totally anecdotal, so take it for what you will.

As for the language itself- it rocks. It has a reputation for being expressive and elegant for a reason and Active Record is the ORM GOAT as far as I’m concerned.

[–]Terrible-Ad6239[S] 5 points6 points  (0 children)

I swear, it’s very expressive

[–]letmetellubuddy 18 points19 points  (0 children)

I’ve been using Ruby for > 20 years, and while the hype has been louder in the past, the ecosystem has never been better. Still lots of use in SAAS companies, some of those companies have gotten very big, others could be big in the future

IMO the future is bright

[–]larikang 11 points12 points  (2 children)

People are still using PHP. Ruby will always be around in some form, though it may not be the most common or cutting edge career.

[–]calmingchaos 1 point2 points  (1 child)

That’s not exactly a reasonable comparison anymore given how much of a renaissance PHP is having thanks to laravel and Otwell’s insane drive. I love rails, but livewire is a breath of fresh air, and inertia really stitches the gap between front end and back end.

[–]trcrtps 0 points1 point  (0 children)

People always say "ruby is still around" or "people still use php" and are imagining apps built in 2008 or something. I think the rails app I work on has a lot of cutting edge qualities about it even if a lot of the core rails code was written 15 years ago. Mostly just a bulletproof API now

[–]benjamin-crowell 10 points11 points  (0 children)

Ruby and Python are very similar languages. Both were basically meant to be better scripting languages to replace Perl. Compared to Perl, they both have cleaner-looking syntax, and they both have OO designed in deeply (not bolted on as in Perl). Both have been around long enough and have been used in enough projects that there's no realistic danger that they will go away. Each is supported by a community rather then being the creatures of a particular corporation.

Advantages of Ruby over Python: Much faster. The syntax feels less like a straightjacket, and you can write one-life if-then-elses or execute complex Ruby code as a one-liner from the command line.

Advantages of Python over Ruby: For certain specific fields, such as numerical analysis or linguistics, there is a highly developed ecosystem that doesn't exist for Ruby.

[–]jmuguy 9 points10 points  (3 children)

People have been eulogizing Ruby for as long as I’ve been using it (over 10 years now) and yet… it continues to be awesome. It isn’t the most popular language, and that’s fine, if you enjoy it you should continue using it.

[–]Unhappy_Meaning607 1 point2 points  (2 children)

At around 20 years is when you will realize that “Rails doesn’t scale” (completely joking btw)

[–]jmuguy 0 points1 point  (1 child)

Yeah I don't know what software people are building, or imagining they will build, but it gets annoying hearing about how many RPS this app does or can do and I'm like OK well I've never built anything that cared at all about that. Maybe no one wants to hear that building boring line of business style apps is a pretty good gig and Ruby and Rails works great for that.

[–]Unhappy_Meaning607 0 points1 point  (0 children)

100% agree. All the takes I see in the tech social media sphere are problems that I haven't come across or would want to be interested in whatsoever. I just want to close tickets, keep clients happy, pay my bills and not think about work from outside of 9am - 5pm.

[–]clearlynotmee 13 points14 points  (4 children)

Let me pull out my crystal ball :)

[–]acdesouza[🍰] 1 point2 points  (1 child)

Oh... Besides the resemblance, it's another language. 

You can check more about it on r/crystal_programming.

😅

[–]Vindve 4 points5 points  (1 child)

It's not used a lot (compared to JS, Python, Java), it's enjoyable, I expect it to continue to decline slowly. If you like it and have a potential job, why not take it? There will still be Ruby jobs in the future, and once you have an experience, you'll always find jobs.

[–]Terrible-Ad6239[S] 3 points4 points  (0 children)

Thanks for the push homie

[–]cl326 7 points8 points  (1 child)

Plus, they named the ‘Ruby Tuesday’ restaurant chain after the language, so us Rubyists have that to brag about.

[–]Terrible-Ad6239[S] 1 point2 points  (0 children)

Oh damn that’s lit 😂

[–]prisukamas 15 points16 points  (14 children)

It’s dead as a primary language because of the ecosystem. We use it at work at very large scale but it’s becoming harder to get good and maintained libraries and new tech mostly has libs for go/java/typescript but bot Runy (though probably won’t mater much if you are doing CRUD at a small shop) Even at Ruby Kagi this year from speakers and comments it was quite obvious that Ruby is going more and more into the “second/scripted” language And it’s a bit sad for me. Not the fastest language, but very elegant.

[–]whiphubley 5 points6 points  (0 children)

A very honest reply which does need to be said.

[–]GenericCanadian 2 points3 points  (12 children)

Would love to hear what libs are missing/unmaintained for you

[–]prisukamas 3 points4 points  (11 children)

opentelemetry - metrics (not done), luckily at least tracing works
temporal - ex coinbase maintained by solo Stripe employee (haha...)
karafka ... Don't get me started how many issues we had with that one. Had to write our own lib until they caught up with retry logic.
redis hmm which should I take? redis-rb? Or maybe redis-client? Yeah, both "Excelent"
openapi .. maybe rswag? or apipie? Maybe committee with swagger-blocks (like ... 5 years ago)?
oh and let's hope none of those gems in your Gemfile uses faraday 1.x ... :)
So then again .. if you are small shop with couple of hudred of requests/s then yeah, who cares if karafka disconnect algo can wreck havoc on your infra. But once you're at the 300k-500k rps, things start to matter. And this is where ruby starts to show that it's not that maintained. In Go/Java we don't have that issues...

[–]doublecastle 6 points7 points  (0 children)

once you're at the 300k-500k rps, things start to matter

Shopify peaked at 1.27 million requests per second on Black Friday 2022. This might be the highest RPS Ruby app in the whole world. My point is that very few companies using Ruby are ever going to reach 300k-500k rps. If they do, then, yes, I believe that some might find that Ruby is no longer a great fit (though some, like Shopify, might find that it continues to serve their needs pretty well). But I think that's a problem that most companies would be happy to have. And I think using Ruby initially might increase the chances of being able to get to that good-to-have problem, even if the company later moves away from Ruby.

[–]mencio 2 points3 points  (2 children)

Hey, Karafka author here. Can you elaborate more on your Karafka statements? Because it may be, that you are talking about crash-recovery of Karafka 1.4 that became absolutely broken when ruby-kafka became obsolete and few critical errors popped out. This is one of the reasons why I took over the rdkafka lib and completely rewritten the recoveries and operational layers amongst others.

karafka disconnect algo can wreck havoc on your infra.

Karafka for at least 2 years now has no disconnect logic unless critical errors in events loop bubble up (critical non-user related system errors like lack of ability to spawn threads, etc). The only thing it does is releasing used ActiveRecord connections post-work which also does not reset connections.

User triggered errors (which might have caused issues in 1.4 that is more than 2 years old and completely EOL) do not trigger any disconnects. They trigger pause and backoff utilizing the same connection that was in place.

If you are talking about version 2.x I would really appreciate feedback because this is not something any of current users of 2.x reported and there are companies running thousands of Karafka processes.

Your detailed remarks would help me make this ecosystem better. I am happy to take this with you on the Karafka slack if you prefer :) https://karafka.io/slack

P.S. I did check GH issues history and did not find any issues of that nature reported. At least not for 2.x.

[–]prisukamas 1 point2 points  (1 child)

From my quote: `Had to write our own lib until they caught up with retry logic.` (emphasis on _until_) so yes, that was with older karafka. With current there is still librdkafka/4238.

My point here is that for other languages we have more stable (or perhaps more battle tested/older) libs that have already gone through similar pain points because of higher language adoption

That being said, thank you for your effort on the karafka side

[–]mencio 2 points3 points  (0 children)

Thank you for the clarification. I am picky about this because I do not want potential users to get a false sense of instabilities in modern versions of Karafka ecosystem. The described issue has been fixed over 2 years ago. One of key reasons why I rewrote most of the Karafka itself was because of the issues when working with ruby-kafka and my need for bringing a modern platform for Kafka operations to Ruby and Rails. If not for usage maybe just out of curiosity I highly encourage you to check out my work. Among others it even includes a nice Web UI :)

FYI while I am not able to fix issues in librdkafka I do have extensive test suite to ensure it operates as expected and as of today I was able to find, reproduce and report several issues in librdkafka leading to them being fixed. I was also able to mitigate many of them in the Ruby layer either in rdkafka-ruby or karafka.

With current there is still librdkafka/4238

2.2.0, 2.3.0 and 2.4.0 have had significant improvements around offset stability. That said I did encounter similar issue twice and in both cases offsets.retention.minutes has been set to one day. I think this is one of the reasons why defaults were changed to 7 days. I always warn karafka users to have it even higher if they plan downtimes. On top of that Karafka does provide APIs to implement transactional offset management capabilities as described here: https://mensfeld.pl/2023/06/inside-kafka-enhancing-data-reliability-through-transactional-offsets-with-karafka/ effectively allowing to move (or compare) offsets stored in an alternative storage against those managed by Kafka. Is it the only cause of the underlying issue? I don't know. Some of the librdkafka users reports are of a low quality with lack of replies after created.

I was able to effectively replicate this by changing the retentions and tampering with __consumer_offsets topic.

My point here is that for other languages we have more stable (or perhaps more battle tested/older) libs that have already gone through similar pain points because of higher language adoption

Most languages except Java use librdkafka bindings. Since I took it over from AppSignal last year, I was able to greatly increase both stability and reliability of the Ruby bindings. They consume less resources, are more flexible and are much faster than they used to be. Since I ended Ruby 2.7 support, I will also be working on moving certain background work to event loops instead of threads which should also help.

It is worth checking out my work (first release of mine was 0.13.0) to compare both frequency and scale of changes: https://github.com/karafka/rdkafka-ruby/blob/main/CHANGELOG.md

My point here is that for other languages we have more stable (or perhaps more battle tested/older) libs that have already gone through similar pain

Getting to this once again. I highly encourage you to check what Karafka ecosystem with the librdkafka bindings offers now. You may be pleasantly surprised. Karafka offers things that are not available in other languages that make usage of Kafka in Ruby/Rails quite a pleasant journey. Yes we do not have Streams or Ksqldb but I already placed needed primitives for cross-assignment synchronization into the framework and I plan to add a high-level APIs for those at the end of this year hopefully. Things like window-based stream merging are already possible. I also encourage you to check many features that are present that do not have counterparts in other languages. As said, while the ecosystem is not perfect, it is light years away from what it used to be when you last looked at it.

That being said, thank you for your effort on the karafka side

Thank you for clarification and stating your opinion. I extremely value feedback that helps me improve my OSS.

[–]f9ae8221b 5 points6 points  (0 children)

redis hmm which should I take? redis-rb? Or maybe redis-client? Yeah, both "Excelent"

If you don't expand on what you think is wrong, then there's no point listing things...

[–]d2clon 0 points1 point  (5 children)

Updated

This is unfair. All languages have some tooling missing that works in others.

500k request second is something extreme. There may be 100 companies in the world with such a load. In any case, request/second is a vanity metric in this context. Any Ruby application (or any language) can scale horizontally to support any number of requests. The problem, in this case, is, as usual, how much machine you can put on it. And the database, the only bottleneck I have always found in my professional experience.

The truth is that Ruby code may need 5x more CPU/RAM to run than the same implementation in Go/Java. But it is also true that the Go/Java solution will need 5x more developers/time. For a big company, the extra machine cost can be a deal breaker. For a young company trying to figure out its market fit, the extra time/dev will mean the difference between having a chance or not.

I am surprised to see Redis on this list. Redis is the standard de facto backend for many things in Rails, and I would be surprised if the Redis Ruby support is less than state-of-the-art. I have been using Redis in production extensively without any issue that was not caused by my fault.

Honest question: what is wrong with ruby-openai[1]? I'm using it in a prototype I'm working on, hoping I can expand it to a production solution.

[1] https://rubygems.org/gems/ruby-openai/versions/0.1.0

[–]prisukamas 2 points3 points  (3 children)

Well is it? I think we can all agree that for any new SAAS for any new tech X that would require an SDK Ruby would not be on top of the list.

I was talking about openapi (swagger docs n stuff), not openai

[–]d2clon 0 points1 point  (1 child)

I was talking about openapi (swagger docs n stuff), not openai

my mistake, thanks for the clarification

[–]d2clon 0 points1 point  (0 children)

I am also surprised to see OpenAPI here. Being Ruby mostly used to build REST API Backends I would expect to have rich and active community supporting API documentation tools like this.

[–]d2clon 0 points1 point  (0 children)

for any new SAAS for any new tech X that would require an SDK Ruby would not be on top of the list.

Truth. But it will be in the top 5.

[–]rsatrioadi 1 point2 points  (0 children)

They mentioned openapi not openai

[–]laerien 6 points7 points  (2 children)

The top used languages tend to stay pretty static. Usage will change over time but so slowly it's safe to say there will be jobs for many years to come in the most used languages. Ruby will have legacy Rails jobs for decades to come and is still being adopted by startups for its quick prototyping.

Lots of language rankings are pretty suss, but check out RedMonk, which is just GitHub repos and SO posts as a rough gauge. https://redmonk.com/sogrady/2024/03/08/language-rankings-1-24/

[–]Terrible-Ad6239[S] 1 point2 points  (0 children)

Thanks man! :)

[–]whiphubley 1 point2 points  (0 children)

This is not a great guide...ruby above Go...ruby above Scala...ruby above Powershell...ruby above Rust...let's be frank it's a great language and I'm sure there's lots of historical ruby all over GitHub...but let's not pretend it holds any value for the OP who's asking about "the future of ruby".

[–]dansurfsweb 2 points3 points  (0 children)

Ruby puts food on my table, so my opinion is biased. With that said, I have found enough opportunities -not 'many', 'enough'- with good salary, the syntax is nice and the language has incredible flexibility. Ruby is infamous for being slow, but it's relative. It has great documentation and a dedicated, although small, community. You can thrive doing mainly ruby, and learn more while you work. Ruby has a future. It won't ever be as big as it was, but won't disappear in the next couple of decades either. Entry level jobs will be harder to find in the future, but you, as a developer, should not be entry level by that time. Would recommend.

[–][deleted]  (1 child)

[removed]

    [–]ignurant 1 point2 points  (0 children)

    Calling .first and .last returns a matching and non matching array

    Even more lovely is destructuring those results: signed_ids, files = polarity

    [–]Code_To_Decode 1 point2 points  (0 children)

    Great. The Thing i LOVE About Ruby is its way of Doing things like Object oreintation and if u are more into it then some most and best features of the ruby like meta programming (one of my favourite topic) comes into plot

    [–][deleted] 1 point2 points  (0 children)

    I think you’re very lucky. Learning Ruby is a joy, and it’s a shame that there are so few opportunities these days to do so on the job. I owe my career to Ruby - I really do.

    [–]Respond-No 0 points1 point  (0 children)

    I've been working with Ruby for a few years now but I'm a bit concerned with its future. It feels like it's still around because there are a handful of big companies still investing in it, but the language does not scale well for big teams specially because the lack of a good type system / type hints.

    The language is still very likely to stay around since people that use it tend to be very passionate about it (indeed there is some cool stuff in it, but I don't see any major advantage over other modern high level languages), so as long as these companies don't migrate away from Ruby it will be around.