18 ms·

Choosing Ruby on Rails for web development project in 2019

194 points by milo_im 7y ago

milo_im 7y ago
Fun story from Gitlab: 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."
- dijit 7y ago
  And yet, when I think of gitlab I think of the insane resources it consumes and the slowness of the system even when you overprovision by a factor of 2 on cpu. 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.
  - abhiyerra 7y ago
    I believe github onprem gets around the speed by using jruby? I’m sure that could be done with GitLab as well.
    - xenorplxx 7y ago
      I just realized I've never actually seen on-prem Github. GitLab on the other side is everywhere, especially thanks to the Community Edition. I've never seen really big deployments, but for instances with 100-200 people on board there was never any problem (and DevOps guys sit right next to me, so I would probably hear something). 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.
      - milo_im 7y ago
        Guys, JIRA cloud is terribly slooow...
        dijit 7y ago
        Sure, but that's an indictment of Atlassian products, not of Java for web. 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.
    - ericb 7y ago
      I have my doubts. From my experience, JRuby is generally slower. Source: used it in production at a billion dollar company, benchmarked it personally on individual items, contacted core devs when it was slower for advice.
  - hrktb 7y ago
    Ruby allows optimisations in C for critical parts. In that sense I'd pin gitlab issues less on the language or framework, and more on a lack of resource to cover the weaker points. 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.
- dcosson 7y ago
  Is the CEO really the best person to ask about such in the weeds details of the codebase, like how the choice of web framework is working out? The CTO seems like a much better choice but even they might be too far removed, I’d rather hear from a sampling of engineers and tech leads that are actually coding and solving technical problems in the app every day.
  - xenorplxx 7y ago
    Well - you can visit their blog or even go to GitLab's repos and see the discussion there :). https://about.gitlab.com/blog/ https://about.gitlab.com/blog/
munmaek 7y ago
The beauty of rails is how simple and quick it is to get a robust (if bare) application up and running. 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.
- duncan-donuts 7y ago
  I lead the work of node APIs but have always worked on convincing people Lumen/Laravel/Rails would be a good choice because of the ecosystem and opinions. Even in the node/express world it’s insane how much rails does for you over express.
- zerkten 7y ago
  > I've been slowly working on a backend for a web app in Rust 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.
  - faizshah 7y ago
    Or if you need both, Yehuda Katz's company Tilde made a library that can help you write code in Rust and use it in Ruby. So if there's a critical path in Rails that you need to speed up in Rust you can do that: https://www.youtube.com/watch?v=lBapt5YDDvg https://www.youtube.com/watch?v=lBapt5YDDvg https://github.com/tildeio/helix https://github.com/tildeio/helix
  - 7y ago
deleted 7y ago
[deleted]
revskill 7y ago
Ruby code is like poetry. Rails code is like a song. 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.
- theflyinghorse 7y ago
  Perhaps I am an odd duck (I come from heavy Java backend experience including Spring and struts and now Go) but Rails feels incredibly clunky. 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.
  - asark 7y ago
    Having spent a lot of time on legacy Rails codebases that need new features and fixes, existing ones coming in from clients, and so on, I'd consider it practically write-only as soon as eyeballs are off it for a couple months or a handoff happens. Heroic testing practices that I rarely see in the wild could save it from that fate, but little else. Ruby's got some great libraries available but there's too much magic and "wtf is this even?" going on in your average Rails codebase. Sinatra with Sequel over it any day if it's my choice and the product's intended to have any kind of lifespan, and we're using Ruby.
- uurrnn 7y ago
  I have barely any experience with Ruby or Rails, but I'm interested in your similies. Could you link a repo that you feel represents this kinda mentality?
sbov 7y ago
> Great for CPU-intensive tasks. 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.
- lkostrowski 7y ago
  I think it's only in comparision to php, python etc.
  - yebyen 7y ago
    Ruby 3x3 is a thing (make Ruby 3.0, 3x faster), and Ruby 2.6 is said to include an optional JIT compilation mode. 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.
    - faizshah 7y ago
      I was listening to a recent interview with DHH and he makes a great point that Rails and Ruby are about optimizing for developer happiness and dev speed. Computing power keeps becoming cheaper and ruby keeps getting faster but developer's salaries continue to be the number one cost for software companies.
      - yebyen 7y ago
        100% agree. Developer happiness, conceptual compression is another important concept that DHH likes to talk about. If there's a hard topic that devs need to understand sometimes, Rails makes it a point to guarantee that devs don't need to understand all those things all the time. 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.
