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

To boldly go where Node man has gone before

blog.jgc.org

Post reply on HN
Print view View original

111–120 of 124 posts

Re: To boldly go where Node man has gone before

#111

Post by daliusd »

mkramlich wrote: post #95
xxbondsxx wrote: post #7

Choosing Node.JS isn't just a performance / scaling decision for me -- one of the main draws to Node is the huge community and wealth of awesome modules. Socket.io, Now.js, cradle, redis, and dozens of other modules abstract away the tedious work and let me build functionality _really_ fast. Go is really promising but it won't win over the majority of casual developers until there's a community around it. I might as…

> one of the main draws to Node is the huge community and wealth of awesome modules. If you think Node has a huge community and wealth of awesome modules wait til you to discover the older and more mature languages/platforms, like Python, C, Java, etc. "What I like about Justin Bieber is the massive history of his career, spanning decades, and the broad range of his musical style across several genres." :)

It is funny because I have chosen Node for one my project because I have not found easy way to do that in Python. I must say I really love Python - it is my favorite programming language. I could do the same project in Python but node.js looked slightly better and faster in this case.

Programming language is just a tool - one from many tools you can choose to make your projects and node.js have done some basic things better than Python (e.g. packaging). I have learned to love JavaScript and it is really good language now. Still there are projects I wouldn't choose node.js as my tool.

Re: To boldly go where Node man has gone before

#112

Post by reissbaker »

moe wrote: post #92
tomjen3 wrote: post #19

Earlier quoted context omitted.

For small apps, no. For complex ones yes. The actual code shared may not be that much, but consider the advantages in sharing validation code between the client and server -- you never accidentally forget one requirement on the server side, leaving you vulnerable to an attack.

consider the advantages in sharing validation code between the client and server Is there a mature implementation of this yet? One that is not tied to an entire immature framework (meteor) or programming pattern (nowjs)? Code-reuse was the big promise of node. Yet in reality I've never seen it executed beyond brittle experiments. Where is the form_for_model() function that emits code for both the client and the serve…

Template compilation being able to happen on either the client or the server is a huge win for anyone writing webapps, and it's trivial to write view code that can be compiled in both Node and browsers even without a framework.

In other languages, even if you write completely logicless views in a templating language that can compile in the browser like Mustache, you'll end up duplicating your presenter code if you don't use a language that browsers can understand.

Re: To boldly go where Node man has gone before

#113

Post by jerf »

zoips wrote: post #108
cageface wrote: post #106

Earlier quoted context omitted.

You can do non-blocking I/O without the nested callbacks you have to use for everything in Node. You just fire off a block to a goroutine and then code sequentially there.

In the short term: https://github.com/laverdet/node-fibers In the long term: http://wiki.ecmascript.org/doku.php?id=harmony:generators

No, and no, respectively. Hacked together libraries to sort of support rewrite it at the wrong level of the stack (the compiler should be doing the continuation transform, anything else will lack performance due to having to jump through a lot more hoops) and merely having generators is not the same thing. And neither solution you propose will give you true preemptive multitasking. Do you know how you fire off a long computation in Go or Erlang? You just do it. No marshalling, no blocking, no dealing with OS processes, no fuss.

Neither of those two things are new ideas. Python has had generators forever. If it solved the underlying problems, Go would never have been written.

Re: To boldly go where Node man has gone before

#115

Post by densh »

zemo wrote: post #86
kbd wrote: post #2

So does Go's net/http module really provide basically exactly the same programming model as Node? If so, why use Node? One thing the author didn't mention is that Go will use multiple cores in this example, whereas Node is single-threaded. Right?

