Live data from Hacker News

Hard-won lessons: Five years with Node.js

blog.scottnonnenberg.com

71–80 of 365 posts

Re: Hard-won lessons: Five years with Node.js

#71

Earlier quoted context omitted.

JavaScript is a scripting language. So is Python and Ruby. As a scripting language, excluding all bindings (files, networking, etc), JavaScript is substantially faster than Ruby or Python. Now, in terms of bindings, bindings to libuv are also fast. So node is not so much of a problem in itself. However the problem is how the language is being used: To say you can write a serious library or server code because you kno…

> As a scripting language, excluding all bindings (files, networking, etc), JavaScript is substantially faster than Ruby or Python. This makes no sense. They're all dynamically typed languages (avoiding the term "scripting languages" since it's pretty vague). The only reason for the difference in speeds between these languages is due to the quality of their interpreters, not the languages themselves.

If you have embedded or extended a scripting language it makes perfect sense.

Repeating myself just for you: I was referring specifically to benchmarking language aspects excluding bindings to native code such as files, networking, processes, etc.

e.g: https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...

Then sure, JavaScript has many implementations, so does Ruby and Python. I was referring to v8 (used by node), CPython and Ruby MRI in particular.

Re: Hard-won lessons: Five years with Node.js

#72
post #15

I can't imagine choosing to write Javascript on the server, but considering its popularity I'm wondering if I'm wrong. So I'm curious as to the reasons people chose Node.js and whether you would recommend it, anybody willing to share their experiences?

For me the question isn't so much why do I choose Node.js and Javascript over other languages, it's why do I choose NPM over other module libraries. I think the ergonomics of the libraries and command line tools we use have a much bigger impact on our coding experience than the language itself.

And what I like about NPM is that there are a LOT of single file modules with a narrow, well defined scope. There are exceptions to this, like Ember or Angular, where they try to package up everything you might need. But there are also smaller frameworks like Vue.js and even smaller packages still, which do a single aspect of data binding or rendering or whatever.

And it's those granular little packages where I think the NPM community ends up exploring just about every possible way to do get something done, and often comes up with a new idea that can teach me something.

The organizational and software complexity behind an interface like Rails or iOS or Ember I think discourages app developers from questioning the interfaces they are using, and participating in shaping the landscape under them. I think that's a shame. The NPM community does it better.

Re: Hard-won lessons: Five years with Node.js

#73

Earlier quoted context omitted.

> yet I still turn to Node.js for proof of concept projects because certain things are just quicker to implement. Why? Writing Java is really very fast these days, especially with IDE's. I can get a small web site serving JSON REST requests and memcache up in ten minutes with a simple Maven/Gradle build and full IDE integration.

I can understand it. If you want to just get something together quickly then dynamic languages do have an edge. They allow you to say "just give me whatever and if it fits, it fits" and if you aren't that concerned about it breaking you can build something extremely fast.

You're just repeating the same claim without any evidence.

Why is it faster to write code in a dynamically typed language?

Most modern statically typed languages have type inference so you don't even need to write type annotations for the most part, assuming these extra characters were the reason.

So what's that mysterious reason that makes writing dynamically typed language faster?

Re: Hard-won lessons: Five years with Node.js

#74
post #19

> Verify All Assumptions When you have to worry about the environment unexpectedly reusing internal variables, when is it considered foolish to use a framework where you have to question every relationship between every concept? Just stop using it.

Yeah...I think we have to use some context clues in interpreting this particular piece of advice. Clearly, he's not suggesting you verify all assumptions as it would take millenia to verify literally all the assumptions that one makes when writing a complicated program. Personally, I interpret it as meaning he believes that the average developer's baseline calibration for how much is to be assumed is too trusting and…

'If you wish to make an apple pie from scratch, you must first invent the universe.' - Carl Sagan

Re: Hard-won lessons: Five years with Node.js

#75
post #15

I can't imagine choosing to write Javascript on the server, but considering its popularity I'm wondering if I'm wrong. So I'm curious as to the reasons people chose Node.js and whether you would recommend it, anybody willing to share their experiences?

NodeJS has a handful of things that tend to get brought up. Callback soup and difficult error handling. Both are resolved by promises. Once you get the hang of promises, you are capable of doing concurrent asynchronous tasks in a manner that would be significantly more difficult in any other language.

