81–90 of 90 posts
Earlier quoted context omitted.
I'm working on a distributed app that shares code between the client and server, and there are already a multitude of open-source libraries that are designed to run in any JS environment.
That doesn't mean it's useful to do so, or that there are significant advantages to be gained from doing so.
This is like saying "This Honda Civic clearly sucks compared to my helicopter. Let me write you an article about everything that my helicopter does betting that your Civic". Clearly the Civic was build for another purpose and so the comparison is void.
> Node.js appeals to people who already know Javascript and don’t want to learn a new language This is a blanket statement that perhaps displays the author's opinion on Javascript as a language itself.
Could someone familiar with Erlang please clarify:
"To understand why this is misleading, we need to go over some background information. Erlang popularized the concept of lightweight processes (Actors) and provides a runtime that beautifully abstracts the concurrency details away from the programmer. You can spawn as many Erlang processes as you need and focus on the code that functionally declares their communication. Behind the scenes, the VM launches enough kernel threads to match your system (usually one per CPU) "
In common Unix tools like 'ps' and 'top' the term 'Lightweight Process' is used as a synonym for OS thread, eg, the LWP column in 'ps -eLf' shows the thread ID.
In this article, LWPs seem to be different from threads? Is this correct? If they're not threads, what are they?
Earlier quoted context omitted.
.. or erlang processes. Or python greenlets. Or Haskell forkIO threads. Or libcoroutines.. Etc. See: http://news.ycombinator.com/item?id=1549023
Erlang has a slightly different but largely equivalent model, but the other alternatives you mention lack Go's channels and/or the select construct which is one of the greatest things about the language. When I found that Stackless Python didn't have a way to read/write on multiple channels at once I was quite shocked.
http://hackage.haskell.org/packages/archive/stm/2.1.1.2/doc/...
http://www.haskell.org/ghc/docs/7.0.2/html/libraries/base-4....
It also looks that "select" statement could be done in a combinator library way.
The power of Haskell (or of any proper modern language) isn't in the language itself, it's in the number of things you can express as a library, on top of the language.
Earlier quoted context omitted.
NodeJS is great for applications with a lot of clients, but not for CPU intensive apps. Well, you do with node what you do with anything: if you have 4 CPU cores, run 4 copies of your app. Problem solved.
Imagine your app has 16GiB of precomputed tables in memory...
Speaking of concurrent programming and parallelism. If you're not into functional programming, check out Apple's Grand Central Dispatch[1] and Objective-C Blocks[2]. Unless you write your own Objective-C http server and run it on Mac OS X Server (it's not that hard, I've done it), this isn't very useful for Web programming. However, if you're comparing the languages / frameworks themselves (you can use all three to c…
I've been hacking away on Obj-C and more specifically MacRuby and did some basic stuff with GCD already, using the async queueing system. The distributed enumeration sounds interesting, could you point me in the direction of where I can find some more info about that?
http://developer.apple.com/library/mac/#documentation/Darwin...
Earlier quoted context omitted.
That doesn't mean it's useful to do so, or that there are significant advantages to be gained from doing so.
Like, say, sharing hashing functions, templating, encoding or math libraries? Not useful at all.
Math (significant math), encoding and hashing being done on the client sounds like a poorly designed application. Same for templating on the server -- which I assume you mean manually compiling templates using a library, and sending the result to a client, perhaps as a property of a JSON object.