Comment by marcuswestin | Hacker News Reader

Comment by marcuswestin | Hacker News Reader

Parent Full thread

Devil advocating:

I coded exclusively in javascript from 2006-2011. Most of that time was spent at Meebo, where we authored one of the most sophisticated JS application in existence at the time. It was great stuff!

I've worked extensively with node.js 2011-mid2013, launching multiple backends written partially and exclusively in node. Lots of fun!

On https://github.com/marcuswestin I maintain multiple widely used open source projects, much of it JS.

In the past 4 weeks I've rewritten my current product's entire nodejs backend to a statically typed language. Why? Because static type analysis allows you to develop more accurate code faster and with lower maintenance cost.

I've been a strong advocate for "javascript everywhere" for a long time. However, these days I believe that there is exactly one fantastic use case for javascript: delivering rich application experiences in web browsers.

So you may be right: perhaps this line of arguing is fading. But in that case I'm a real outlier.

(and with all that said, the most important thing to consider is this: what tool will best allow you and your team to build and maintain your intended product?)

I very much agree with this. While it's definitely fun to build apps in Node, especially when you need one really simple thing to happen with enormous capacity in terms of requests per second, I prefer to build my backend in Rails and frontend in Ember.js, because I feel JavaScript is best used as a frontend language, and Rails is really great at making RESTful APIs as well as encapsulating business logic far away from the JS frontend app. I much prefer writing Ruby rather than JavaScript, but I appreciate JS and know it well enough to do a good job.

And rails is particularly better/easier to implement a backend in than NodeJS + crudify/restify/express, or any number of other tools?

I've not used anything that allows for as easy modularity as node+npm lend themselves to... just because it's JS doesn't mean it's spaghetti that has blurry code sharing between the client and server.. it's not all meteor, even if that does have a lot to offer.

> Because static type analysis allows you to develop more accurate code faster and with lower maintenance cost.

This statement may be true for you, but it's not for everyone.

It's a dangerous argument because it assumes that static types are going to somehow magically turn bad code into good code, or (by extension) bad coders into good ones.

Static typing is a not a solution to the problem of any deficiencies in the language, but rather the problem of people shooting themselves in the foot with it. It's admittedly a related problem, but a separate one.

I also said:

> (and with all that said, the most important thing to consider is this: what tool will best allow you and your team to build and maintain your intended product?)

I'd defend the statement you quoted like this: all languages are type. Dynamic languages simply have exactly one expression type, "any". Specifying multiple types affords you strictly beneficial abilities. Static type checks is probably the most significant. Performance improvements and highly specific and accurate code editing assistance (e.g auto suggest) can also be significant.

But yes, you're absolutely right. Nothing but sincere effort, lots of practice, and critical thinking can make you a better programmer.

At the same time, a great carpenter becomes even so much better with a properly weighted hammer and an accurate lever.

:)

In what language are you rewriting the backend?

Bet it's Java.

So what is the other static language? I see go programs on your github account also Objective C.

Go

Reply on news.ycombinator.com