| |||||||||||||
JavaScript ubiquityJavaScript ubiquityPosted Oct 17, 2012 23:41 UTC (Wed) by man_ls (subscriber, #15091)In reply to: Wayland and Weston 0.99.0 snapshots released by ms Parent article: Wayland and Weston 0.99.0 snapshots released
This "let's do everything in JavaScript" trend at the moment is a curious thing. I can't believe anyone with any experience of any sane language would actually want to write in JS - it's more just that it's pretty much the only choice for web apps.It is interesting to me also; one year ago I would not have thought it possible. It is hard to know what you mean by "sane language"; I have a background in C, Java, Python and a few other languages, and after a while I find JavaScript a great language. It is extremely simple, it is very expressive (and functional), and it can do lots of things with very little code: for example, node.js does the main loop in js code, not in some awful native library. Of course it is possible to do aberrations against Nature in it, but that is true of all languages. Lua is a bit horrible too once you get to meta-tables. The object model in particular is awful; the good thing is that you can build your own with a few lines of code. In summary: in JavaScript, you take an empty object, tell it "you are a chicken now", stick a beak, legs and some feathers on it, and it goes away clucking like crazy.
(Log in to post comments)
JavaScript ubiquity Posted Oct 18, 2012 22:27 UTC (Thu) by alonz (subscriber, #815) [Link] Hey, I thought JavaScript had duck typing! Now you're telling me it's been chicken typing all along?;)
JavaScript ubiquity Posted Oct 19, 2012 0:17 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] In my experience it's more like duct taping. But it works. Usually.
JavaScript ubiquity Posted Oct 22, 2012 3:32 UTC (Mon) by cmccabe (guest, #60281) [Link]
I think the node.js people will be tossing out their old code and rewriting in a new language in a few years. When the number of cores on a CPU keep doubling every year or two, and you can use only one of them... you're not in a good situation.
I agree that duck typing is one thing that ECMAScript got right. However, Golang (Google Go) is able to do this without giving up static typing. I think that's the way to go... no pun intended. :)
JavaScript ubiquity Posted Oct 22, 2012 7:52 UTC (Mon) by man_ls (subscriber, #15091) [Link] Somehow I don't think so: node.js is already orders of magnitude faster than other traditional servers. Also, I don't see all Python people throwing away their twisted servers, or Ruby throwing away Rails; and node.js is much more convenient than those two.For some applications a single-process server may not be right, but for the rest convenience usually trumps performance. (Witness MongoDB beating Riak or Cassandra.) Amazon rents cheap two-core servers, very convenient to run node.js on. In fact node.js uses two cores: one for receiving requests and another for servicing them. There are a couple of ways around a single-process server on a multi-core machine. One is to run many stateless node.js processes on a server. Another is to modify the V8 engine to run many threads in the same process and synchronize them; it is a more definitive solution, even though the engineering costs may be high. I don't doubt that Google can make it if they try.
JavaScript ubiquity Posted Oct 22, 2012 7:53 UTC (Mon) by man_ls (subscriber, #15091) [Link] A relevant reference for R. It can be done.
JavaScript ubiquity Posted Oct 25, 2012 9:34 UTC (Thu) by cmccabe (guest, #60281) [Link]
My argument is not about whether node.js is faster or slower than anything today, but about whether it will be useful in a multi-core future.
Personally I find the claims of "orders of magnitude faster than other traditional servers" pretty hard to swallow, but such claims are also "traditional" in their own way, so who am I to complain? :)
> For some applications a single-process server may not
It doesn't really make sense to compare Cassandra to MongoDB and Riak, since traditionally Cassandra is used with a much weaker consistency model.
JavaScript ubiquity Posted Oct 25, 2012 9:38 UTC (Thu) by man_ls (subscriber, #15091) [Link] I don't understand the bit about "weaker consistency model". I am using MongoDB with a very weak consistency model: data is denormalized (there are several copies of each piece of data, in different collections) and I have to ensure consistency in my application code. Why is it different with Cassandra or Riak?
JavaScript ubiquity Posted Oct 30, 2012 15:55 UTC (Tue) by cmccabe (guest, #60281) [Link]
MongoDB has a master server at each point in time for any given shard. And when you update a key in that shard, you always update the master. In contrast, Riak doesn't force you to funnel all writes to a key through a particular server. Because of this, clients are forced to reconcile the divergent versions of a key that may occur when they do reads. Cassandra is similar.
Note to nitpickers: a lot of these datastores can be configured to run in different consistency modes. For example Riak has last_write_wins, and Cassandra has the ability to do quorum writes, etc. In general, though, if you find yourself obsessing over these settings, you might just be using the wrong datastore for the job. They have different design goals.
To come back to your particular situation, denormalizing the data that you store in MongoDB is a choice that you have made. You could do the same thing with SQL, or any other strongly consistent data store.
On the other hand, you could say that the limtiations MongoDB forced you to go down this path, since it doesn't support SQL-style transactions, foreign keys, and so forth. That's a fair point.
|
|||||||||||||