On top of that, NodeJS is very, very fast. Compared to Python or Ruby, straight computing is significantly faster, but that's not even where the meaningful gains come from. Because NodeJS is non-blocking, the core is IMMEDIATELY available to serve the next request once an asynchronous call is made (read from DB/Cache/HTTP call). Because of this, each core can serve thousands of simultaneous connections.

Because JS is single threaded, in order to take advantage of multi core hardware, you just run the cluster module to effectively launch a concurrent instance of your application for each core.

As far as the language itself, once I understood it, I loved it. At first, I thought it was terrible, but when I went to ES6 syntax, and fully groked how to write asynchronous code, it rocketed to my favorite language.

I started with Java, moved to Python, and although it took me a while to come around to JS, I would absolutely never go back.

Re: Hard-won lessons: Five years with Node.js

#76

Earlier quoted context omitted.

I've got over a decade of professional experience in C#, Python, and Java. I'd consider myself a Java developer before all else, yet I still turn to Node.js for proof of concept projects because certain things are just quicker to implement. Here's the major caveat, out of, say 100+ PoC/prototype projects I've ever done, I've taken two to 'production'. I put production in quotes because they were actually internal ser…

> yet I still turn to Node.js for proof of concept projects because certain things are just quicker to implement. Why? Writing Java is really very fast these days, especially with IDE's. I can get a small web site serving JSON REST requests and memcache up in ten minutes with a simple Maven/Gradle build and full IDE integration.

The edit/refresh cycle starts to slow as the project grows in Java, but node has pretty close to zero startup time and is interpreted. That plus a repl supports a much more explorative coding style where things work as fast as you can add them. No JVM restarts, compilations, or going back to change types or api's in the middle of a thought.

Re: Hard-won lessons: Five years with Node.js

#77
post #47

spent 2+ years learning js/nodejs etc I finally turned to PHP for server side, it just seems easier for me to get the job done with php, or it's just me.

Not a big fan of PHP, but it has certainly improved it's performance. Wouldn't be surprised if PHP 7.1 isn't competitive with Node.

Re: Hard-won lessons: Five years with Node.js

#78
post #39

Earlier quoted context omitted.

Yeah. I've had production experience with node. It's been the single least productive coding environment of my life. When you're taking care of large systems of backend servers, Javascript is pretty far down on the list of languages I'd pick to use. Add to that Node's explicit handling of asynchronous operations instead of just blocking and waiting. Also, it seems to get worse the more code you have. I'm sure it's po…

> Another subject the author brings up is "the ecosystem". Javascript has so many libraries that keeping up with them, their updates, and using them in a canonical way throughout a large codebase is a full-time job for at least one engineer. I love the language, but this is absolutely true.

Same, and same. It's very research-y. It is an incredible place to work if you treat your development process like research anyway, but if you just want to jam through production cycles I would pick Python or something stable.

Re: Hard-won lessons: Five years with Node.js

#79
post #15

I can't imagine choosing to write Javascript on the server, but considering its popularity I'm wondering if I'm wrong. So I'm curious as to the reasons people chose Node.js and whether you would recommend it, anybody willing to share their experiences?

I only know JavaScript (and I know it quite well). Why learn a whole other language, when Node gets the job done just fine?

Because nto everyone suffers from Stockholm syndrome?

Re: Hard-won lessons: Five years with Node.js

#80

Earlier quoted context omitted.

I can understand it. If you want to just get something together quickly then dynamic languages do have an edge. They allow you to say "just give me whatever and if it fits, it fits" and if you aren't that concerned about it breaking you can build something extremely fast.

You're just repeating the same claim without any evidence. Why is it faster to write code in a dynamically typed language? Most modern statically typed languages have type inference so you don't even need to write type annotations for the most part, assuming these extra characters were the reason. So what's that mysterious reason that makes writing dynamically typed language faster?

For example, I've been doing a lot of Rust coding.

The code in question looks like:

    iter.next().ok_or(ErrorKind::NotEnoughArguments.into())?.parse().chain_err(|| "cannot parse argument")?
the compiler responds with cannot infer type information for `_`

the solution is of course to do

   iter.next().ok_or::(ErrorKind::NotEnoughArguments.into())?.parse().chain_err(|| "cannot parse argument")?
then the type inference is decidable

in a dynamic language, you wouldn't have to worry about this; in fact, you wouldn't need to call .into() either - there's just less typing and compiler errors

Post reply on HN