Live data from Hacker News

Choosing Ruby on Rails for web development project in 2019

ideamotive.co

101–110 of 216 posts

Re: Choosing Ruby on Rails for web development project in 2019

#101

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.

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.

Re: Choosing Ruby on Rails for web development project in 2019

#102
post #3

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…

Did RoR people ever fixed their monolith inducing architecture?

Re: Choosing Ruby on Rails for web development project in 2019

#103
post #89

Earlier quoted context omitted.

How?

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

Do you have a good reference link to learn more about what you're talking about?

Re: Choosing Ruby on Rails for web development project in 2019

#104
> 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-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.

Re: Choosing Ruby on Rails for web development project in 2019

#105

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 bo…

I agree, Elixir/Phoenix is really great. One advantage Rails still carries though, is the massive Ruby ecosystem.

Re: Choosing Ruby on Rails for web development project in 2019

#106
post #3

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…

Did RoR people ever fixed their monolith inducing architecture?

Sometimes it is a feature, not bug?

Re: Choosing Ruby on Rails for web development project in 2019

#107

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 bo…

1. You can find a RoR developer.

Re: Choosing Ruby on Rails for web development project in 2019

#108

> 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 fe…

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.

Re: Choosing Ruby on Rails for web development project in 2019

#109

Earlier quoted context omitted.

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.

I agree that avoiding type-related issues are not a particularly big selling feature. I, however, like typed languages because the tooling tends to be substantially better, as tooling is much easier to build when you have type information available. Tooling makes my job a lot easier, faster, and, in my opinion, results in better code long-term. We're getting much better at building tools for dynamically-typed languag…

Yeah this was one thing I missed going from Java to ruby 10 years ago.

Re: Choosing Ruby on Rails for web development project in 2019

#110
post #26

Earlier quoted context omitted.

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 atte…

Just a disclaimer, I work with Rails every day, but I don't really like it all that much and I really don't like ActiveRecord. We have Rails legacy apps and I maintain one of them. I'd still use Rails for some things, but it I'm pretty picky about what I think it's good for. 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, bu…

I agree! SQL-avoidant developers are something we actively try to screen out in our interviews. (Being too gung-ho about using raw SQL -- something I've been accused of --is bad too, but at least it's not a path of willful ignorance)

    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)
Is SQL's syntax really that awful? I think any language that maps fairly closely to relational algebra will wind up looking similar, and a lot of frustration that we feel toward SQL's syntax is because sometimes we want to express procedural concepts in a language that is based on relational algebra.

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.

Post reply on HN