throwayEngineer 7y ago
This looks like an SEO grab. Lots of key words all over the page. Did anyone find anything useful? Some basic programming language advice... Is this an HN Affiliate?
- zerkten 7y ago
  For consulting companies who have to educate their customer base on why they should go with Rails this is a well put together microsite.
  - throwayEngineer 7y ago
    So, this is exactly an SEO grab. Anyone on HN find anything useful?
    - diveanon 7y ago
      A bunch of active rails developers.
k2xl 7y ago
I run engineering at Calendly - We are on Rails and it's been great for us for multiple reasons. 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.
- criddell 7y ago
  Is there a particular course or tutorial that you recommend to your new hires that don't have Ruby or Rails experience?
oftenwrong 7y ago
Rails is ideal for the "Get Shit Done" approach to development. However, Ruby's type system does not provide many assurances, making mature codebases harder to maintain, refactor, and extend (as compared to codebases in, say, well-written Java). I am surprised this was not listed as one of the criticisms. Sorbet, a type checker for Ruby, stands to make this criticism less valid: https://sorbet.org/ https://sorbet.org/
- conanbatt 7y ago
  I have to be honest, I don't understand why people care so much about typed languages. I almost never face type related issues, and when they occur they are the easiest to catch.
  - oblio 7y ago
    Safe refactoring + fewer runtime exceptions.
    - chessturk 7y ago
      The first point is definitely a positive point for typing. 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.
  - Karunamon 7y ago
    Ease of refactoring is the big one, especially with an IDE since you'll catch a lot of problems as you write. 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.
  - quest88 7y ago
justaaron 7y ago
maybe consider https://amberframework.org/ https://amberframework.org/ it's fast. type-safe, and imitates scaffolding and other rails features...
- realusername 7y ago
  I've contributed a bit to Amber but it's just not there yet unfortunately. The Crystal ecosystem is still a bit too small for my taste.
kadabra9 7y ago
I used to do a lot of work in Rails in around 2012-2014. Around 2015 or so I sort of pivoted out of web development and more into data engineering, so I took a bit of a hiatus from making side projects/web apps. When I revisited Rails years later, it seemed like so much had changed with all of the new versions and updates that it seemed like overkill, I just shrugged and ended up using Sinatra instead. 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?
- faizshah 7y ago
  I've been using Hartl's Ruby on Rails Tutorial and Agile Web Development with Rails 5 by Sam Ruby. I had much less experience with Rails 3 than you so you might find it redundant but those have been the two best for me.
- xenorplxx 7y ago
  You can definitely check out https://github.blog/2018-09-28-upgrading-github-from-rails-3-2-to-5-2/ https://github.blog/2018-09-28-upgrading-github-from-rails-3... and other stories of big Rails upgrade to get a grasp of what has changed. As for new features, I'd just go with googling what's new in Rails 4/5.
  - xenorplxx 7y ago
    Oh, I've just noticed there's similar blog post on GitLab's blog now: https://about.gitlab.com/2019/05/28/upgrade-to-rails5/ https://about.gitlab.com/2019/05/28/upgrade-to-rails5/
throwaway_x13zd 7y ago
Devise[1] alone makes it worth using rails for many webapps. Throw in things like simple form[2] and will paginate[3] and it's incredible how much you can get done cleanly and quickly. Using something like intercooler.js, you can build a solid modern web app in a fraction of the complexity of most systems today. 1 - https://github.com/plataformatec/devise https://github.com/plataformatec/devise 2 - https://github.com/plataformatec/simple_form https://github.com/plataformatec/simple_form 3 - https://github.com/mislav/will_paginate https://github.com/mislav/will_paginate
- fouc 7y ago
  intercooler over turbolinks? or together? not quite sure what intercooler really brings
  - throwaway_x13zd 7y ago
    intercooler just gives you finer grained control over your ajax requests, which makes it easier to implement stuff like active search, etc. turbolinks is great if you just want a faster pure web-app. I've used both successfully independently and in tandem.
    - fouc 7y ago
      That's interesting! I do some ajax with the js.erb files, but I honestly find that it's pretty messy & gross. Maybe I could eliminate those .js.erb files with intercooler.js (or clean them up). Do you find that intercooler lets you avoid using .js.erb files altogether?
jrgifford 7y ago
Can anyone else find a source about Etsy being based on Rails? I thought they were primarily a PHP/Node shop.
- cwt137 7y ago
  You wont because they are a PHP shop https://codeascraft.com/?s=php https://codeascraft.com/?s=php
