Comment by pmontra | Hacker News Reader

Comment by pmontra | Hacker News Reader

I used Rails mostly for small or medium sized projects, one or two developers teams, all of us freelancers. It's the perfect tool for this kind of work. We can deliver quickly, send invoices, move on to something else or come back later to add features.

Do projects get complicated? Yes, some of then. Mainly because most customers pay for features and not for refactoring or design, which they don't understand (remember, no in house technical staff). Try to sell them a new page with attached the price of a major refactoring... good luck with that. So sometimes features get kludged together because of budget constraints. I have projects with suboptimal UX (understatement) because they rationally decide to make tradeoffs between usability and costs. It's their privilege. I bet this would happen with any language or framework. Your customers could be more long sighted than mines, I hope they are.

So, would I move away from Ruby and from Rails? Yes, when customers won't like starting a project with Rails anymore. This means that other tools don't have to cost them more. Do I care about Rails architectural shortcomings? A little, but I appreciate its shortcuts more. They work well in my projects.

This is my takeaway from Rails. Good default for your 1.0. Frankly, I would probably use Rails even if I was starting a startup. It's easy to hire, easy to talk about. Heck you will often find graphic designers who have played with Rails.

Choosing Rails will definitely lead to problems in the long run, but at least they are well understood problems. You're going to do an in-flight replacement of your 1.0 eventually anyway. You just need one grayhair on the team to steer the younglings away from the worst abuses and you'll have a stable, if clunky, platform to build on. It's the definition of mitigating risk.

Java and C# are of course equally boring, but I think the fact that Rails is culturally open source provides a huge benefit over them.

JavaScript, Go, Haskell, etc are arguably better if you really understand them, but they're research projects. Lots of great pieces of code, but the story of how to use them together is still being written. I would use one of them if my intention was to hire slow and keep my dev team fewer than ~30 people in the long term.

Did you just call JavaScript a research project? I seriously hope you meant Node.

Yes, I'm talking about the consensus web development framework around Node, to the extent that there is any. Same for Go and Haskell. Obviously all three are mature languages.

The Go community is just not that big into web development. There are web frameworks (eg. Revel) but they're not seeing that much traction. I truly love Go but I just don't think it's a good building material for more than a JSON API - for which it is awesome BTW.

Can't speak about the Haskell community though. To the extent I know the language I probably wouldn't want to use it to create HTML forms, either.

Haskell has a healthy and growing web ecosystem, from larger frameworks like Yesod to leaner ones like Snap, Scotty, and Spock. Servant is also looking promising as toolkit for building both API servers and clients. And GHCJS lets you write your frontend code in Haskell as well, if you so choose.

What you're missing (at least with Node.js/Javascript) is that Node does not aim to be Rails. Node doesn't aim to have one correct way of doing one thing as Rails often does. Yes, there are best practices, but Node aims to give the developer the freedom to do things as they need to.

The result of this is that, yes, development of your standard CRUD app is probably not as fast as it would be with Rails. Also, moving from project to project is not as easy as it would be with Rails. But the advantage is that, if you have good developers who are good at architecting (a big if), you architecture will better reflect the problem at hand.

No, I'm aware of that. I love Node and npm and UNIX and I use only small single purpose modules and its amazing. But I am effectively a research engineer. And honestly, if you want your company to run on Node, you need to be a research engineer too, because "which infrastructure should we use?" is an open question in the world you describe.

Compare to Rails, where you start of with OK infrastructure by default. That's not better, it just means you can hire a random person off the street and they're on the same page as you. If you want to keep a team of 50 JavaScript developers on the same page you need a really strong culture. Or just say "Use Ember and Express, end of story". But at that point you no longer have the "developer freedom" you correctly cite as the core selling point of Node.

And by "on the same page" I mean "we both have a similar understanding of a sensible default way to transport persist text fields from an HTML form". Put 10 JavaScript programmers in a room and you'll get 8 different approaches.

> Node doesn't aim to have one correct way of doing one thing as Rails often does.

Or any correct way of doing one thing, starting with the language (JavaScript) and moving on from there …

> The result of this is that, yes, development of your standard CRUD app is probably not as fast as it would be with Rails. Also, moving from project to project is not as easy as it would be with Rails. But the advantage is that, if you have good developers who are good at architecting (a big if), you architecture will better reflect the problem at hand.

And if you just want something to work quickly, Rails wins. JS encourages developers to spend days and weeks on picking each part of a framework for an MVP that may go nowhere. Rails is no longer the new shiny and it has moved into the 'get shit done' category of developer tools.

Java and C# are of course equally boring

And they're the ones who don't write medium posts daily whining about how their frameworks are the worst in the world.

It's boring, it works, it scales.

I don't know why but the Ruby on Rails community has the most drama around it. Does that start with DHH?

No. Rails just happened to be in the right time and place to attract relatively young, progressive people who tend to use social media more.

There's plenty of "drama" in many programming communities, but a lot of it is hidden, because your median Java developer is less likely to be on Twitter, Medium, or even HN.

