Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The node.js aesthetic

substack.net

Post reply on HN
Print view View original

71–80 of 81 posts

Re: The node.js aesthetic

#71

Post by masylum »

MostAwesomeDude wrote: post #34

I find the spinning in this article to be incredible . The "limited surface area" is all well and fine in JS, because there is no object inheritance in JavaScript . The author tries to emphasize usability over extensibility, which is a false dilemma in my book since it's possible to code to an interface in other languages. You define a usable interface, and then everybody codes things that fit that interface. You don…

Its not about language syntax, its about culture. You can do monolithic frameworks in nodejs if you want, but the majority of nodejs programmer (and substack is one of the better examples) just implement tiny modules with "limited surface area". This is why nodejs is great. Its not because of js (although it helps), its about people.

Re: The node.js aesthetic

#72

Post by bradleymeck »

bretthoerner wrote: post #65
bradleymeck wrote: post #64

Earlier quoted context omitted.

By giving a shared in-memory resource for the current state of an object that is not mutated from other threads during a single stack build / teardown. Concurrent access in threads requires locking the object until it is in a determinate state, while in Node you are guaranteed the state until the stack unwinds.

But this isn't unique to Node, is it? It seems like you're saying you've added a feature when you've really removed one. You can create a single threaded event loop in any language and get the same properties, no? I'd argue something like Clojure is actually providing a feature here, instead of taking something away from your toolkit. You can have a single view of an object for the life of, say, a request all while i…

Perhaps it is taking away a "feature" in some senses, but in my view it is taking the logical step not allowing concurrent access to preempt during execution. I often want the current value that has changed after the original context is changed by an asynchronous task (IP addresses of internal servers changing while a script was running came up today).

There is no way preempting access / memory contention is a feature, but Clojure avoids this with somewhat immutable state which can make keeping up to date values painful, although I may not be experienced enough to state much about Clojure.

For web services such as ours where we have values changing underneath us it is elegant that we keep a value the same through a single flow of control (until the stack unwinds). Even if it is incorrect for one part of the task as a whole, it is predictable where the values can change and dealing with errors from pointing to the wrong object / value is trivial compared to most race conditions (yes, node does those before anyone jumps in).

The environment here is key though. Node was built as a single threaded event loop. All the bindings for node / libraries for node expect this. Libgmp's love of aborting threads after a process gives it a wrong value is a good example of where the single threaded environment fights the threaded model, and the same problems of expecting threads is apparent in many programming environments (.Net Http stack I'm looking at you).

So in many ways: Node does not give you something that cannot be done in other environments; but, in other environments there is a lot of existing code that encourages thread usage. Doing something in twisted or the like proved difficult once I needed libraries that had been written expecting threads. The same is true in Node, but I can be confident that good libraries / bindings for Node provide things that expect to work in a single threaded event loop. And I like the command queue / event loop / actor based / reactive / whatever you want to call it. I like it more than anything due to the lack of concurrent edits, but allowing a lot of mutability at the same time.

Re: The node.js aesthetic

#73

Post by bretthoerner »

2mur wrote: post #67
bretthoerner wrote: post #65

Earlier quoted context omitted.

But this isn't unique to Node, is it? It seems like you're saying you've added a feature when you've really removed one. You can create a single threaded event loop in any language and get the same properties, no? I'd argue something like Clojure is actually providing a feature here, instead of taking something away from your toolkit. You can have a single view of an object for the life of, say, a request all while i…

Ah but node is really just the appearance of a single thread which is actually a v8 managed evented threadpool (or some such magic).

Only one is used for computation (afaik), the rest are used to toss I/O onto. gevent/eventlet in Python do the same, as do other languages. Nothing unique there.

Re: The node.js aesthetic

#74

Post by jemfinch »

catshirt wrote: post #41
IsaacSchlueter wrote: post #38

Earlier quoted context omitted.

JavaScript does have inheritance, and classes. Please troll using facts next time.

perhaps you guys are arguing semantics. i think it's fair to say javascript does not have traditional inheritance or classes. crockford seems to agree [0], perhaps i don't understand the argument. [0] http://javascript.crockford.com/javascript.html

"perhaps you guys are arguing semantics."

I think that's a given, since they're arguing about the semantics of a programming language.

Re: The node.js aesthetic

#75

Post by gbog »

jesusabdullah wrote: post #52
gbog wrote: post #2

Hmm, seems a bit hand-waving to me, but to be fair I have never tried Node.js and would probably have hard time convincing my finger to type javascript code for server things. Javascript always seemed to me a language that you used, and tried to use correctly, because you had to. On a server I have the choice, right? So my choice is currently Python so I read this article with some bias. In the section "batteries not…

numpy and scipy are poor examples because they're not core python modules. You still install them from separate people.

True, let's say re, math, array ?

Re: The node.js aesthetic

#76

Post by gbog »

2mur wrote: post #10
gbog wrote: post #2

Hmm, seems a bit hand-waving to me, but to be fair I have never tried Node.js and would probably have hard time convincing my finger to type javascript code for server things. Javascript always seemed to me a language that you used, and tried to use correctly, because you had to. On a server I have the choice, right? So my choice is currently Python so I read this article with some bias. In the section "batteries not…

