Choosing Ruby on Rails for web development project in 2019(ideamotive.co) |
Choosing Ruby on Rails for web development project in 2019(ideamotive.co) |
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.
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)!
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?
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?
Anyone on HN find anything useful?
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.
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.
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...
It's true that you end up running into certain types of bugs that a strongly typed language would've caught immediately, but in java/c#/rust you end up having to hand implement more stuff depending on what you're doing.
Ideally I would use rust, but I also think Ruby can work quite well if defensive programming practices are followed, as well as running linters, static analyzers, etc. Most issues seem to stem from poor architecture or tightly coupled, dense code.
Do you find that intercooler lets you avoid using .js.erb files altogether?
You can find more experienced Ruby devs -- finding someone with multiple years of Elixir would be very difficult.
My experience with ruby devs is that they are usually employed and not actively searching. Since it isn't the flavor of the week anymore you don't have as many programmers entering the field as ruby devs.
Mentoring is always a solid option too, the language and frameworks are simple. Any CS graduate worth his degree will pick it up in no time.
> lead the development of...Our Java, Swift, and React Native-based mobile apps
> - Experience with building application backends in Ruby
> - Experience with React and Redux
> - Interest in machine learning and other next-gen technologies.
That job posting doesn't know what it wants.
I read a post like that and think "why bother when I can get paid the same for doing one of these things well somewhere else".
Offering remote would help.
Perhaps for a classic C extension that's true, but (for portability across Ruby interpreters and other reasons), using FFI is usually the preferred way to do new C interop, and none of that is true for FFI.
The trade off that Ruby has always made was maximizing developer productivity. It’s never tried to be the fastest, but it’s plenty fast enough.
In Python you can write your low level extensions directly in Rust via PyO3 [0]. I guess there is something similar for Ruby.
https://developers.redhat.com/blog/2018/03/22/ruby-3x3-perfo...
I'm just talking out loud here, not to you specifically, but things are the way they are, for good reasons. It's not a "mistake", the way the landscape is today, most technical leads are not sheep. Technical & business requirements have been mulled over time and time again by many thoughtful people, usually leading to these two platforms. A lot of us don't care about what's cool. We demand true technical innovation to adopt a new platform, not technical churn and there's an awful lot of that, if not outright downgrades.
For me, all these things matter.
-Good tooling
-Industrial-strength language design
-Backwards compatibility and support
-Breadth of domains you can target and target well (server-side, desktop, mobile)
-Availability of talent for employers
-Availability of jobs if you're an applicant
As for the hosted solutions, IMO both GitLab.com and Github.com are pretty slow. I've just recently started using non-premise solutions of both and Github slowness is really taking it's toll on my patience.
For context: Ebay, Amazon and Google (Plus, Talk) are using Java for web. None of those are what I would consider slow.
If people were condemning Java for web as being slow, and Atlassian used Java and was slow, then you could reasonably assume that the reasons are correlated.
That is the case I'm making about Gitlab and RoR.
EDIT: you're mentioning Jira Cloud being slow, but we have the on-prem version and it's also very slow.
The average salary of an entry level Ruby on Rails Dev in China is under 24K USD.
And while everything is cheap in China, for whatever strange reason their Cloud Compute Resources and Bandwidth are 2x of even Amazon in Hong Kong or Australia ( Some of the most expensive instances in AWS ).
And you get the idea why pretty no one outside of High Salaries Region, ( US, UK, Germany, France ) are using Ruby Rails. Sometimes the equation or selling point just doesn't fit.
If you were starting up a web app in China what languages would you choose?
The second I feel is by design. A runtime exception is better than undefined behavior, which was the other option when many of these more abstract languages started taking hold. We're just reaching a point where languages with undefined behavior are being competed against by projects like Rust which offer similar performance without the same risks. Runtime exceptions become less attractive when you can avoid them and avoid undefined behavior with more comprehensive solutions.
I've found that a more effective way to achieve the same results as microservices is to deploy the monolith to multiple servers and have each one acting in a specialized capacity.
This tends to make testing a lot more consistent and improves code reuse dramatically.
If you really want to make it modular you could always package the functionality you want to share into gems.
A stellar case about Object design, not strong typing. I don't find type solves this issue, in fact, it even might be the opposite. Its way looser and more flexible to be able to say how things actually behave than to define the exact type they are to see how they behave.
The static analysis is definitely a huge plus, but it's a bit tangential: if a static analysis tool were able to point to the same issues, the reason would evaporate. (It's like saying a language is better because it has a better community, which is practical but not intrinsic).
> if a static analysis tool were able to point to the same issues, the reason would evaporate.
This static analysis tool is called the type checker. The experience of using a type checker is best when the underlying language has sound types. Sorbet, TypeScript, Typed Racket etc. bolt a type system on top of an existing language, and so don't have a choice but to be unsound, and so their qualitative experience isn't as nice as it could be. Even so, they're highly recommended for large codebases.
> It's like saying a language is better because it has a better community, which is practical but not intrinsic
Not at all. This is an intrinsic feature of programming languages and has a huge effect on how we think of programs.
It is however not a silver bullet and when building web applications, practicality - tooling, ecosystem etc. trumps everything else. However if you run into difficult problems which require deep attention to data modelling, and wish for a better tool to help frame the problem, then Typed Functional Programming might be a good try.
So many of the production bugs I've encountered in my rails career (probably around 2/3rds) would immediately go away with a type system. Now, that's not to say that I won't encounter other issues, but type systems provide other benefits as well. Typescript annotations make JS seem pretty sane, and editor integrations like VSCode's support for TS is amazing. You get go-to-source functionality that isn't based on heuristics, compile-time error reporting as opposed to runtime error reporting.
Sure, it might not make sense in your situation. But every single job I've had in my career would've been much easier with a type system, and depending on how solid sorbet turns out to be, working in ruby might look quite a bit different in the next few years.
Basically, you want:
• a runtime that forces a functional/immutable programming style (because it’s so much harder to avoid errors in algorithms that operate on mutable data), and which has lots of persistent data structures to make this style efficient;
• concurrency for processing unrelated batches;
• workload isolation (where one batch-job workload crashing doesn’t bring down your whole job processor);
• runtime inspectability and tracing (because it’s hard/illegal to replicate production customer data in staging to get matching conditions)
• a solid library to transit data between a DBMS and native record types (a Record-Relational Mapper lib), with fluent syntax for advanced relational querying features;
• and, of course, a solid Rails-like backend MVC framework to stick on top, to give people an API and web app view into your system†.
So, a lot of these companies are choosing an Elixir+Phoenix stack 85% because of ERTS, 10% because of Ecto, and 5% because of Phoenix itself.
For the companies that realize that what they’re doing is Event Sourcing, the https://github.com/commanded/commanded CQRS/ES framework is also an exciting “feature” of the Elixir ecosystem.
† Sometimes this is considered a separate need—you can build the business event-processing system, in Elixir, as a custom e.g. gRPC API service; and then you can use whatever you want for the web-API/web-app service that fronts it. Sometimes these shops use Rails for the web layer! But just as likely they use Node (because they delegate the front-end layer—now free of business logic—to the front-end devs, and front-end devs know JS) or Elixir+Phoenix (if the same backend devs writing the event-processing system are tasked with writing the web layer.)
1) Elixir + Phoenix have some definite advantages when spawning asynchronous tasks (no external dependencies, it's in the language) and it runs reasonably quick.
2) Coding in Ruby on Rails is faster. An example, it's much easier to write queries in ActiveRecord than in Ecto, which is over engineered for the common needs of a web app. Queries, updates, transactions, everything are productivity killers there. For 99.9...% of the web apps it will be fast enough and the CPU will sit idle most of the time.
3) Django is as bad as Rails for concurrency and performances. The ORM is more verbose than ActiveRecord but luckily it's much closer to AR than to Ecto. The project structure is very loose compared to both Rails and Phoenix, which is bad for onboarding people coming from other Django projects ("ah, you put that there, why?")
My suggestions. If you know you're going to build a big application, scale it, etc, use Phoenix. Small to medium size: use Rails unless you're already a Python shop. In that case use Django. Smaller frameworks like Sinatra or Flask: it's not worth using them with the exception of very small applications that won't grow bigger. If they do you'll start adding components and turn them into an homegrown nightmare resembling the more polished Rails and Django.
I've found Ecto to be a productivity boon once I understood it, except for very small projects. For those, I reach for Rails just as you suggested.
My real productivity boost with Phoenix is that Elixir (or the Erlang VM, to be accurate) can take care of so many things I'd be dishing off to Redis, Sidekiq or other tools in a Rails app. That and the lack of surprises from metaprogramming or ActiveRecord default behaviors I haven't kept in mind while building.
The promise of a lean app with rails' ecosystem is too good to be true, and it is. It's so much easier to just start with rails from the beginning instead of slowly adding things piecemeal.
I still like sinatra and flask but they have one purpose: very very simple webapis, that's it. Nothing even remotely as complex as user sessions or forms.
I've been playing with Pheonix/Elixir here and there but I've never sat down and written a full app in it. I guess that's the future ultimately, at least for larger companies that need that performance.
My other strongest languages are Golang and JavaScript, so I'm used to (duck-)typed and untyped approaches, and I've never felt that Elixir was difficult to work with because of the lack of types. I've treated pattern-matching like type inference, and as long as you have guard clauses, the worst that can happen is a runtime error which you "let fail" anyway.
I guess the guard clauses are a bit of boilerplate, but I feel like these complaints have a different root. I just don't see it yet.
Ruby Rails is still the best for SaaS type of product, in the West or the East. With SaaS, your cost of scaling is proportional to your revenue. That is why you see BaseCamp, Shopify, ZenDesk, AirBnB, Github. All of them works well because the cost of framework or languages shouldn't really matter, since every user are paying you. But in a freemium model or ads based model, which is extremely popular in the East, your initial breakeven point will be a lot higher.
But it is not about the technical challenges, there are very little Ruby talent pool in China. Many Rubyist couldn't find jobs and switched to Java or Python. The phase for many Rubyist is; I love Ruby, but Ruby doesn't feed me. And precisely because Ruby Rails is more expensive to run for those in charge, they will adopt something faster like Go. ( Something like Gitea [1] came from China) Which means even less project being done on Ruby, and even less Jobs, with no demand in Jobs also mean people are not going to learn it. It is a vicious cycle.
And without a talent pool, it doesn't really matter what languages or framework you love or thinks works best.
You make it sound like an unconfirmed rumour? It's there in the release.
That's an unusual result - if it's faster for an actual app you're using in production you should report that as they'll be thrilled.
Computing power can be increased by scaling vertically or horizontally. Vertical scaling has an upper limit, and when one reaches it, in certain contexts, end of the happiness :-)
Case in point: GitLab; they have Go microservices. GitHub was also hiring Go developers, so very likely they've done the same.
Of course, few companies are GitLab/GitHub, but the point is that it's not possible to make absolute statements about power being cheap.
By being able to run your service on a single server instead of ten allows your team to focus on features instead of scaling your application using background concurrency, caching, or “micro-services”.
Imagine what you could do when you don’t need to manage a fleet of web-servers.
Conceptual compression means that you can unpack those ideas and work with them when you need them, or pack them back up and don't pay attention to them when you don't need them.
The biggest example that I can think of is ActiveRecord. I can't tell you the number of times I've seen presentations by programmers who work with other frameworks like .NET, who have embedded large, complex SQL queries into their code. They don't think twice about it, don't even flinch, parsing SQL is part of the cost of doing business in this language.
Having said that, it makes me a bit sad that there are quite a few developers who actively avoid SQL. Granted the syntax is absolutely awful, but it is a very useful and powerful language. The concepts behind relational databases are embraced by SQL in ways that I can't imagine in any other language (I'm sure there must be other good relational query languages somewhere, but I've never been exposed to them). Honestly, if I have developers working with a relational DB doing anything even a little bit complex I want them to not not think twice or even flinch to use or read it (and I say that not really being all that accomplished with the language myself).
Rails has some good niches where it is very well suited. ActiveRecord is OK if you have a very particular data model. However, as they say, if a hammer is your only tool, every problem starts to look like a nail. You may find that if you approach the problem differently, you will find reasons why people choose not to use very simplified ORMs.
Obviously you now need to add an API client layer but in terms of code organization, if your packages are cleanly separated then you've done a lot of the work already. (Transactions being the obvious piece that you'll often have to rethink when crossing a service boundary).
The advantage of this approach is that it's much easier to refactor your internal "services" when they are just packages, than it is to refactor microservices after you've extracted them and set them free (since upgrading microservice APIs requires more coordination and you can't upgrade clients and servers all in one go, as you often can inside the same codebase).
Keep all your code in one repo, deploy that codebase to multiple servers, but have it acting in different capacities.
1 email server, 5 app servers dishing out html, 2 api servers
Etc
It works very well and was able to handle spikes of traffic during super bowl ads without any problems.
A properly organized codebase scales very well when partitioned into services.
It is my default approach for all new projects for the last 10 years or so.
His talk was pretty cool and helpful if you want to split monolith!
Each visitor hits a Ruby process which renders the page directly, or serves it up from filesystem cache. I'm not honestly sure which, it could be monitoring the filesystem for changes to the markdown files, and only recompiling them when it observes a change on disk... or it could be rendering each request freshly for the visitor.
It would be hard-pressed to call this a production deployment though, I can say without a blog post or any hard data to back it up that when I did side-by-side trials, the page loading response times were marginally faster with the JIT enabled, after repeated trials.
After watching @tenderlove's talk from RailsConf 2019, I think I'm obligated to say also about this that, your results will improve if you paid attention to cache hit ratios, and consider tuning the JIT Cache size to achieve the maximum benefit. Perhaps these things will be better in a later iteration of Ruby JIT?
I don't know why it fell out of fashion, but for your average web app it is the gold standard imo.
What ActiveRecord isn't is discoverable. Which is to an extent understandable. Its domain is literally anything you could express in SQL. But you really can do anything you want with it, you just have to find the right abstraction. A tool I use a lot is to .to_sql which will show you the compiled SQL fragment in a debugging session. You can compose with bare SQL fragments and ActiveRecord even includes an intermediate library so that you can work at the relational algebra level if you want.
It's not that ActiveRecord forces you to work a certain way. It just doesn't advertise all its features.
Ryan Bigg wrote a great book about breaking away from AR in Rails called Exploding Rails[3]. It's a good read.
[0] http://sequel.jeremyevans.net/
[1] https://github.com/elixir-ecto/ecto
[2] https://rom-rb.org/5.0/learn/introduction/active-record/
found [ActiveRecord] to be severely limited in
working with complex queries which use many
JOIN statement and sub-queries
I would certainly agree that SQL > AR once your queries grow past a certain (fairly low) complexity threshold.
But, AR (wisely) doesn't try to be a complete replacement for SQL. It very happily (and even elegantly, I might say?) lets you use raw SQL pretty much any time you, the developer, feel it's more convenient/productive. That principle is pretty explicitly baked into AR.
Many ORM frameworks don't make this easy at all, whereas with AR it's very painless.
I have a lot of beef with AR but I think this is one of its strong points.
I've used sequel before and agree, it's closer to the SQL and does the job well. ROM looks excellent. I'm just reading down the page you linked, and I love every word. I can say I've had all of these problems with ActiveRecord, and ROM's answers to them all look great!
Granted [SQL's] syntax is absolutely awful, but
it is a very useful and powerful language. The
concepts behind relational databases are embraced
by SQL in ways that I can't imagine in any other
language (I'm sure there must be other good relational
query languages somewhere, but I've never been exposed
to them)
It's somewhat significant, I think, that when Microsoft came up with LINQ (sort of a language- and backend- agnostic query language) they basically settled on something that looks like SQL but puts the FROM clause first, mainly so the editor can give you typing hints.
I'm not saying LINQ was a rousing success, but that was a pretty major greenfield MS devtools initiative and they have some pretty smart language/compiler people, so it's interesting that they settled on something not too different from good ol' SQL.
My biggest issue with AR is that the arbitrary SQL cannot be combined or reused in a way which leads to compositional queries. An example would be to break up a large SQL statement into several smaller statements and then recombine them in different ways, safely.
What I found with Ecto and ROM is that, while simple to low complexity SQL was about the same as AR, maybe 10% harder to understand, complex to very complex statements were about equivalent to their SQL counterparts and could be composed together. That was a major win over AR for non-trivial queries.
You can do this, look into arel. Here's a blog post:
https://blog.codeship.com/creating-advanced-active-record-db...
As another commenter noted, yes you can do composable AR/Arel with raw SQL.... but like you said, it does get hairy pretty fast.