I have seen a fair share of Java web app hate posts.

One advantage of starting with Rails is that you can progress to JRuby on Rails when scaling is required. From there you can factor out services to Clojure or Scala without rewriting everything. So I'd say Rails has much more to offer than a quick starter app.

Uh, Go is not a research project. It was written to be used, not to explore previous unexplored language features. Basically nothing in the language is new (or at least wasn't new to the creators), something that it is often criticized for.

Dropbox has stated that pretty much their entire backend is written in Go. Go is also (obviously) used in production at Google. Neither Dropbox or Google is screwing around. Once a project is run at Google or Dropbox scale, it is no longer a research project.

Go is very simple (many people say too simple) and writing a web app in it doesn't really require a very good understanding of the language. This is because very few of its more advanced features are really required for writing a normal web app. Because it isn't really a framework, it does require a good understanding of web development.

I think Haskell can be fairly described as a research project and definitely requires a good understanding.

> Go is very simple (many people say too simple) and writing a web app in it doesn't really require a very good understanding of the language.

But you do have to know to how to use the standard libraries well to write anything beyond a Hello World web app in Go.

Just because the Go language itself is simple, it does not mean web development is easy in Go. Quite the opposite, you have to write a lot of boilerplate code in Go (even with Go frameworks) to do things that would seem trivial in other frameworks.

I think what erikpukinskis means may be more that Go is still a "non-mature"/"research" ecosystem - for example, what do you use for version control of dependencies? Rails has bundler, Go has a few different approaches, none of which are the go-to thing everybody uses.

Standard Chartered is a massive multi-national bank with a £17 billion market cap and a multi-million line Haskell code base. Is that still a research project?

> Java and C# are of course equally boring, but I think the fact that Rails is culturally open source provides a huge benefit over them.

Java is culturally open source at this point; nearly every widely-used Java library is open source and there is a huge open source ecosystem around Java (namely everything maintained by the ASF, but there are plenty of other open source projects like Gson, etc.). Bonus points for tying in to any of the bazillion proprietary software systems also built in Java.

The problem with Java is that it's so damn verbose -- it can take forever to build a moderately complex system because you just have to worry about so many things (maven, spring, jetty, etc.) just for a simple web service. This means you're spending time up front solving a lot of technical problems just to get a simple web service up and running.

Rails is great because it implements a set of sensible defaults and lets you worry about product design rather than implementing yet another database backend for a user store. Its event-routing model also makes a lot more sense for the web; in Java everything is kind of a hack to link the web stuff back to the JVM. But yeah, once your project gets complex, it might as well be Java -- complex software is just complex to write. Rails kind of sucks when the "sensible defaults" don't make sense anymore because you need heavy customization. It's a great prototyping platform, and that means a lot -- but it still won't let you escape the problems caused complexity.

Do the customers know what Rails is enough to like or dislike it? Or do they like the promises of quick functionality which you translate in to lower costs?

If I may also ask, have you run in to an older rails app when someone wanted some fairly minimal additions? Have you been the "next guy?" or do you avoid those projects? Did you migrate it to a newer rails? rewrite it? Or write old rails code? I've run in to a couple of ancient apps that were running untouched for like 4 years, they want to freshen the application, maybe add some features, you have to sell them a major refactor, or you can't touch it, like they depended on some gems that were orphaned. It's not exclusive to Rails, I've seen this with node too, once the application needs to be living and breathing to stay healthy, once you put it on the shelf, it's dying. An express.js 2 to 4 migration is effectively a rewrite, it's not super terrible but it's a chunk of work that isn't adding their new features.

I've simply never heard a long term success story with rails or node when it comes to maintenance. It's maybe not a technical thing but it seems like it's the culture of both communities. Blue sky and green field code? It's a blast, fixing up or adding to someone else' existing code? I probably wouldn't touch it. Oddly, I don't feel the same way about a lot of Java stacks though.

> I've simply never heard a long term success story with rails or node when it comes to maintenance.

Basecamp, Shopify, GitHub aren't long term successes? smh...

Basecamp went through a massive rewrite, and GitHub went through a long period of (perceived) low pace innovation culminating in "Dear Github".

I don't know whether Rails maintenance issues played a part in either of those things. However I do know that YAGNI and tight coupling are traditionally things than come back to haunt you 5+ years later. Front ends may change in that time but the fundamental logic of applications, especially their data structures tends to evolve much slower. Isolating the two can only be a good thing if you're not building a throwaway project.

Everything long term is going to need serious refactoring or a rewrite at some point (or just hire exponentially more developers). I don't think it has anything to do with the language or framework.

But the ease with which you refactor or rewrite does depend on the language or the framework.

Depends if it was written well in the first place. I am maintaining a Django app, and because they have gone for "thin models fat controllers philosophy" (the opposite of Djangos best practices) it is a pain in the arse to modify stuff that should be easy.

Ok, maybe the framework doesn't have much influence, but a language with sane types will make refactoring easier. I'm not saying it will make it easy, just easier than other languages.

I try to answer all your questions.

No, those customers only know that Rails is mainstream and so it's a safe choice. If I propose Phoenix to them I bet they will look puzzled and ask me about PHP, Python, Node, Rails, maybe even Java. I'll make a test.

I've been the next guy many times. Rails makes that easy because I know where to look. The worst are custom PHP projects because I need to understand the original programmer's way of thinking. It can be a smart architecture (usually it's not) but it's time consuming and inefficient cost-wise.

I migrated every single version of Rails.

Never total rewrites, no need to do that.

I'm maintaining Rails 3, 4 and 5 beta apps right now. The customer with the 3.2 one has very little budget (we atarted and paused the upgrade to 4.2) and it's going to be EOL very soon. We'll see what happens. I was the next guy, that app started in 2011, I got it in 2012.

Orphan and incompatible gems happen. They make upgrades more difficult but I always handled them. With node it's an order of magnitude worse because of the much more rapid pace of change. It's the main reason for I would not recommend using Node.

Java just costs more to the customer. I use it only when I'm the next guy in a Java project. It's always a pain to work with it. It's like those ten lines would be one if this was Rails and I would have delivered two days ago (small new features). I just don't understand why developers want to inflict that environment to themselves.

Re: Java environment.

Because Java is a huge chunk of the job market (at least in the Sacramento area), not because it's a "language of choice" . Actually, the JVM is a nice thing, even if the Java language is primitive and verbose.

Too bad the jFoo alternate language implementations haven't got more traction yet. (jRuby, Jython, Nashorn, et al)

I can tell you why, speaking about jRuby.

Because it takes so long to start and you feel it whenever you run the tests. It gets a little better if you disable the JIT compiler and so... in dev mode, where developers spend all their life, it's not faster than RMI. Because it used to support only the syntax of older versions of Ruby. Basically devs get all the pain of the JVM and none of the gains. Guess what they want to use? A customer of mine asked me how to migrate from jRuby to MRI because devs where having problems. I explained and suggested they could try using MRI in dev and keep jRuby in production. They're a JVM shop. I'll ask them what they decided to do.

"Java" is a big world now. A java 8 app with spring boot and jooq is just as simple to work in as any other backend software. If someone is stuck on java 6, classic spring, and hibernate...I feel your pain.

I had to quickly patch a Java 8 web app weeks ago, years after I worked with Java.

Java 8 is not bad but still trailing Ruby by a long shot in terms of readability. Thinking in Ruby I wanted to implement the Java equivalent of

    input.select {|i| validations.include?(i) }.map {|i| "'#{i}'" }.join(",")

where validations is a List<String>.

I ended up with a small nightmare with streams and collectors. That boilerplate shouldn't belong to this world, probably it's there because of the Java way to static typing.

They use Spring, don't know which versions, but it's got @RequestParam annotations to extract parameters from the request body. I think this is Spring Boot. It looks like Sinatra because of the @RequestMapping. Having @RequestParam in the action arguments looks a little like Phoenix pattern matching but I didn't have time to dig into the web and understand if it can really route requests to different actions according to the RequestParam. Overall is more or less where Ruby frameworks where ten years ago unless it's got pattern matching.

The webapp I had to work on still use ctags, which are a major PIA which slows down work and raises costs.

Queries are written in SQL, which is perfectly OK, and executed on a connection returning a java.sql.ResultSet. Not shiny but everybody can understand that. I googled jOOQ and it looks like ActiveRecord/AREL for Java. Nice but it would have cost me more time for this kind of quick hack.

What's so bad about this?

  input.stream().filter(i -> validations.contains(i)).map(i -> "'" + i + "'").collect(Collectors.joining(","))

It doesn't compare with ruby for code golf, but for readability it's practically identical.

I agree. Depending on how validations is defined you could also use a method reference .filter(validations::contains).map...

Yes, one of the benefits of Rails most overlooked by it's opponents is how immensely productive it is for small to medium sized apps. This comes from not only the DRY perspective but also from having strong standard ways to do things, and quite a stable API.

I don't agree on the sentiment in the article that it's hard to follow what happens in rails/activerecord. It's pretty well documented and all the quirks are thoroughly discussed on stackoverflow. Ruby has excellent tooling and it's easy to find performance bottlenecks.

On the negative side though, I find that I use other languages when I need performance or better concurrency, but that always comes at the price of lengthier development.

> Yes, one of the benefits of Rails most overlooked by it's opponents is how immensely productive it is for small to medium sized apps.

That's the only justification anybody ever uses for choosing Rails, so I'd hardly say it's overlooked.

> Try to sell them a new page with attached the price of a major refactoring... good luck with that

Could it work to include a "technical debt" figure in your quotes (where each feature without refactoring increase the debt and the "interests" on each future invoices)? Might be useful to explain them that quick-and-dirty is not always the best solution.

Maybe, but this made me remember http://higherorderlogic.com/2010/07/bad-code-isnt-technical-...

Reply on news.ycombinator.com