faizshah 7y ago
Among my peers (undergrads in college) Rails has largely lost mindshare to python and Node (and even PHP!). At the 3 hackathons I went to this semester I could not find a single other person who knew Rails (so I always have to switch to node or python). If you take a look at devpost, Rails is increasingly losing popularity: https://devpost.com/software/built-with/ruby-on-rails https://devpost.com/software/built-with/ruby-on-rails 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)!
- dschadd 7y ago
  To play devil's advocate, I am a junior dev in a relatively large US market and Rails is still very popular. I'm currently using it as the backend API for my side project. It's just simple and fun to code in.
- derefr 7y ago
  I’m surprised it’s Python/Node taking that mindshare. From my perspective (fintech industry), it looked like 100% of the decreasing usage of Rails by other fintech startups have been due to choosing Elixir’s Phoenix framework instead.
  - davidkuhta 7y ago
    Out of curiosity, as a non-fintech Elixir/Phoenix dev, what particular facets of Elixir/Phoenix are fintech startups finding attractive/useful?
    - derefr 7y ago
      A lot of finance is built on event sourcing (without calling it that), in that you can’t just overwrite your existing DB state with new state; everything has to be a ledger with a history, and you have to be able to trace the “provenance” of your data—what version of your business rules were used to compute any derived results, both so that those results (and results derived further from them) can be recomputed when you update your logic; and so you that you can use the version of the business rules appropriate to a given dataset (e.g. the tax laws appropriate for the year a given invoice was generated) when auditing that dataset, or when migrating that dataset to a new storage format. 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 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.)
jaegerpicker 7y ago
I think I'd only ever choose RoR for a throwaway project, in 2019. I do love RoR and the development experience but Elixir and Phoenix give me almost exactly the same feeling but with WAY better performance and an Immutable/Functional language that results in much cleaner and better code. It's an investment to learn Elixir but it's 100% worth it and honestly I'd choose Phoenix over Rails almost every time.
- mercer 7y ago
  I suppose I could see myself picking Rails if 1) I need particular functionality that is well-served through a gem that doesn't have an equivalent Elixir package, or 2) I need others to work with me and there's a pool of Rails devs available. Other than that I'd also go for Phoenix/Elixir, especially with LiveView being a thing now.
- csolorio 7y ago
  What is your IDE setup? I like elixir, but it seems that IDE support isn't where I'm used to in other languages. Specifically module auto imports/aliasing. Not a big gripe, but I haven't found an IDE I like as much as Rubymine for Elixir.
  - jaegerpicker 7y ago
    We mainly use VS Code with the ESElixir plugin but I've had great luck with Intellij Idea and the Elixir plugin also.
  - arthurcolle 7y ago
    Have you tried this plugin out? https://github.com/KronicDeth/intellij-elixir https://github.com/KronicDeth/intellij-elixir
kiernanmcgowan 7y ago
I had the opportunity to run some hackatons / startup coaching last year with some CS student at University of Wisconsin- Madison. I spoke in front of some large lectures and asked students what languages they were learning. Literally no one out of a few hundred students was learning ruby. Go/nodejs/etherium is what people were putting their energy into.
- conanbatt 7y ago
  Yeah, rails does look out of style. But node backend development is unpleasant (at least compared to rails).
  - kiernanmcgowan 7y ago
    Agreed - its just interesting to see the next generation of talent completely ignoring a major platform in current tech industry.
    - mtberatwork 7y ago
      I suppose they will be in for a bit of a shock when they try to make their way into the workforce to find out that the majority of enterprise-land is using Java or .Net and a bit of python mixed in.
      - BuckRogers 7y ago
        They shouldn't be surprised, if they're fully informed on the technical and business merits of every platform available. I wouldn't build a business on anything except CoreCLR or Hotspot. C# or Kotlin for me. 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
llamataboot 7y ago
Ruby/Rails backend with a React FE seems to be pretty popular these days, and is where I spend most of my time, but honestly I'd rather go back to Rails views with Stimulus for some of the components that need it. 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.
- mipmap04 7y ago
  I've taken the approach of building the monolith first with an architecture that allows me to easily pull parts of it out into services when I hit constraints and need that scalability.
  - 87zuhjkas 7y ago
    How?
    - shijie 7y ago
      Elixir and Phoenix. The contexts pattern used in Phoenix is the most modular, easily microserviced way of structuring apps I’ve ever used. I slapped myself on the forehead when I first saw it. Duh. It’s really fantastic. Highly recommend
      - bschwindHN 7y ago
        Do you have a good reference link to learn more about what you're talking about?
        pdimitar 7y ago
        Official source: https://hexdocs.pm/phoenix/contexts.html https://hexdocs.pm/phoenix/contexts.html A video: https://elixircasts.io/phoenix-contexts https://elixircasts.io/phoenix-contexts
