The obvious performance and bloat overhead with RoR aside, I have yet to see a framework and ecosystem that lets you have a programmable web application up and running with typical features in comparable time.
For shipping new products or testing out ideas, I have not come across a more optimal framework in terms of going from idea to market.
Most often I've tried Phoenix, Django and Laravel as alternatives, but all of them seem to fall short. I gave .NET MVC a shot too back in its early days, it was not pleasant.
I run a dev shop and it seems to fit really well with our business model.
> The obvious performance and bloat overhead with RoR aside.
Does the bloat matter in the end tho?
You can build a million dollar business on a single $20 / month DigitalOcean server to run everything with tens of thousands of users. That's what Chris did from https://gorails.com. We talked about his Rails driven tech stack on the Running in Production podcast[0].
Recently he tweeted out he generated a million dollars from his business[1].
If you can get 100ms or less p95 response times without a complicated infrastructure then the only thing that matters is the ecosystem, community and how much you enjoy using that technology. If performance is a web framework's biggest feature then I think they're fighting an uphill battle. Performance isn't that important for most applications as long as you can produce a nice feeling application that responds quickly. All modern frameworks have a means to do that. Now it comes down to how fast can you build it and how nice is it to maintain.
This is what brought me to RoR land... and this is what made me leave.
I agree rapid prototyping is an excellent point for RoR but when you need to actually evolve the project for years, it gets really tedious and hard.
So for a dev shop RoR is quite fine -- you make the project, do very little iteration on it, and ship. That works well and I've experienced it.
For longer-lived projects however, Phoenix is miles ahead. Even Rust's Rocket, but only if you are willing to invent a lot of stuff yourself (auth for example).
>The obvious performance and bloat overhead with RoR aside, I have yet to see a framework and ecosystem that lets you have a programmable web application up and running with typical features in comparable time.
This answers your question indirectly. I’ve included a link below to Amber Web Framework, built on Crystal. Crystal is a statically typed language with the speed of C and the exact same syntax as Ruby.
Check out the video a couple screens below, and you’ll see a demo of how quickly an Amber Blog App is generated. You’ll notice their is almost no difference between Rails syntax and Amber syntax.
Spring Boot Kotlin is worth giving a go. It has rapid prototyping abilities, but underlying Java promise of easy refactoring, great tooling. I recently refactored entire frontend and parts of backend code without ever having to restart server.
Looks great - but since you mention you're inspired by Sorbet, why not use their type annotations instead of rolling your own with Rubyspeed::T? (I don't know too much about C, so this might be obvious to some)
Otherwise, I'm excited to try this out. I don't really have any performance-sensitive ruby personal projects, but with time and improvements pushing this to a production-ready state this could be a lifesaver in production for computationally heavy parts of a rails codebase.
The amount of new languages and "the absolute best framework" makes me think that big enterprises should never leave Java. Fancy project written on a newest tech is legacy before it is published. Scary from the business point of view. Disclaimer: I love Ruby.
Imagine going all in on a Ruby project with this specialized library that literally changes the way you write Ruby and still thinking that's a good idea.
Keep Ruby as it is - slow and expressive. If you need to speed up, get faster hardware.
Why not try to make Ruby faster without changing how expressive it is? I don't think this project does that by the way - it breaks Ruby semantics - but let's aspire to make Ruby faster.
> If you need to speed up, get faster hardware.
If your code is still too slow for your required per-request latency on a top-of-the-range Xeon and your individual requests have no useful parallelism and are not memory or IO bound... where do you go from there? Where are you getting faster hardware from?
> ...If you need to speed up, get faster hardware.
So if I need to speed up my Rails application on a AWS, GCP or Azure instance, you're telling me in order to increase performance, I need to upgrade to hardware that is able to take at least 4 to 6+ GB of RAM, to modern hardware on each of the servers I have to make it go faster?
Not only that it will still be slow, very expensive and an unnecessary waste of money (Given the absolutely huge cloud costs), it shows that it doesn't scale efficiently to save on costs at all. Oh dear.
This is like saying, "Can you please get a new laptop with 16GB RAM to let my hungry electron apps eat the RAM it wants?, 4GB RAM is not enough and literally causes starvation."
EDIT: To downvoters: Oh so the high overhead and heavy resources of a Rails app and upgrading your instances to new hardware and more RAM requirements is justified with the extremely high cloud infrastructure costs then? Explain your reasons if this is the case.
By the way, I don't want to see your gigantic operating costs if you're running Docker & Kubernetes on a multi-instance Rails stack.
Faster hardware costs money. If this works well, and it stops being a PoC, why pay extra when you can simply add an annotation to a method, and your speed gain is free?
I'm sad Ruby has been, or is, left behind by python. There are lots of little reasons but no real big one. I just love ruby. I love little things like 'unless'. I know it's still with us, but still feels a little sad.
I don’t really think it’s so much that Ruby has declined in popularity (although Rails has), but that Python has exploded as it moved from Academia into data science and ML which are really big right now.
Ruby only ever has one big ecosystem (web development), whereas Python has expanded into several.
But Ruby isn’t going anywhere, so no need to be sad. It’s still a joyful scripting language, and its community is alive and well :)
I still think Ruby is the more interesting and expressive language. However, for me there's a single pain point that means Python wins in any larger project. That is the behaviour of Python's "import" vs. Ruby's "require". So it's not surprising that this distinction between these languages pops up all over the place. Python tries to be as explicit as possible. While "from import *" is possible it is heavily frowned upon. The Ruby culture doesn't seem to have such qualms; things are often much more hidden and magical. It can make navigating larger projects... even your own... difficult and inefficient.
While I feel sad too, I think the primary reason why it imploded under its own weight was the "magic".
I still love Ruby, for all its developer friendliness and the consistency of its idioms. But too much of that sugar leads to bloat, that requires a bunch of hair-pulling for newbies to grok.
Now of course, there exist other simpler frameworks (a la sinatra), but when your posterchild is a thing like Rails, you can't expect people to not be burnt in the long term and still come back.
Thorsten Ball's writeup [1] on the architecture behind Unicorn is one of the single most informative pieces I've ever read about fork-based multiprocessing, signals, and pipe-based ipc. The information there can be applied to any platform and, imo, is a must-read for anyone operating in a *nix environment.
Ruby is changing. I doubt it will ever be as big as the Python world, but I can see it coming back into fashion. I’ve been paying attention to the community and it’s still very active.
Rails jobs are still plentiful. I don't see what's gonna wipe them all out in the coming 10-20 years. Especially if you live in North America, Rails is still super popular.
But yes outside Rails there's mostly devops for Rubyists.
I have exact the same thing with Coffeescript. First left behind because apparently most Javascript dev's think ESx is now better than Coffee. And after that they joined the strict typing frenzy.. I hope the next front-end/node language will be a little more joyful.
im not fan of ruby but python was on its death bed and it came back to life only because of "data science" and "machine learning" since it was wasier to write it in python than in some compiled language and so it exploded since every big tech jumped on it right away and here we are. never say miracles don't happen :D
ruby has nothing to offer so it was left behind. maybe possibility to take your old code and ccompile it into C and gain massive performance will put ruby back on map, but i would not count on it. ruby was just a sillicon valley favourite pet that's no longer the case so i would not keep my hopes up for a big return.
I also love Ruby, it's all the little things. It helps me along and makes me happy every time I manage find a solution to a problem. "Woah! Can I really do it just like this?!?!"
I was intrigued by it for a while. I can remember the jokes from years ago that it should be renamed the Rails programming language. I find it a shame when an otherwise interesting language gets pigeonholed into single framework.
Those are probably not for the same use case. Crystal is a whole another language, and you'd have to migrate your whole codebase there. This (in my understanding) is more for compiling certain heavily used functions in your otherwise Ruby codebase to get a quick performance boost.
I maintain a 4 year old rails code base. I'm not going to be porting it to Crystal - but if I had an easy way to get ~5x speedup of the most performance critical parts of my code, I would jump at the opportunity. I'm glad someone is working on this
Crystal is not a Ruby. They're doing things that are intentionally different, and it's totally put me off considering it.
In practice 99% of the time plain old MRI is fast enough for the things I do. The rest of the time, resorting to RubyInline or a C-module has usually been more than enough.
E.g. the bulk of my code for my masters that involved heavy use of k-nearest neighbour implementations etc. for pre-processing image files for OCR was written in Ruby, with only ~2-3% then replaced with RubyInline C-code to get the speed needed.
I'd take that over Crystal any day, as I don't like the places where Crystal diverges.
fareesh|5 years ago
For shipping new products or testing out ideas, I have not come across a more optimal framework in terms of going from idea to market.
Most often I've tried Phoenix, Django and Laravel as alternatives, but all of them seem to fall short. I gave .NET MVC a shot too back in its early days, it was not pleasant.
I run a dev shop and it seems to fit really well with our business model.
nickjj|5 years ago
Does the bloat matter in the end tho?
You can build a million dollar business on a single $20 / month DigitalOcean server to run everything with tens of thousands of users. That's what Chris did from https://gorails.com. We talked about his Rails driven tech stack on the Running in Production podcast[0].
Recently he tweeted out he generated a million dollars from his business[1].
If you can get 100ms or less p95 response times without a complicated infrastructure then the only thing that matters is the ecosystem, community and how much you enjoy using that technology. If performance is a web framework's biggest feature then I think they're fighting an uphill battle. Performance isn't that important for most applications as long as you can produce a nice feeling application that responds quickly. All modern frameworks have a means to do that. Now it comes down to how fast can you build it and how nice is it to maintain.
[0]: https://runninginproduction.com/podcast/12-learn-ruby-on-rai...
[1]: https://twitter.com/excid3/status/1295730795148193792
joelbluminator|5 years ago
pdimitar|5 years ago
I agree rapid prototyping is an excellent point for RoR but when you need to actually evolve the project for years, it gets really tedious and hard.
So for a dev shop RoR is quite fine -- you make the project, do very little iteration on it, and ship. That works well and I've experienced it.
For longer-lived projects however, Phoenix is miles ahead. Even Rust's Rocket, but only if you are willing to invent a lot of stuff yourself (auth for example).
portpecos|5 years ago
This answers your question indirectly. I’ve included a link below to Amber Web Framework, built on Crystal. Crystal is a statically typed language with the speed of C and the exact same syntax as Ruby.
Check out the video a couple screens below, and you’ll see a demo of how quickly an Amber Blog App is generated. You’ll notice their is almost no difference between Rails syntax and Amber syntax.
https://amberframework.org/
iamsb|5 years ago
d3nj4l|5 years ago
Otherwise, I'm excited to try this out. I don't really have any performance-sensitive ruby personal projects, but with time and improvements pushing this to a production-ready state this could be a lifesaver in production for computationally heavy parts of a rails codebase.
agrafix|5 years ago
ClikeX|5 years ago
hasa|5 years ago
abhiyerra|5 years ago
jonny383|5 years ago
Keep Ruby as it is - slow and expressive. If you need to speed up, get faster hardware.
chrisseaton|5 years ago
Why not try to make Ruby faster without changing how expressive it is? I don't think this project does that by the way - it breaks Ruby semantics - but let's aspire to make Ruby faster.
> If you need to speed up, get faster hardware.
If your code is still too slow for your required per-request latency on a top-of-the-range Xeon and your individual requests have no useful parallelism and are not memory or IO bound... where do you go from there? Where are you getting faster hardware from?
Sometimes there is no faster hardware.
rvz|5 years ago
So if I need to speed up my Rails application on a AWS, GCP or Azure instance, you're telling me in order to increase performance, I need to upgrade to hardware that is able to take at least 4 to 6+ GB of RAM, to modern hardware on each of the servers I have to make it go faster?
Not only that it will still be slow, very expensive and an unnecessary waste of money (Given the absolutely huge cloud costs), it shows that it doesn't scale efficiently to save on costs at all. Oh dear.
This is like saying, "Can you please get a new laptop with 16GB RAM to let my hungry electron apps eat the RAM it wants?, 4GB RAM is not enough and literally causes starvation."
EDIT: To downvoters: Oh so the high overhead and heavy resources of a Rails app and upgrading your instances to new hardware and more RAM requirements is justified with the extremely high cloud infrastructure costs then? Explain your reasons if this is the case.
By the way, I don't want to see your gigantic operating costs if you're running Docker & Kubernetes on a multi-instance Rails stack.
dastx|5 years ago
nathancahill|5 years ago
> "a basic proof of concept"
bfieidhbrjr|5 years ago
burlesona|5 years ago
Ruby only ever has one big ecosystem (web development), whereas Python has expanded into several.
But Ruby isn’t going anywhere, so no need to be sad. It’s still a joyful scripting language, and its community is alive and well :)
hetman|5 years ago
satyanash|5 years ago
Now of course, there exist other simpler frameworks (a la sinatra), but when your posterchild is a thing like Rails, you can't expect people to not be burnt in the long term and still come back.
altdatathrow|5 years ago
[1] https://thorstenball.com/blog/2014/11/20/unicorn-unix-magic-...
eddietejeda|5 years ago
joelbluminator|5 years ago
Smoosh|5 years ago
https://crystal-lang.org/
11001001011010|5 years ago
02020202|5 years ago
ruby has nothing to offer so it was left behind. maybe possibility to take your old code and ccompile it into C and gain massive performance will put ruby back on map, but i would not count on it. ruby was just a sillicon valley favourite pet that's no longer the case so i would not keep my hopes up for a big return.
unixhero|5 years ago
non-entity|5 years ago
moonchild|5 years ago
d3nj4l|5 years ago
blodkorv|5 years ago
Am enjoying the nostalgia quite a bit :)
02020202|5 years ago
tuananh|5 years ago
pjmlp|5 years ago
m12k|5 years ago
vidarh|5 years ago
In practice 99% of the time plain old MRI is fast enough for the things I do. The rest of the time, resorting to RubyInline or a C-module has usually been more than enough.
E.g. the bulk of my code for my masters that involved heavy use of k-nearest neighbour implementations etc. for pre-processing image files for OCR was written in Ruby, with only ~2-3% then replaced with RubyInline C-code to get the speed needed.
I'd take that over Crystal any day, as I don't like the places where Crystal diverges.