Here are 3 things why I believe the future of Ruby can be bright:

1) Lots of modern libraries are growing very fast these days
2) Modern Ruby implementations are in the works, and they show very promising improvements in performance. Especially TruffleRuby[1] and Ruby+OMR[2]
3) Rails seems to have less influence on the ecosystem these days (controversial? maybe)

1) chrisseaton.com/rubytruffle/
2) developer.ibm.com/open/2016/11

· · Web · 0 · 3 · 4

@solnic I dunno if I've ever been working on a project where the (admittedly not blazing) speed of the MRI was the thing holding it back, but I'm still excited by the performance gains presented by these alternative implementations.

Do you think there'll be a day where the MRI is no longer seen as the default, or do you think the MRI will catch up?

@jsrn most of the projects I’ve worked on suffered from poor performance, and I’m not necessarily talking about response times, but things like background jobs processing larger amounts of data that’d take way too long than it should.

Re MRI, it’s hard to tell, really. There are big plans for MRI 3.0 too, but to be honest I’m more excited about TruffleRuby than MRI these days.

@solnic you could always implement your sidekiq jobs in Crystal :)

There's a compatible crystal version of sidekiq by Mike Perham himself: github.com/mperham/sidekiq.cr

@chris inorite, but it doesn't change the fact things can be faster thanks to better tools :)

@solnic I don't think I could stop shilling Crystal if I tried :)

Truth be told, I'm looking forward to truffle ruby and ruby 3, even if my ruby is quite rusty by this point.

I'd love to see a better evented IO model in ruby like crystal or go's, not sure whether that exists already.

@chris btw do you have any experience with ruby ext written in crystal?

@solnic There's quite a few projects that allow you to write Ruby exts in Crystal but i'm not sure which are maintained or actually used, or even if there's one project that's in the lead versus the others. The only one I can find is way, way out of date.

I haven't personally written a Ruby ext in Crystal. I think a lot of people try the "microservice" approach and make their Crystal part a HTTP serive, although that has a load of disadvantages.

I'll see if I can find something

@chris I see, I’d appreciate some info about it. We have a bunch of gems written in a way that crucial parts (and bottlenecks) can be easily rewritten as exts, because those are pure functions (as in, singleton methods, that receive args, and have no side-effects).

In example transproc is used for data transformations, and it’s based on singleton methods. dry-validation uses predicates from dry-logic and they are singleton methods.

@solnic Not sure if FFI overhead would be an issue there? Worth a benchmark anyway.

I think you're stuck with github.com/phoffer/crystalized, which is out of date. The maintainer has said they're willing to work on it again if there's interest though, which sorts that problem. Maybe hit us up at gitter.im/crystal-lang/crystal for a chat?

@solnic I always liked Ruby, just didn't have enough need for it to use it regularly. Never did the rails thing though (just standard SysAdmin type stuff).

@solnic I'd add three more points:

4) Ruby's ecosystem is big and a lot of libraries have become stable
5) Rails stays a good choice for webdev (at the same time agree with your on 3, it's healthy for the community to have more successful non-Rails projects)
6) It's more fun to program in Ruby than in comparable languages (still)

@janl 6 is very subjective :) (even though I agree, and I tried other languages FWIW)

Sign in to participate in the conversation
Mastodon

The original server operated by the Mastodon gGmbH non-profit