cargoshipit 7y ago
Frameworks like Rails/Django are still an extremely viable way to go; even just for an API. I've seen so many cases of early microservices adoption when something like RoR would have saved them a ton of headache. If you need that kind of scale then great, but it's more likely that "you ain't gonna need it".
agounaris 7y ago
I stopped reading at "Python, the language used in Django, is a language very commonly used for academic purposes, whereas the Ruby community — thanks to Rails — is more business-oriented."...
- brndn 7y ago
  It's okay to read articles that you don't completely agree with.
mmartinson 7y ago
> What is special about Ruby? Blocks 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.
- save_ferris 7y ago
  I don't really understand your argument here, blocks and lambdas are both procs. A block is just a special proc that can't be assigned to a variable. There's nothing less flexible about a block as opposed to a lambda, they both utilize the same functionality.
cpursley 7y ago
I love Ruby/Rails and owe my career to it, but I don't see the advantage of choosing this stack in 2019 over Elixir/Phoenix for greenfield projects. Elixir tooling and libraries are now up to par and I'd argue have surpassed RoR. 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.
- WillPostForFood 7y ago
  I agree, Elixir/Phoenix is really great. One advantage Rails still carries though, is the massive Ruby ecosystem.
- LanceH 7y ago
  1. You can find a RoR developer.
  - deleted 7y ago
    [deleted]
  - zukzuk 7y ago
    Or not! Here in Toronto we've had a req open for a senior Ruby dev since like last October. We're seriously debating switching over to something else for no reason other than lack of available Ruby talent. Relatively view new devs are picking up Ruby nowadays. Job posting is here if anyone's interested --> https://angel.co/company/akira-2/jobs/106786-sr-full-stack-ruby-engineer https://angel.co/company/akira-2/jobs/106786-sr-full-stack-r...
    - deleted 7y ago
      [deleted]
    - wolco 7y ago
      A switch to PHP/Laravel would net you more candidates. Offering remote would help.
    - 7y ago