But the point about project-local node_modules is that it is baked into the ecosystem. Directly contrast that with the reason that most people use virtualenv which is to not pollute the global python install with project-specific dependencies. It's just really well done. And javascript isn't that bad on the server when you're dealing with ES5 and not worrying about browser-specific js nightmare stuff.

I have use cases for virtualenv, but on my dev machine, to emulate a prod machine setup. But on a prod machine I will have to question hard every line in the install log, and virtualenv may not stay in.

For JS, I don't think it's only problem is with browser compatibility, it also has other flaws and need some patching before being usable, I've heard.

Re: The node.js aesthetic

#77

Post by shadowsun7 »

exogen wrote: post #70
zzzeek wrote: post #50

Earlier quoted context omitted.

> but the framework author certainly had to deal with thread safety usually not. if your framework builds off the common web integration system for the target environment, i.e. Java Servlets, WSGI in Python, etc., you're already handed a request scope within a thread. It's only web servers and containers that really have a heavy lifting job to do.

Okay. Clone the Rails repo and do this: git log --grep thread

To be fair, though, Django is not thread safe. Now while I respect Rails for taking the effort in making it thread safe (IIRC, it was a Google Summer of Code project) - it doesn't seem to be a must-have to have your framework be thread safe.

Re: The node.js aesthetic

#78

Post by donspaulding »

IsaacSchlueter wrote: post #42
moe wrote: post #23

Earlier quoted context omitted.

because node and npm are already paranoid on your behalf. Yes, until npm blows up in obscure ways. Which it likes to do frequently.

What do you mean by "blow up in obscure ways"? It generally dumps a ton of colorful errors to your terminal. If you find them obscure, please be comforted by the fact that I certainly do not find them obscure, and would love to fix whatever problem they indicate. It's actually my job. Also, npm is a software program, and not intelligent. It doesn't "like" things. To the extent that it has preferences, it loves semant…

Maybe npm loves moe, but it hates me. I had to downgrade my version of node to 0.4.12 to even get NPM to install on my Mac. The error I was seeing was identical to one that had been seen (and reported in the Github issues list) by several other people 6 weeks earlier.

Just found it. I was being bitten by https://github.com/isaacs/npm/issues/1087

The issue was seemingly marked as "Closed" on June 27th, a full 2 days before a fix was released for testing. It subsequently broke again and stayed broke for, well, I don't know, because I still haven't upgraded my node for fear that NPM would break again.

I'm confident that it's me and not you, but I think I'll stick to pip/virtualenv as my package managers of choice, thanks.

Re: The node.js aesthetic

#79

Post by scubaguy »

> Instead of the http server being an external service that we configure to run our code, it becomes just another tool in our arsenal.

This is unfair. If I create a framework cal Java.js and make it possible to create a httpserver by running server.start(8080, aCallbackObject), does that make Java great? One day someone might make node.js "configurable" via a configuration file (that is not written in JavaScript). Will having a configuration file make node.js less useful?

> Note also that the http snippet from earlier isn't inheriting from an http.Server base class or anything of the sort.

That is also unfair. You typically don't use inheritance in JavaScript because you can compose objects or clone from a prototype. There is no static analysis of classes, which in the main benefit of classical inheritance. Programming via callbacks is simply the JavaScript style. This might even change when the language provides better support for classes, or when more people write their node.js code using CoffeeScript.

> If software ecosystems are like economies then core libraries are at best government bureaucracies and at worst nationalized state corporations.

This is very subjective and I strongly disagree. There is a great advantage in using a language and framework that has a strong core library and a common way of doing thing, especially when you start building teams or start recruiting people to maintain legacy code. If anything, Node should start including more batteries, such as a module for concurrency.

PS - Here's the thing. I am really excited about the event driven nature of node.js and the community. However, I am new to node.js and I want to see quality critical analysis of its strength and weaknesses. If you are going to tell me its great, you better have pretty solid reasons. This article simply doesn't cut it.

Re: The node.js aesthetic

#80

Post by IsaacSchlueter »

moe wrote: post #63
IsaacSchlueter wrote: post #42

Earlier quoted context omitted.

What do you mean by "blow up in obscure ways"? It generally dumps a ton of colorful errors to your terminal. If you find them obscure, please be comforted by the fact that I certainly do not find them obscure, and would love to fix whatever problem they indicate. It's actually my job. Also, npm is a software program, and not intelligent. It doesn't "like" things. To the extent that it has preferences, it loves semant…

Not sure if your question is serious? Here's the obscure blowups that were filed in November alone; https://github.com/isaacs/npm/issues/1793 https://github.com/isaacs/npm/issues/1790 https://github.com/isaacs/npm/issues/1809 https://github.com/isaacs/npm/issues/1785 https://github.com/isaacs/npm/issues/1801 https://github.com/isaacs/npm/issues/1770 https://github.com/isaacs/npm/issues/1727 https://github.com/isaacs/…

Moe,

So, when you say "obscure blowup", do you mean, "someone posted any issue whatsoever"?

Several of those are feature requests, or node-core bugs, or things that have been fixed.

I find your blowup very obscure. As for npm failing for you, gist or it didn't happen.

Post reply on HN