No, the model is completely different. In Node, you pass in a callback to establish what should be done following the return of a longrunning I/O operation. In Go, you use goroutines to manage the concurrency. Basically if you say this: fn() The Go runtime will execute the function in its entirety and wait for a return value. If you say this: go fn() The Go runtime will execute that function in a new goroutine (the r…

Important point there seem to be missing from your goroutine description is it's scheduling with respect to system calls -- all interactions with underlying OS is asynchronous in Go even though it looks like a blocking API. E.g. networking internally uses polling specific to given OS. So if one goroutine is waiting for a system call to complete it will not block the rest of goroutines.

Re: To boldly go where Node man has gone before

#117

Post by veemjeem »

vibrunazo wrote: post #32
veemjeem wrote: post #6

I'm sure the reason why users pick node is probably similar reasons why one picks ruby/python -- it's not for the speed. The language of the web is javascript. Until web browsers allow Go as the embeddable language, node will remain useful. I seriously doubt people would pick Go over node because of a micro-benchmark.

You can compile Go to js with gwt. You can reuse code that way. I personally even reuse Java code between Android, front end Web and server. Because of gwt. I don't think there are many people who choose js because they like it. It's usually because they feel forced. Javascript is a terrible language, I always prefer one of the compilers. Dart can't come fast enough.

Where is this GWT compiler for Go? From what I understand, GWT is for Java translation only, and it only works well on code that doesn't reference any third party libraries. It doesn't work that well on code that makes heavy use of annotations either.

Re: To boldly go where Node man has gone before

#118

Post by antihero »

virmundi wrote: post #93
arturadib wrote: post #60

Node is popular not only because it's very fast (yes, it's still pretty darn fast even if there might exist faster alternatives), but because it's JavaScript. That's an enormous advantage for startups as (a) the JavaScript hiring pool is much larger than most other languages (particularly in comparison to nascent ones, like Go), and (b) the ability to write client- and server-side code in the same language means smal…

I've heard the JavaScript developers are easy to find argument before. However, good JavaScript developers are really hard to find. Especially when you need them to take those skills and run them on the server. There is a big difference between a jQuery hack and a good JavaScript developer.

Exactly, I just see the PHP problem repeating itself. Yes, you can get a PHP developer for £7/hour, but are they going to write good code? Unlikely.

Re: To boldly go where Node man has gone before

#119

Post by kisom »

m0shen wrote: post #61
peterwwillis wrote: post #35

Earlier quoted context omitted.

You might like Perl too. Edit: haha I love how people downvote this like i'm being sarcastic. Down with Perl, that horrible language with a community and modules 100x larger than Node!

I don't understand the attitudes either. While I enjoy writing Javascript for Node, when other Node users tell me they hate Perl, I can do nothing but give them a blank stare. So you want an environment that is easy to program in a functional style with closures and first class functions. Has a large ecosystem, including hundreds (thousands?) of packages to do asynchronous IO. Is easily extensible and can fall back o…

It's not hip and exciting anymore and generations of poor Perl coders have everyone convinced Perl code must always look ugly.

I'm a fan of C and Python myself, but I always chuckle at all the Perl hate.

Re: To boldly go where Node man has gone before

#120

Post by moe »

reissbaker wrote: post #112
moe wrote: post #92

Earlier quoted context omitted.

consider the advantages in sharing validation code between the client and server Is there a mature implementation of this yet? One that is not tied to an entire immature framework (meteor) or programming pattern (nowjs)? Code-reuse was the big promise of node. Yet in reality I've never seen it executed beyond brittle experiments. Where is the form_for_model() function that emits code for both the client and the serve…

Template compilation being able to happen on either the client or the server is a huge win for anyone writing webapps, and it's trivial to write view code that can be compiled in both Node and browsers even without a framework. In other languages, even if you write completely logicless views in a templating language that can compile in the browser like Mustache, you'll end up duplicating your presenter code if you do…

and it's trivial to write view code that can be compiled in both Node and browsers even without a framework.

Nonsense. It's far from trivial to have the same code get binding and validation right on both sides. That's why it needs to be wrapped in a thin abstraction, which apparently nobody in the node-community has been capable of writing.

Instead we see dozens of rails-clones (oh, exciting..), and a handful of very half-baked full-stack universes that are nowhere near production ready.

Post reply on HN