truth_seeker 7y ago
> Rails is for CPU intensive operations WHILE NodeJS is for IO intensive operations. The whole comparison they did on this link is flawed. https://thebittheories.com/rails-vs-nodejs-the-comparison-feba9081251f 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/faster/node-yarv.html 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.
dinkleberg 7y ago
Whenever I read about Rails it makes me want to try it again and "understand" it this time... But it always ends up feeling wrong, and I go back to old reliable Django. 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?
- hervature 7y ago
  Mostly interested in commenting on your last paragraph. But I think your first point of Django being more intuitive is probably due to your (I'm assuming here) background of growing with Django through time. As someone who has developed in both, I find that Django is basically RoR version (n-1). People claim that Django is too complex for them over Flask. I say it just takes time to learn all the features. 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.
ksec 7y ago
Rails doesn't scale, or more accurately described as Rails does not scale easily or cheaply. A lot of people doing consultation may have heard their client ask if they should switch to something else because Rails does not X, or Y or Z. ( Normally the standard reply is But GitHub and Shopify is using Rails as well, which should settle the argument ) 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-interactive-real-time-apps-no-need-to-write-javascript https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera... [2] https://fie.eranpeer.co https://fie.eranpeer.co
- diveanon 7y ago
  I am curious about your definition of scale, because in my experience this is just flat out untrue.
  - ksec 7y ago
    It just basically meant it uses more hardware resources than Go or JSP. Which is a problem in places like China, when the Scale is 10x of anywhere else, Salary is 5x lower, and Computer Resources are 2x - 3x more expensive.
    - diveanon 7y ago
      Fair enough, I was thinking in terms of SV salaries and western compute resources.
      - ksec 7y ago
        A few more Data Point, The total online population in China is more than online population of US, Canada and Whole of EU combined. And while US, Canada and EU are separated by 10+ time zone, China is in one time zone, the peak traffic of anything that gets small traction in China is likely to be 10x if not a lot higher. 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.
swat535 7y ago
Threads like these are really interesting to me. 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.
diveanon 7y ago
I don't really enjoy writing Ruby, but rails is the most productive framework I've ever had the pleasure of working with. I recommend it without hesitation for startups all the time.

194 points by milo_im 7y ago

Fun story from Gitlab: 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."

dijit 7y ago
And yet, when I think of gitlab I think of the insane resources it consumes and the slowness of the system even when you overprovision by a factor of 2 on cpu. 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.
- abhiyerra 7y ago
  I believe github onprem gets around the speed by using jruby? I’m sure that could be done with GitLab as well.
  - xenorplxx 7y ago
    I just realized I've never actually seen on-prem Github. GitLab on the other side is everywhere, especially thanks to the Community Edition. I've never seen really big deployments, but for instances with 100-200 people on board there was never any problem (and DevOps guys sit right next to me, so I would probably hear something). 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.
    - milo_im 7y ago
      Guys, JIRA cloud is terribly slooow...
      - dijit 7y ago
        Sure, but that's an indictment of Atlassian products, not of Java for web. 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.
  - ericb 7y ago
    I have my doubts. From my experience, JRuby is generally slower. Source: used it in production at a billion dollar company, benchmarked it personally on individual items, contacted core devs when it was slower for advice.
- hrktb 7y ago
  Ruby allows optimisations in C for critical parts. In that sense I'd pin gitlab issues less on the language or framework, and more on a lack of resource to cover the weaker points. 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.
dcosson 7y ago
Is the CEO really the best person to ask about such in the weeds details of the codebase, like how the choice of web framework is working out? The CTO seems like a much better choice but even they might be too far removed, I’d rather hear from a sampling of engineers and tech leads that are actually coding and solving technical problems in the app every day.
- xenorplxx 7y ago
  Well - you can visit their blog or even go to GitLab's repos and see the discussion there :). https://about.gitlab.com/blog/ https://about.gitlab.com/blog/

munmaek 7y ago

The beauty of rails is how simple and quick it is to get a robust (if bare) application up and running. 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.

duncan-donuts 7y ago
I lead the work of node APIs but have always worked on convincing people Lumen/Laravel/Rails would be a good choice because of the ecosystem and opinions. Even in the node/express world it’s insane how much rails does for you over express.
zerkten 7y ago
> I've been slowly working on a backend for a web app in Rust 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.
- faizshah 7y ago
  Or if you need both, Yehuda Katz's company Tilde made a library that can help you write code in Rust and use it in Ruby. So if there's a critical path in Rails that you need to speed up in Rust you can do that: https://www.youtube.com/watch?v=lBapt5YDDvg https://www.youtube.com/watch?v=lBapt5YDDvg https://github.com/tildeio/helix https://github.com/tildeio/helix
- 7y ago

deleted 7y ago

[deleted]

revskill 7y ago

Ruby code is like poetry. Rails code is like a song. 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.

theflyinghorse 7y ago
Perhaps I am an odd duck (I come from heavy Java backend experience including Spring and struts and now Go) but Rails feels incredibly clunky. 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.
- asark 7y ago
  Having spent a lot of time on legacy Rails codebases that need new features and fixes, existing ones coming in from clients, and so on, I'd consider it practically write-only as soon as eyeballs are off it for a couple months or a handoff happens. Heroic testing practices that I rarely see in the wild could save it from that fate, but little else. Ruby's got some great libraries available but there's too much magic and "wtf is this even?" going on in your average Rails codebase. Sinatra with Sequel over it any day if it's my choice and the product's intended to have any kind of lifespan, and we're using Ruby.
uurrnn 7y ago
I have barely any experience with Ruby or Rails, but I'm interested in your similies. Could you link a repo that you feel represents this kinda mentality?

sbov 7y ago

> Great for CPU-intensive tasks. 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.

lkostrowski 7y ago
I think it's only in comparision to php, python etc.
- yebyen 7y ago
  Ruby 3x3 is a thing (make Ruby 3.0, 3x faster), and Ruby 2.6 is said to include an optional JIT compilation mode. 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.
  - faizshah 7y ago
    I was listening to a recent interview with DHH and he makes a great point that Rails and Ruby are about optimizing for developer happiness and dev speed. Computing power keeps becoming cheaper and ruby keeps getting faster but developer's salaries continue to be the number one cost for software companies.
    - yebyen 7y ago
      100% agree. Developer happiness, conceptual compression is another important concept that DHH likes to talk about. If there's a hard topic that devs need to understand sometimes, Rails makes it a point to guarantee that devs don't need to understand all those things all the time. 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.

throwayEngineer 7y ago

This looks like an SEO grab. Lots of key words all over the page. Did anyone find anything useful? Some basic programming language advice... Is this an HN Affiliate?

zerkten 7y ago
For consulting companies who have to educate their customer base on why they should go with Rails this is a well put together microsite.
- throwayEngineer 7y ago
  So, this is exactly an SEO grab. Anyone on HN find anything useful?
  - diveanon 7y ago
    A bunch of active rails developers.

k2xl 7y ago

I run engineering at Calendly - We are on Rails and it's been great for us for multiple reasons. 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.

criddell 7y ago
Is there a particular course or tutorial that you recommend to your new hires that don't have Ruby or Rails experience?

oftenwrong 7y ago

Rails is ideal for the "Get Shit Done" approach to development. However, Ruby's type system does not provide many assurances, making mature codebases harder to maintain, refactor, and extend (as compared to codebases in, say, well-written Java). I am surprised this was not listed as one of the criticisms. Sorbet, a type checker for Ruby, stands to make this criticism less valid: https://sorbet.org/ https://sorbet.org/

conanbatt 7y ago
I have to be honest, I don't understand why people care so much about typed languages. I almost never face type related issues, and when they occur they are the easiest to catch.
- oblio 7y ago
  Safe refactoring + fewer runtime exceptions.
  - chessturk 7y ago
    The first point is definitely a positive point for typing. 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.
- Karunamon 7y ago
  Ease of refactoring is the big one, especially with an IDE since you'll catch a lot of problems as you write. 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.
- quest88 7y ago

justaaron 7y ago

maybe consider https://amberframework.org/ https://amberframework.org/ it's fast. type-safe, and imitates scaffolding and other rails features...

realusername 7y ago
I've contributed a bit to Amber but it's just not there yet unfortunately. The Crystal ecosystem is still a bit too small for my taste.

kadabra9 7y ago

I used to do a lot of work in Rails in around 2012-2014. Around 2015 or so I sort of pivoted out of web development and more into data engineering, so I took a bit of a hiatus from making side projects/web apps. When I revisited Rails years later, it seemed like so much had changed with all of the new versions and updates that it seemed like overkill, I just shrugged and ended up using Sinatra instead. 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?

faizshah 7y ago
I've been using Hartl's Ruby on Rails Tutorial and Agile Web Development with Rails 5 by Sam Ruby. I had much less experience with Rails 3 than you so you might find it redundant but those have been the two best for me.
xenorplxx 7y ago
You can definitely check out https://github.blog/2018-09-28-upgrading-github-from-rails-3-2-to-5-2/ https://github.blog/2018-09-28-upgrading-github-from-rails-3... and other stories of big Rails upgrade to get a grasp of what has changed. As for new features, I'd just go with googling what's new in Rails 4/5.
- xenorplxx 7y ago
  Oh, I've just noticed there's similar blog post on GitLab's blog now: https://about.gitlab.com/2019/05/28/upgrade-to-rails5/ https://about.gitlab.com/2019/05/28/upgrade-to-rails5/

throwaway_x13zd 7y ago

Devise[1] alone makes it worth using rails for many webapps. Throw in things like simple form[2] and will paginate[3] and it's incredible how much you can get done cleanly and quickly. Using something like intercooler.js, you can build a solid modern web app in a fraction of the complexity of most systems today. 1 - https://github.com/plataformatec/devise https://github.com/plataformatec/devise 2 - https://github.com/plataformatec/simple_form https://github.com/plataformatec/simple_form 3 - https://github.com/mislav/will_paginate https://github.com/mislav/will_paginate

fouc 7y ago
intercooler over turbolinks? or together? not quite sure what intercooler really brings
- throwaway_x13zd 7y ago
  intercooler just gives you finer grained control over your ajax requests, which makes it easier to implement stuff like active search, etc. turbolinks is great if you just want a faster pure web-app. I've used both successfully independently and in tandem.
  - fouc 7y ago
    That's interesting! I do some ajax with the js.erb files, but I honestly find that it's pretty messy & gross. Maybe I could eliminate those .js.erb files with intercooler.js (or clean them up). Do you find that intercooler lets you avoid using .js.erb files altogether?

jrgifford 7y ago

Can anyone else find a source about Etsy being based on Rails? I thought they were primarily a PHP/Node shop.

cwt137 7y ago
You wont because they are a PHP shop https://codeascraft.com/?s=php https://codeascraft.com/?s=php

faizshah 7y ago

Among my peers (undergrads in college) Rails has largely lost mindshare to python and Node (and even PHP!). At the 3 hackathons I went to this semester I could not find a single other person who knew Rails (so I always have to switch to node or python). If you take a look at devpost, Rails is increasingly losing popularity: https://devpost.com/software/built-with/ruby-on-rails https://devpost.com/software/built-with/ruby-on-rails 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)!

dschadd 7y ago
To play devil's advocate, I am a junior dev in a relatively large US market and Rails is still very popular. I'm currently using it as the backend API for my side project. It's just simple and fun to code in.
derefr 7y ago
I’m surprised it’s Python/Node taking that mindshare. From my perspective (fintech industry), it looked like 100% of the decreasing usage of Rails by other fintech startups have been due to choosing Elixir’s Phoenix framework instead.
- davidkuhta 7y ago
  Out of curiosity, as a non-fintech Elixir/Phoenix dev, what particular facets of Elixir/Phoenix are fintech startups finding attractive/useful?
  - derefr 7y ago
    A lot of finance is built on event sourcing (without calling it that), in that you can’t just overwrite your existing DB state with new state; everything has to be a ledger with a history, and you have to be able to trace the “provenance” of your data—what version of your business rules were used to compute any derived results, both so that those results (and results derived further from them) can be recomputed when you update your logic; and so you that you can use the version of the business rules appropriate to a given dataset (e.g. the tax laws appropriate for the year a given invoice was generated) when auditing that dataset, or when migrating that dataset to a new storage format. 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 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.)

