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

61–70 of 81 posts

Re: The node.js aesthetic

#61

Post by [deleted] »

MostAwesomeDude wrote: post #60
substack wrote: post #39

Earlier quoted context omitted.

> Let's go ahead and compare with Twisted, shall we? Oh goodness, yes. How about an echo server. This one is from the twisted home page, so I am not knocking down a strawman. from twisted.internet import protocol, reactor class Echo(protocol.Protocol): def dataReceived(self, data): self.transport.write(data) class EchoFactory(protocol.Factory): def buildProtocol(self, addr): return Echo() reactor.listenTCP(1234, Echo…

The reactor is explicit. "Explicit is better than implicit." You don't have to always be in the reactor, if you don't want to. It lets people use Twisted to build GUIs and other things, without always being in the reactor's context. Twisted is a general-purpose networking library, not a tiny-web-servers-only networking library. An example used to illustrate and educate does not necessarily result in the shortest code…

[deleted]

Re: The node.js aesthetic

#62

Post by jesusabdullah »

MostAwesomeDude wrote: post #60
substack wrote: post #39

Earlier quoted context omitted.

> Let's go ahead and compare with Twisted, shall we? Oh goodness, yes. How about an echo server. This one is from the twisted home page, so I am not knocking down a strawman. from twisted.internet import protocol, reactor class Echo(protocol.Protocol): def dataReceived(self, data): self.transport.write(data) class EchoFactory(protocol.Factory): def buildProtocol(self, addr): return Echo() reactor.listenTCP(1234, Echo…

The reactor is explicit. "Explicit is better than implicit." You don't have to always be in the reactor, if you don't want to. It lets people use Twisted to build GUIs and other things, without always being in the reactor's context. Twisted is a general-purpose networking library, not a tiny-web-servers-only networking library. An example used to illustrate and educate does not necessarily result in the shortest code…

> I was gonna type out an IRC bot, the favorite exercise of novice coders, but I felt that would be petty, since there's no IRC library included in Node.

[There's a library for that](https://github.com/martynsmith/node-irc). You should use this; It would not be considered petty.

Re: The node.js aesthetic

#63

Post by moe »

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…

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/npm/issues/1654

Re: The node.js aesthetic

#64

Post by bradleymeck »

bretthoerner wrote: post #58
bradleymeck wrote: post #35

Earlier quoted context omitted.

When working with requests that share resources via web frameworks that deal with threads, the large consensus is to put the resource into an external managed resource. This external resource such as a database will manage the locking for you to prevent write conflicts, however, when caching values for complex interaction beyond CRUD you may have update conflicts where a new request has an in memory copy of an outdat…

Wait, how does Node solve this where others don't?

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.

Re: The node.js aesthetic

#65

Post by bretthoerner »

bradleymeck wrote: post #64
bretthoerner wrote: post #58

Earlier quoted context omitted.

Wait, how does Node solve this where others don't?

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 its root binding is actually being mutated by other threads. You won't "see" the new value until you deref the root binding on the next request. Except nobody stole threads from you and sent you a bill.

Re: The node.js aesthetic

#66

Post by exogen »

zzzeek wrote: post #29
russell_h wrote: post #24

Earlier quoted context omitted.

I think what he is getting at is that if you want to handle multiple requests within the same process (in order to have in-process shared state, so you can make your chat server without external dependencies or whatever), you either need an event loop, threads, or both. If you have threads, you do have to worry about mutexes and reentrance.

none of that has anything to do with writing web-request-handling code, it has to do with writing custom servers. There are plenty of asynchronous solutions for writing servers, including the very widely used Twisted platform as well as the Erlang programming language. It's a tad annoying that node.js is touted largely by front end developers as solving a supposedly previously unaddressed problem. to wit: > emerging…

Did you even read the line you quoted? He didn't say "emerging set of software capabilities." The programming conventions, philosophies, and values of the Node.js community are evolving. Your response doesn't make any sense.

Re: The node.js aesthetic

#67

Post by 2mur »

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…

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

Re: The node.js aesthetic

#68

Post by 2mur »

phamilton wrote: post #12

Could someone clarify something for me? Is http.createServer robust enough for production? It is my understanding that running it as is in production is not a good idea. You want to at least configure nginx between node and the world. If that's the case, doesn't that undermine the whole "focus on your application, not the configuration" point he's making? Sure you can call startServer multiple times, but then you wou…

The one catch with nginx is that it doesn't support http 1.1 (ie. websocket support). So if you want that you have to reverse proxy with something that does like haproxy or node-http-proxy.

Re: The node.js aesthetic

#69

Post by htilford »

MostAwesomeDude wrote: post #60
substack wrote: post #39

Earlier quoted context omitted.

> Let's go ahead and compare with Twisted, shall we? Oh goodness, yes. How about an echo server. This one is from the twisted home page, so I am not knocking down a strawman. from twisted.internet import protocol, reactor class Echo(protocol.Protocol): def dataReceived(self, data): self.transport.write(data) class EchoFactory(protocol.Factory): def buildProtocol(self, addr): return Echo() reactor.listenTCP(1234, Echo…

The reactor is explicit. "Explicit is better than implicit." You don't have to always be in the reactor, if you don't want to. It lets people use Twisted to build GUIs and other things, without always being in the reactor's context. Twisted is a general-purpose networking library, not a tiny-web-servers-only networking library. An example used to illustrate and educate does not necessarily result in the shortest code…

> tiny-web-servers-only networking library

really?

Re: The node.js aesthetic

#70

Post by exogen »

zzzeek wrote: post #50
exogen wrote: post #11

Earlier quoted context omitted.

Node is not a web framework. It's something one might use to build a web framework. So it's a bit silly to say that 'any web framework ever' already deals will this for you – well, duh, but the framework author certainly had to deal with thread safety (possibly incorrectly). And don't say no framework user has ever screwed up shared state because they didn't realize how threadlocal works or that requests might be han…

> 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
Post reply on HN