Live data from Hacker News

Why I believe Rails is still relevant in 2019

devbrett.com

251–260 of 264 posts

Re: Why I believe Rails is still relevant in 2019

#251
post #170
post #77

Why are people saying stupid things like this? I'm doing rails 24/7 for the past 5 years in MANY different projects and I can say its the BEST and very relevant in 2019. I have to deal with other platforms written in different languages/frameworks like php/laravel and I can only pity developers that have to do that by choice.

I very much prefer Laravel/PHP to Rails/Ruby and I'm mostly working with Rails nowadays.

PHP even has static types now. I think Ruby is missing out by not supporting static types. Python has it as well, and there are a couple different type systems for JavaScript- TypeScript being the most popular.

I’m not saying all languages and projects need static types- but there are several great examples of scripting languages that have successfully added optional support for static types. After working on several large projects with Ruby, type-less Python, and JavaScript - I have a major appreciation for static types. I’m also a fan of compilers. Anyways, that’s my two cents on Ruby these days. I think it’s a cool language and has a neat ecosystem- but I think it could get a huge boost from static types.

Re: Why I believe Rails is still relevant in 2019

#252
My personal love for Rails is recent. I had been trying in my one to two hours of spare time on weekends (I am busy with exercise/family/gaming/etc) to build a simple website for my wife's company (simple crud stuff mostly). I found that several ways I had attempted to build the site were time consuming to learn/compile/test/demo/repeat. Even though I program for a living, starting from scratch takes time and one/two hours per weekend is almost nothing when it comes to getting stuff done. When the PC I was using for building kicked the bucket and I got an old Macbook air, I tried Rails and within an hour I had got most of the base moved from Spring Boot to Rails. I can't complain about Rails. The time investment to usable results are there. I think Rails is going to relevant like other web frameworks for a good long time.

Re: Why I believe Rails is still relevant in 2019

#253
post #234

Earlier quoted context omitted.

I know what an async worker and what sidekiq is. But apparently you don't know that in modern stacks you don't need this anymore and it was an oddity because of RoR. I am on mobile and don't have time to write down why, please just go to StackOverflow and ask people why something like Sidekiq is not needed in stack x.

What stack would you recommend if not rails? Serious question with no malice

I'm currently working in the JVM and find myself wishing I had Sidekiq. Learn at least two stacks to some degree so you can contrast and know what you are missing when you inevitably have to learn a third and a fourth and a fifth.

Re: Why I believe Rails is still relevant in 2019

#254
post #30

Build your app using whatever you're most comfortable with because in the end an existing product is better than no product. Will you enjoy spending an extra hour per day working with this framework over another? That's an hour more of progress. Personally I think Spring Boot with Kotlin is a way better choice today for monoliths that transition well to micro services. But if you're already deep in the RoR world just…

I'll second the thought on Kotlin, and in fact I just trained a diverse team of PHP, RoR, and Python developers on Kotlin with Spring Boot, and our platform migration project to Kotlin massively reduced our LoC and increased each engineers understanding of the platform. We broke off a couple pieces into microservices which need to scale independently, and it was a great experience. I'm hoping Kotlin continues to grow…

Kotlin is indeed great, but there's gotta be something better than Spring Boot out there...

Re: Why I believe Rails is still relevant in 2019

#255
post #218

Earlier quoted context omitted.

Adding a services directory with logic moved out from my models into POROs helped a lot for taming the mess.

Can you share a link about what you mean by this? I went searching but came up pretty empty ... do you literally mean adding an "app/services" directory, is that all? Where you put classes related to external dependencies that aren't ActiveRecord?

I don't agree with the pattern discussed here and actually like smart models (I want to tell my model "do the thing", not write and babysit a bureaucratic coordinator service. But, since you asked, it's common in other frameworks like Spring to have a "service" layer that sits between your controller and model layers. The service layer has the logic, and the models are just storage.

Re: Why I believe Rails is still relevant in 2019

#256

I work on a Rails system. It's fine. Just like everything else is fine. I have problems, but I have problems with everything else too (sometimes different problems, but not always...). I think my main complaint about Rails is that it's pretty heavy weight. Lately we did a Sinatra app because we didn't really need anything that rails was giving us. Fairly quickly I realised that I didn't need anything that Sinatra was…

Having worked with many different languages and frameworks over the years, I have to disagree: when creating web applications, starting from scratch or from a minimal base is massively slower, more error prone and less safe than starting from a well developed and maintained framework, where so many of the things you're going to need have already been solved and battle tested.

It certainly can be. It doesn't have to be thought. It really depends a lot on your team. I've worked on teams where building large scale, but minimal, well tested systems was their bread and butter. I've also worked on teams where hooking up existing frameworks was what they were comfortable with and any footstep taken outside of that activity was marked with considerable rancour. Not invented here syndrome is also a real thing and sometimes people sit there building "game engines" instead of "games" ;-) On the other hand "Invented here" syndrome is also a real thing and sometimes people completely panic when faced with the thought of writing something novel. You need to go with your team.

I think it was Alan Kay who summed it up best: If your team is capable of building a compiler, you must build a compiler. If your team is not capable of building a compiler, you must not build a compiler. That matches my experience exactly ;-)