jaegerpicker 7y ago

I think I'd only ever choose RoR for a throwaway project, in 2019. I do love RoR and the development experience but Elixir and Phoenix give me almost exactly the same feeling but with WAY better performance and an Immutable/Functional language that results in much cleaner and better code. It's an investment to learn Elixir but it's 100% worth it and honestly I'd choose Phoenix over Rails almost every time.

mercer 7y ago
I suppose I could see myself picking Rails if 1) I need particular functionality that is well-served through a gem that doesn't have an equivalent Elixir package, or 2) I need others to work with me and there's a pool of Rails devs available. Other than that I'd also go for Phoenix/Elixir, especially with LiveView being a thing now.
csolorio 7y ago
What is your IDE setup? I like elixir, but it seems that IDE support isn't where I'm used to in other languages. Specifically module auto imports/aliasing. Not a big gripe, but I haven't found an IDE I like as much as Rubymine for Elixir.
- jaegerpicker 7y ago
  We mainly use VS Code with the ESElixir plugin but I've had great luck with Intellij Idea and the Elixir plugin also.
- arthurcolle 7y ago
  Have you tried this plugin out? https://github.com/KronicDeth/intellij-elixir https://github.com/KronicDeth/intellij-elixir

kiernanmcgowan 7y ago

I had the opportunity to run some hackatons / startup coaching last year with some CS student at University of Wisconsin- Madison. I spoke in front of some large lectures and asked students what languages they were learning. Literally no one out of a few hundred students was learning ruby. Go/nodejs/etherium is what people were putting their energy into.

