Hacker News Reader

Comment by archgeek | Hacker News Reader

Maybe Golang is great for developing frameworks, but as someone who build websites i prefer Node because Go's typing makes development slower and more expensive.

View on HN

Dynamic typing was very cool when I started out with Node, too. It lets you get things wired up very quickly and come up with a very functional app with almost no friction. But in my experience, once the app reaches a point where I no longer remember every single line of code that was written in it, I start to miss what a type system could tell you.

Hmm, do I pass a string in the first parameter, or was it the second? What does that funciton return? Am I really getting a number in this parameter? Of course, you can get around that confusion by adding more unit tests and parameter validation but with strong typing I'd get all that for free.

The question to your answer of what that funciton [0] returns, it's lots and lots of boxes.

[0]: http://esolangs.org/wiki/Funciton

Maybe try Typescript, it has optional typing and is compatible with normal Javascript. It really solves those problems you mention and will give you compile errors if you send parameters of the wrong type to functions.

While I don't disagree with you that that's inconvenient and totally solved by strongly typed languages (I love having my arguments filled in when writing a function call in Go), this usually isn't a big deal in literally any of the production Node systems I've worked on (some of which are particularly complex).

At my shop, we emphasize making obvious (if somewhat verbose at times) names for functions, so that it's pretty easy to intuit what arguments it takes. Also a naked function (e.g. "foo(bar)") will always be defined in the same (<100 line) file, so it's not hard to find it, or in a module (which is a Cmd+P away).

All this to say, while I agree with you that strong type systems mostly eliminate this pain, it's not exactly "painful" in Javascript either.

I totally see your point. I think what's tripping me up is that I'm new to node/JavaScript and coming from a strongly typed world, I'm still writing my apps with that framework in mind. Working with dynamically typed code requires you to think about your application differently and I'm just starting to understand the patterns.

I understand that. There certainly is a learning curve, and I don't pretend that all the Node stuff I've written since day 0 has been awesome - I've churned out my fair share of nasty, unmaintainable garbage because I abused the freedom that Javascript gave me.

One tip: rubber ducking is really valuable. If it takes more than ~30 seconds to explain whats going on in ~10 lines of code, then you probably should do some abstracting.

I actually prefer stronger typing and Typescript solves that for me for Javascript+Node.js

The bigger reason I see for sticking with Node.js for web development is being able to use Javascript for both server and client code.

Newer Javascript frameworks and templating libraries such as dust.js, Ractive.js, React.js can render both on server side and client side so on the initial requst the server can send a fully rendered page for SEO and performance, and then client side Javascript can dynamically update the page using the same code/templates.

"development slower and more expensive"

really means

"I am ready to trade speed of development for having more bugs"

I used to feel similarly about most static type systems, but Go's feels unusually light and I rarely feel encumbered by it.

I still found it more awkward to do things like access JSON in Go.

Can't you just unmarshal into interface{}?

You can, but the properties need to be string pointers, not strings (this one stumped me for hours).

Reply on news.ycombinator.com