Hacker News Reader

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.

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

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.

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.

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?