conanbatt 7y ago
Yeah, rails does look out of style. But node backend development is unpleasant (at least compared to rails).
- kiernanmcgowan 7y ago
  Agreed - its just interesting to see the next generation of talent completely ignoring a major platform in current tech industry.
  - mtberatwork 7y ago
    I suppose they will be in for a bit of a shock when they try to make their way into the workforce to find out that the majority of enterprise-land is using Java or .Net and a bit of python mixed in.
    - BuckRogers 7y ago
      They shouldn't be surprised, if they're fully informed on the technical and business merits of every platform available. I wouldn't build a business on anything except CoreCLR or Hotspot. C# or Kotlin for me. 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

llamataboot 7y ago

Ruby/Rails backend with a React FE seems to be pretty popular these days, and is where I spend most of my time, but honestly I'd rather go back to Rails views with Stimulus for some of the components that need it. 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.

mipmap04 7y ago
I've taken the approach of building the monolith first with an architecture that allows me to easily pull parts of it out into services when I hit constraints and need that scalability.
- 87zuhjkas 7y ago
  How?
  - shijie 7y ago
    Elixir and Phoenix. The contexts pattern used in Phoenix is the most modular, easily microserviced way of structuring apps I’ve ever used. I slapped myself on the forehead when I first saw it. Duh. It’s really fantastic. Highly recommend
    - bschwindHN 7y ago
      Do you have a good reference link to learn more about what you're talking about?
      - pdimitar 7y ago
        Official source: https://hexdocs.pm/phoenix/contexts.html https://hexdocs.pm/phoenix/contexts.html A video: https://elixircasts.io/phoenix-contexts https://elixircasts.io/phoenix-contexts

