Hacker News Reader

Comment by puppetmaster3 | Hacker News Reader

4 reasons its good and 2 way to make it better:

1. it's async! most developers can't do threading. it does not do locking at all! let me say it again: no locks. java devs: what is faster, hashmap or hashtable?

2. it's dynamic. compare to old static langs.

3. it uses same syntax as browser.

4. npm. compare it to the maven.

A way to make it better?

1. thick client, not server side rendering of ui. use a CDN and phonegap build

2. npm -g install typescript (to make it a bit less dynamic)

cheers.(I myself now like D libs, such as http://vibed.org )

View on HN

> 4. npm. compare it to the maven.

NPM is probably the worst part. It solves the easy problem using brute force and 20 copies of the same library, but punts on actual packaging. Joyent's advice is "don't use NPM to deploy -- use tarballs." What kind of package manager requires you not to use it for deployment??

I really think NPM is a solution for immaturity on the node libraries. Think about the attack surface when you have 20 different versions of the same library scattered throughout your application.

Not having to understand your library dependencies means you don't understand all of the security bugs from old versions of libraries. You should understand your library dependencies. Forgetting about them doesn't make those relationships go away.

What are you comparing it to? I compare it to Maven and one is clearly better - if you used both in anger.

>Java devs: what is faster, hashmap or hashtable?

Ok, as a Java-dev I'll bite: They are not really comparable - because their use depends on the situation. One is meant for concurrent access by multiple threads - and thus synchronizes the access, while the other one is not thread safe and should not be used where this is a requirement. If you want the best of both, use ConcurrentHashMap.

There is a concept of a shared resource, e.g. a cache of computed values. A shared resource will necessarily be subject to concurrent modification, and thus requires synchronization. The point is, depending of the situation shared resources may far outweigh the cost of synchronization. These are tools, understand them and use them where they makes sense.

>>it's async! most developers can't do threading Most developers can't do async either. - It's really hard to debug if you dont get your callbacks right.

Personally I find threads easier than async.

It's just you. It's easy to do clean deterministic event driven programming. Maybe you are just not used to it. It works just like the browser events, and there are kids in elementary doing it.

Last, no locks is FAST!

Reply on news.ycombinator.com