3 years ago we were breaking monoliths into microservices, now it seems that we overshot that, and I'm much more likely to see people sticking with one main monolith, and maybe one or two other services. Similarly, I'm much more likely to see people choosing NOT to use JS frameworks these days than use them.
The boosts to dev speed from a monolith / monorepo over a more "scalable" approach are huge and allow you to focus on business problems instead of self imposed tech challenges.
Even if you use sinatra or padrino instead, the wealth of the web community built around ruby still makes it rather easy.
If I were a tech lead and had to make a choice now, in 2019, I would still (probably) choose rails-api for a backend with some separate frontend.
I've been slowly working on a backend for a web app in Rust, and it's really made me realize the sheer amount of things rails provides for you. It has its problems, of course, but so does everything else.
I'm interested in why you made the choice to use Rust for a web app? It feels like you love a good challenge, but there are obviously technical constraints for some apps. I look around and wonder if the options have really changed a whole lot since 2006?
If you need productivity, choose Ruby or Python (or maybe JS.) Java and .NET exist if you have more exacting performance requirements (these platforms are somewhat more pleasant in 2019 and I see Go as joining their ranks.) Or, you choose to go really low-level with C/C++, or perhaps Rust in 2019. The latter never seemed like a viable option unless you had extreme performance concerns.
Number crunching still has to be dished off to something else like C, Rust or Go, though.
I also recently dealt with maintaining / upgrading a large, not well architected rails app. Debugging mysterious issues in Rails (and asp.net webapi2) sucks compared to Rust.
For a professional project I would largely go with rails, depending on the situation. asp.net isn't bad either.
1 - https://github.com/plataformatec/devise
turbolinks is great if you just want a faster pure web-app.
I've used both successfully independently and in tandem.
Ruby is among the slowest languages out there. Which is fine for most webapps, but calling it great for CPU intensive tasks... I don't understand what logic is being used to come to this conclusion.
Ruby has the same thing that every other language has, call outs to C code under the hood for most of the real work.
What makes Rails slow is the process around so much object creation and destruction, but this is exclusive to Rails itself.
You put a Sidekiq worker up against a Go worker for some background processing and the performance is comparable.
Yes, this is exactly the problem. Ruby is so slow that you end up writing C extensions when you want to do any non-trivial computation. The documentation is bad, the tooling is bad, the build/CI complications are bad, and there's not much community info online about the process. And now your RoR developers have to support a C library, where a segfault can kill an entire Ruby interpreter.
I don't think most RoR apps run into these problems, which is why RoR is such a great thing in the first place, but we shouldn't brush aside how slow it is, and the implications of that when it becomes a problem.
I've been doing Elixir/Phoenix lately and subjectively it feels significantly faster than Ruby/Rails.
Check out some of the comments above about "service oriented monolith".
That being said, know your limits. If you are doing a lot of image processing for instance it may be worth investing in an external service in a language that is a better fit for that problem.
I haven't seen any benchmarks or analysis that say JIT is ready for production use, but indications are strong that the next version of Ruby will include a lot of surprising things, like maybe a type system?
Ruby got a reputation for being slow very early on, and my understanding is a lot of that was due to slow code in Rails (version 2 and/or 3?). Rails is a lot better now. Ruby continues to evolve. Still, I don't know how many Ruby developers have chosen it for reasons owing to CPU-intensive work. This does seem like a stretch, even if we are beating Python in some benchmarks.
At this point, it's just as productive (perhaps even more as you don't have to glue on a bunch of additional components) and joyful to work with like RoR but massively scalable out of the box thanks to the Erlang VM.
My plea to the Rails community and Rails senior devs:
1) Fully embrace SPAs as an option, React and Vue are ubiquitous among my peers. I've seriously seen people who have difficulty understanding a for loop that know how to use react at a basic level.
2) Increase your outreach to hackathons and universities, I'd love to see more Rails companies coming out to the big hackathons and mentoring students. At the biggest hackathon in MLH (Bitcamp 2019) I couldn't find a Rails or Ember mentor. I'd also love to see more courses on coursera and other places that teach Rails, in my search for Rails courses on Coursera I only found 1 course (although Traversy media has been making some great content on youtube)!
Recently we decided to switch back to using Rails + Turbolinks + Stimulus.js and the development speed and experience have been so much better.
It's disheartening to hear so few young people are using Rails. In my 10+ years experience, I always get drawn in by the new hot thing but always end up finding my way back to Rails for the better.
SPA's just require way too much work and fine-grained detail for starter applications. I would not recommend to do full-stack node over rails if you care about iteration speed early on.
The biggest things I miss from the original setup:
1) it's easy to write integration tests when rails is nothing but an api
2) components. it's just way easier & nicer to work with than rails views/partials.
I thought rails + turbolinks + stimulus etc would be simpler in terms of code/maintainability, but I'm not so sure anymore.
Is that really what you want? That sounds like a ticket for short-term gains and long-term pains.
Python is pretty great, but the fragmentation of the ecosystem puts it behind Rails imho.
Node is a constant headache and I have seen it be the death of more than one startup. Unless you are using a typed version of JS it is going to be a problem, I can guarantee it.
Rails kinda just works. It isn't as performant as I would like, but for the overwhelming majority of web apps that isn't an issue.
I know it can be hard to find rails devs, so just make them. Hire competent CS grads and train them. If they actually earned their degree it will be easy.
If you are in an executive role at a startup building a web app and optimizing for team velocity it is always in your interests to choose an opinionated framework that has already solved the hard problems for you and imposed structure on your team.
The problem is, I think, DHH doesn't really cares about it. He made it clear that Open Source shouldn't come with responsibility to make it great or fit your needs. It is more like a gift to the rest of the world with No Strings attached.
There is also the resources and company backing problem. Python is THE languages in Data Science, Node is javascript that is everywhere, and PHP, despite many people despise it, still runs the vast majority of the web.
With Github and Shopify now actively contributing to Rails, and Stripe working on Ruby, hopefully things will be better in the future.
I almost never face type related issues, and when they occur they are the easiest to catch.
Particular example: every time you've accidentally pulled the wrong key out of a map (because that's how everyone does structs in Ruby and Python and Javascript) and gotten a null pointer exception: those were probably type related issues, and they're easily buried and discovered only in production, or through stupidly intensive unit testing, much (not all, but much) of which exists mostly to cover for (wait for it) lack of typing.
This is done using what is called "sum types" - we can tell the compiler that say a user can be "Premium" or "Regular". This distinction will affect policies across the codebase - eg. Premium customers get a discount on their shipping costs. We'll have robust unit tests and integration test that cover all these policies.
But even with the tests, we run into trouble when the feature request to create a new type of User comes in - "Semi-Premium" who gets only their _domestic_ shipping free. We now have to hunt and peck across the codebase, and change all our policies so that it handles this possibility well. Our tests are of no help here - they are meant to verify existing facts about the system, and can't tell when this user fall through certain policies because we forgot to handle it there. The type system on the other hand knows exactly the places where we decide things based on the kind of user. It will then realize that a new type of user has come in, and our policies don't handle them. This turns what usually is a high-risk and difficult task into an almost mechanical one.
What's happening here is that we're telling the compiler more things about our domain. This means the compiler can then remind us as we go about our business writing code, to handle every case, to never pass a null, and to help model our data structures that prevents inconsistent states from ever happening. The more we can encode in types, the more powerful this becomes.
Fast forward to when the same project grows and matures. Now it is huge and no one knows every subsystem. The original developers skipped town years ago. There are -1x to 10x developers on the team, and contractors who must "hit the ground running." Static typing is now crucial to prevent the whole thing from collapsing like a house of cards.
I recommend the best of both worlds, such as prototyping in a productive language, then port when the design solidifies. Or, use a language that can be gradually typed later as your startup matures into an established company with customers that rely on it.
Slides here: https://github.com/dlthomas/using-c-types-talk/tree/master/s...
The example is a toy but the technique was developed for (and very successfully used in) a production setting.
There isn't really a universal agreement on how to handle nil in the ruby community, and as long as that remains true, type issues will continue to be a daily reality of using the language.
However, any decent IDE will work with type hinting (putting types in the comments, basically), and as long as you're fastidious about using them, you can realize those same benefits.
1: There's a large ecosystem or gems to do almost anything you need for basic SaaS apps
2: We are based in Atlanta, and there aren't too many Rails developers here compared to out west. However, the language of Ruby itself is easy to learn - we have hired engineers with backgrounds in PHP, Scala, JavaScript, Python, etc.. and they were all able to pick up Rails within 30 days.
3: The framework (in general) encourages good practices. Easier to avoid terrible database schema naming and structure.
The downsides for rails which we experience is in our builds - takes a long time to run tests and precompile assets, and it hasn't been straightforward thing to solve.
I can't put my finger on it, but Django just feels intuitive to me and Rails just feels strange. Maybe it is the convention over configuration mindset which results in lots of magic, but I just can't get comfortable using Rails.
I love the idea of Rails and it's community, but I don't think it will ever be the tool for me.
And as a Django + Python lover, I feel the need to refute the idea (not just in this article) that it is mainly for academic/scientific purposes. Python is a great general purpose language which can do just about anything. It's not the best tool for every job, but for the generalist, it is wonderful. And Django is incredibly solid and can build an MVP in no time. And maybe I'm just a bad developer, but I don't see how the extra configuration necessary when using Django vs Rails is going to add up to much time at all when building your MVP. Is a couple of extra hours really going to make a difference?
Anyway, as for the academic/scientific thing. I couldn't agree more. I feel like they are just perpetuating something silly. I can guarantee you that no one in academia is using Django for research. Probably some weird transitive logic like science => numpy/pandas => python => django.
But I think this stems from the target audience of the article:
""" The only person who won’t find much use for this guide would be a high-level master Ruby on Rails developer. If you’re not on that level yet, then you’ll definitely be able to learn something! """
That is, if it's useful for everyone, it's useful for no one. The whole comparison table is unsubstantial. As interpreted languages, they are going to be roughly the same performance especially on a single thread. If anything, Ruby might be better on multi threaded due to the GIL but then this is contradicted in the table where it claims that Django is more scalable which I think is more of a comment as to how project architecture is laid out in Django with everything supposed to be a separate app.
Yes, the "magic" is a double-edged sword. I find a similar problem with Dot-Net MVC: when the "helpers" work as intended, they are great. But when they don't, troubleshooting takes way too long. (MS-MVC is more or less a clone of R-on-R.)
Its auto-matching of URL's to controllers & methods etc. (routing) is an example of this. A bunch of IF or CASE statements to do the same thing would probably be much quicker to debug, even if it's more typing up front. (Or even put the mappings into data tables for bigger apps.) One can scaffold (auto-generate) IF/CASE statements for such if needed to reduce the original build grunt-work.
All these "magic helpers" are over-complicated and opaque. Yes, I know that once one gets used them they know how to cajole them, but the learning curve is unacceptable for things that should be relatively simple. The helpers are more trouble than they are worth because they try to fit too many application types and styles, and rely on reflection, which makes following the actual helper code a pasta factory visit.
Must it be that way? I want clear and logical processing, not a bunch of organic dark-grey boxes. Maybe I'm old fashioned and relying on a bunch of dark-grey boxes glued together is the proper "new way"? #Idontgeddit
Maybe it's better for big projects or large pool of devs where you hire plug-and-play specialists who know a specific technical area well such as routing or views. But in shops with smaller staff or that divide tasks by project or entity instead of tech specialties, this doesn't make sense. But orgs feel compelled to do it that way because "everybody else is": MVC-Lemmings.
However, I got more comfortable with it and soon, for the most part, I LOVED the way everything was structured. Other frameworks just felt off.
I credit a lot of this to just understanding the internals of how Ruby works. I highly recommend the Well Grounded Rubyist. If you go through it, you'll be comfortable digging through your code, gems, etc. Things won't feel like magic and you'll be able to pinpoint how and why things are happening in your application.
Rails is one of the most productive web frameworks out there and once you know how things work, you're off to the races.
That Elixir/Phoenix combo though...
Working with RoR always made you feel being like an artist, instead of being only a software developer.
RoR is always my inspiration on how to design a software from start to finish.
I am working on a mid-size Rails app and it's a total horror show. Setting up debugger alone was very difficult (had to locate just the right patch version of a ruby gem that would work with my app); I can't just follow the calls because things are wired together behind the scenes based on names and sometimes through delayed jobs. I can't just read code and understand what it's doing I have know Rails and a myriad of other tools (react on rails and such).
So far RoR has left a fairly unpleasant taste in my mouth.
Could you link a repo that you feel represents this kinda mentality?
As far as I can tell, blocks are just some sort of hack to get around the performance overhead of using lambdas. They feel like more of a bug than a feature. Why, otherwise, would it be sane to have an ubiquitous feature that is almost a lambda, but less flexible, while also having lambdas that no one uses.
Ruby was my first programming language. I would agree that it's natural feeling, but it is the opposite of simple.
Our fascination with which language /framework is the best, most performant, whilst understandable (we are all attracted to shiny technology) misses an important point.
Engineering is all about trade offs and there are plenty of technologies that are comparable nowadays.
I think it's more a matter of picking something that makes sense for you and your team as well as the particular problem you are tackling and sticking with it than engaging in a holy war.
For example if you need great concurrency support.. perhaps you are better off with elixir if you need heavy computations.. go for python if you need safety, then perhaps look at go or rust
Rails really optimizes for developer happiness, comes with a huge ecosystem and is mature enough that can be called a boring, stable technology to build on. That being said, it certainly isn't the right choice for everything.
Disclaimer: I mainly use ruby on a day to day basis but also love elixir, python and even go.
When our Co-founder and Engineering Fellow Dmitriy Zaporozhets decided to build GitLab, he chose to do it with Ruby on Rails, despite working primarily in PHP at the time
GitLab CEO Sid Sijbrandij thinks his co-founder made a good choice:
"It's worked out really well because the Ruby on Rails ecosystem allows you to shape a lot of functionality at a high quality," he explained. "If you look at GitLab, it has an enormous amount of functionality. Software development is very complex and to help with that, we need a lot of functionality and Ruby on Rails is a way to do it. Because there's all these best practices that are on your happy path, it’s also a way to keep the code consistent when you ship something like GitLab. You're kind of guided into doing the right thing."
Not saying I dislike gitlab, I actually really like it and we use the on-prem gold edition licensed to 6k seats. (as in, I put my money where my mouth is when I say I like it)
But of the things people complain about regarding rails that's that it's: large, heavy, slow et al.
All of those points carry directly over to gitlab and are the biggest argument against using the product.
I say that having seen a ton of PHP code base that is not stellar in itself, but has the more critical parts well optimized, going through external C libraries or DB hooks on parts that really warrant it.
Rails, by default is still viewed as a Server Rendered Only Framework. Although its API Mode could be used with any front end such as Vue.js, it doesn't seems to be well known or gaining any momentum.
I am wondering if Ruby Rails will ever pick up something similar to liveView [1], instead of sprinkle of Javascript, LiveView could get rid of it. It fits the narrative of Ruby Rails, and for those that don't like it could still use it as Rails-API and some other front end.
Edit: Turns out there is something similar on Rails called Fie. [2]
[1] https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera...
Other than that I'd also go for Phoenix/Elixir, especially with LiveView being a thing now.
The whole comparison they did on this link is flawed. https://thebittheories.com/rails-vs-nodejs-the-comparison-fe...
AFAIK, from v0.12 NodeJS was always faster than Ruby runtime. Although author might be referring to some c-extension hacks which Rails framework uses.
Ruby Vs NodeJS computation benchmark: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
> Ruby is multi-threaded in its operations in contrast to NodeJS which makes it much better for CPU intensive operations.
>NodeJS is single threaded and was designed for heavy I/O bound applications and is great in this domain. BUT when it comes to heavy computing requirements, NodeJS is terrible.
OMG people still don't understand concurrency and parallelism and how to reap out maximum throughput out of CPU bound an IO bound tasks.
Literally no one out of a few hundred students was learning ruby. Go/nodejs/etherium is what people were putting their energy into.
Tribalism in tech helps no one.
Is there a good resource out there for someone who used Rails 2.x / 3 a lot years ago to get caught up to speed on what they need to know to get up and running with the new(er) versions?
I recommend it without hesitation for startups all the time.
Lots of key words all over the page.
Did anyone find anything useful? Some basic programming language advice... Is this an HN Affiliate?