Re: Why I believe Rails is still relevant in 2019

#257
post #218

Earlier quoted context omitted.

Can you share a link about what you mean by this? I went searching but came up pretty empty ... do you literally mean adding an "app/services" directory, is that all? Where you put classes related to external dependencies that aren't ActiveRecord?

I don't agree with the pattern discussed here and actually like smart models (I want to tell my model "do the thing", not write and babysit a bureaucratic coordinator service. But, since you asked, it's common in other frameworks like Spring to have a "service" layer that sits between your controller and model layers. The service layer has the logic, and the models are just storage.

Don't you mind having 5000+ LOC model? Methods being redefined because the class is huge and the developer didn't notice the existing method?

Re: Why I believe Rails is still relevant in 2019

#258
post #127

Earlier quoted context omitted.

I use Grails which is very similar to Rails and a lot easier and productive than Spring Boot. Good defaults makes application building a much smoother experience. Grails is still Spring Boot, and you can still code like it was a pure Spring Boot application. Grails has its own ORM called GORM, which can use several different backends like Hibernate/MongoDB Groovy is a great language, with the best from dynamic langua…

I've had some not-so-great experiences developing web services with Spring Boot, Hibernate, Groovy itself, Grails. We now stick to plain old Java with no annotations, Ratpack, jOOQ, etc. In my experience, and opinion: Lack of static typing is a good way to make shooting yourself in the foot easy. Annotation-driven magic sucks. Just Writing Queries causes fewer headaches than using an ORM. Basically, libraries over fr…

I do understand why you feel like that, I've been there too. No framework is a silver bullet, but over time you will see the value in them.

One thing though, with Groovy you can choose between dynamic and static typing. These days everyone agrees that you should use static typing with Groovy as much as possible. Use dynamic typing when static typing becomes hard, for example when working with JSON objects.

And Hibernate is really flexible with how close you get can native queries, the documentation however is not convenient there. But Hibernate developers like Vlad Mihalcea is working hard to document how you can do this and is writing blog posts and answering questions on Stack Overflow. I am really grateful for the effort he puts in helping everyone.

Re: Why I believe Rails is still relevant in 2019

#259
post #218

Earlier quoted context omitted.

Can you share a link about what you mean by this? I went searching but came up pretty empty ... do you literally mean adding an "app/services" directory, is that all? Where you put classes related to external dependencies that aren't ActiveRecord?

I don't agree with the pattern discussed here and actually like smart models (I want to tell my model "do the thing", not write and babysit a bureaucratic coordinator service. But, since you asked, it's common in other frameworks like Spring to have a "service" layer that sits between your controller and model layers. The service layer has the logic, and the models are just storage.

That's common in Rails too. Except I don't think it's necessary to make it a go-between.

Where controllers have simple interactions with models (which represent database structures, and may have logic in them) you let the controller have direct access to the model.

Models can grow to be too complex, this is where having a concept of named "Concerns" can come in handy, even if you won't use them in another model, it can lift some complexity out of your model and put it into a logical group.

Services, in my view, are akin to models. Some of them may use models behind the scenes. More of them actually represent an external service, which might be an external database that lives behind a web service, an API. Or it might be an LDAP service. (Or it might be a command pattern)

I agree with smart models, if the complexity does belong to the model, then why not let it live there. It sounds like the service layer you're describing is a needless ceremony for "managing complexity" – I'll bet it was a concept that was introduced to your group by an architect.

Re: Why I believe Rails is still relevant in 2019

#260
post #110

Earlier quoted context omitted.

True as far as it goes, but does Rails offer a compelling advantage over higher-performance languages these days, even when starting out? Modern compiled languages have closed the expressiveness gap with Ruby a lot in the last decade or two. E.g. I find I'm just as productive in Scala as in Ruby - if anything more so - so I'd sooner work in Scala/Wicket from day 1 (for use cases where server-side rendering makes sens…

That's quite hard to measure, how do you measure expressiveness? Or easiness to grasp and get into? Take a CS graduate and have them build an app either with Rails or with Scala, in which stack will they be more productive? That to me will say a lot about a stack's productivity - because quality of documentation, community, stackoverflow questions, 3rd party libraries, general framework architecture etc etc etc..all…

> That's quite hard to measure, how do you measure expressiveness?

How much code it takes to express a given idea. I was just talking about my subjective impressions, but I'm sure one could count lines of code.

> That to me will say a lot about a stack's productivity - because quality of documentation, community, stackoverflow questions, 3rd party libraries, general framework architecture etc etc etc..all those things are crucial for productivity.

Depends on what kind of organisation you're in; in the kind of environment I'm working in, how easy it is to get up and running for a quick prototype has surprisingly little to do with longer-term productivity. To the extent that you're actually doing novel programming work, how familiar the syntax is and how available libraries are is actually much less important than how clearly you can think about the problem you're actually solving, and I'd far rather be using a cleaner language with fewer frameworks available. Of course in other cases you're doing things that can mostly be solved by frameworks (indeed that's the original idea behind Rails - it started out as a tool to make stamping out repetitive crud apps easier, and it's very good at that) and in that case the availability of those frameworks is the higher priority.

Post reply on HN