cargoshipit 7y ago

Frameworks like Rails/Django are still an extremely viable way to go; even just for an API. I've seen so many cases of early microservices adoption when something like RoR would have saved them a ton of headache. If you need that kind of scale then great, but it's more likely that "you ain't gonna need it".

agounaris 7y ago

I stopped reading at "Python, the language used in Django, is a language very commonly used for academic purposes, whereas the Ruby community — thanks to Rails — is more business-oriented."...

brndn 7y ago
It's okay to read articles that you don't completely agree with.

mmartinson 7y ago

> What is special about Ruby? Blocks 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.

save_ferris 7y ago
I don't really understand your argument here, blocks and lambdas are both procs. A block is just a special proc that can't be assigned to a variable. There's nothing less flexible about a block as opposed to a lambda, they both utilize the same functionality.

cpursley 7y ago

I love Ruby/Rails and owe my career to it, but I don't see the advantage of choosing this stack in 2019 over Elixir/Phoenix for greenfield projects. Elixir tooling and libraries are now up to par and I'd argue have surpassed RoR. 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.

WillPostForFood 7y ago
I agree, Elixir/Phoenix is really great. One advantage Rails still carries though, is the massive Ruby ecosystem.
LanceH 7y ago
1. You can find a RoR developer.
- deleted 7y ago
  [deleted]
- zukzuk 7y ago
  Or not! Here in Toronto we've had a req open for a senior Ruby dev since like last October. We're seriously debating switching over to something else for no reason other than lack of available Ruby talent. Relatively view new devs are picking up Ruby nowadays. Job posting is here if anyone's interested --> https://angel.co/company/akira-2/jobs/106786-sr-full-stack-ruby-engineer https://angel.co/company/akira-2/jobs/106786-sr-full-stack-r...
  - deleted 7y ago
    [deleted]
  - wolco 7y ago
    A switch to PHP/Laravel would net you more candidates. Offering remote would help.
  - 7y ago

truth_seeker 7y ago

> Rails is for CPU intensive operations WHILE NodeJS is for IO intensive operations. The whole comparison they did on this link is flawed. https://thebittheories.com/rails-vs-nodejs-the-comparison-feba9081251f 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/faster/node-yarv.html 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.

dinkleberg 7y ago

Whenever I read about Rails it makes me want to try it again and "understand" it this time... But it always ends up feeling wrong, and I go back to old reliable Django. 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?

hervature 7y ago
Mostly interested in commenting on your last paragraph. But I think your first point of Django being more intuitive is probably due to your (I'm assuming here) background of growing with Django through time. As someone who has developed in both, I find that Django is basically RoR version (n-1). People claim that Django is too complex for them over Flask. I say it just takes time to learn all the features. 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.

ksec 7y ago

Rails doesn't scale, or more accurately described as Rails does not scale easily or cheaply. A lot of people doing consultation may have heard their client ask if they should switch to something else because Rails does not X, or Y or Z. ( Normally the standard reply is But GitHub and Shopify is using Rails as well, which should settle the argument ) 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-interactive-real-time-apps-no-need-to-write-javascript https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera... [2] https://fie.eranpeer.co https://fie.eranpeer.co

diveanon 7y ago
I am curious about your definition of scale, because in my experience this is just flat out untrue.
- ksec 7y ago
  It just basically meant it uses more hardware resources than Go or JSP. Which is a problem in places like China, when the Scale is 10x of anywhere else, Salary is 5x lower, and Computer Resources are 2x - 3x more expensive.
  - diveanon 7y ago
    Fair enough, I was thinking in terms of SV salaries and western compute resources.
    - ksec 7y ago
      A few more Data Point, The total online population in China is more than online population of US, Canada and Whole of EU combined. And while US, Canada and EU are separated by 10+ time zone, China is in one time zone, the peak traffic of anything that gets small traction in China is likely to be 10x if not a lot higher. 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.

swat535 7y ago

Threads like these are really interesting to me. 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.

diveanon 7y ago

I don't really enjoy writing Ruby, but rails is the most productive framework I've ever had the pleasure of working with. I recommend it without hesitation for startups all the time.