Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Choosing Ruby on Rails for web development project in 2019

ideamotive.co

Post reply on HN
Print view View original

91–100 of 216 posts

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

#91

Post by derefr »

davidkuhta wrote: post #59
derefr wrote: post #40

Earlier quoted context omitted.

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.

Out of curiosity, as a non-fintech Elixir/Phoenix dev, what particular facets of Elixir/Phoenix are fintech startups finding attractive/useful?

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 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.)

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

#92

Post by save_ferris »

conanbatt wrote: post #50
oftenwrong wrote: post #14

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/

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.

Type-related issues are super common in rails apps with several contributors. Do you ever get "undefined method foo for nil:NilClass"? That's a type error.

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.

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

#93

Post by collyw »

conanbatt wrote: post #74
kiernanmcgowan wrote: post #54

Earlier quoted context omitted.

Agreed - its just interesting to see the next generation of talent completely ignoring a major platform in current tech industry.

To be fair, Java/python people probably said the same things to the upcoming rails people at some point.

Perl was more popular then and to be honest most people were impressed at how quickly you could build something.

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

#94

Post by tptacek »

conanbatt wrote: post #50
oftenwrong wrote: post #14

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/

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 used to think that, as a C programmer used to passing void-stars around bristling against C++ in 2001 (which, to be fair, was not a good language. I continued to think it through a years of writing Python and Ruby. Then I picked up Go, which I thought I would hate due to typing, and: the opposite thing happened.

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.

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

#95

Post by madlynormal »

llamataboot wrote: post #45

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. Si…

Similar experience at the company I work for, though we're mostly using Angular for FE.

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

#96

Post by Dangeranger »

bjz_ wrote: post #86
AlchemistCamp wrote: post #75

Earlier quoted context omitted.

Or if you want productivity and a performant web server, try Elixir + Phoenix. Number crunching still has to be dished off to something else like C, Rust or Go, though.

The lack of a type system in Elixir is a productivity killer though :(

You can annotate your types if you want and get a lot of editor benefits. Also, I don’t buy the “we need strong types for everything” argument, as optional typing in Clojure, JavaScript, and now Ruby gives you lots of benefits without having to think all the way through the app’s architecture.

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

#97

Post by randomdata »

conanbatt wrote: post #50
oftenwrong wrote: post #14

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/

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 languages, but there is still a gap.

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

#98

Post by Dangeranger »

pizza234 wrote: post #83
faizshah wrote: post #17

Earlier quoted context omitted.

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.

It's not so easy. 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 abs…

Agreed. Yet even if you don’t reach Gitlab scale, languages like Go and Elixir can help you deliver the same service at 10-20% the cost.

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.

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

#99

Post by theflyinghorse »

revskill wrote: post #5

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.

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.

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

#100

Post by cpursley »

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.

Post reply on HN