8 ms·
Vert.x – JVM Polyglot Alternative to Node.js
- lucian1900 14y agoSo it's more like Twisted (a library) than Node (a runtime + a library).
- tantalor 14y agoNode is more like a library than a runtime. Its runtime is V8. The node libs could be ported to another JavaScript engine such as jsc, narwhal, or ringo. > Node.js consists of Google's V8 JavaScript engine plus several built-in libraries. http://en.wikipedia.org/wiki/Nodejs http://en.wikipedia.org/wiki/Nodejs
- lucian1900 14y agoNode ships with both runtime and async library, unlike Twisted, which doesn't ship Python.
- treenyc 14y agoalso look at http://ringojs.org http://ringojs.org
- pan69 14y agoTrying to install this on Ubuntu. Is it me or is the "binary" download link [1] not really a binary download link? [1] https://github.com/purplefox/vert.x/downloads https://github.com/purplefox/vert.x/downloads
- purplefox 14y agoWorks fine here: https://gist.github.com/2594983 https://gist.github.com/2594983 Are you sure you're not looking at the github tags, rather than the downloads?
- pan69 14y agoOK. I think I know what I did wrong. On the Github (download link on the website) I click "Download .tar.gz" assuming I was getting the latest version. I might got the latest version but it seems to be the latest of source. I should have chosen one of the packages.
- deleted 14y ago[deleted]
- abeatnik 14y agoThe install pre-requisites recommends that Windows users install a linux VM - but I found the beta 11 version works directly.
- purplefox 14y agoYes, vert.x should work directly on Windows. I shall update the wiki accordingly :)
- wiradikusuma 14y agoi wonder how is it compared to servlet container (e.g. tomcay and servlet spec?
- hanswesterbeek 14y agoit ignores those, for good reason
- ExpiredLink 14y agowhich is?
- tsewlliw 14y agoEvery concurrent request gets its own thread, whereas this seems to be one thread per core. Also, the servlet API is crazy, partly because of all its baggage. There seems to be a lot of exploration around what the right API is right now, but its pretty clear the world wants something new.
- pron 14y ago> Every concurrent request gets its own thread, whereas this seems to be one thread per core. No. Servlet containers use a thread pool (that grows and shrinks dynamically).
- pivo 14y agoThere's really no conflict between the statement, "every request gets it's own thread" and the use of thread pools. The point is that a given request in a servlet container is handled in it's own thread. That thread will probably come from a pool and be reused to handle another request of course, but that's sort of immaterial.
- Animus7 14y agoImpressive. It's basically a kinda-sorta-rewrite of Node.js APIs on the JVM. Looking through the docs, the main difference I see is that this is opting for a comparatively heavy-core approach which contrasts with Node's ruthless minimalism + third-party modules. For example: -file system access is convoluted with HTTP handling: req.response.sendFile() -pieces of web framework functionality by default, but no full solution (RouteMatcher) -integrated WebSockets with a novel but unconventional accept/reject API -heavyweight SockJS integration It will be interesting how all of his plays out. And I'm definitely interested in hearing evidence for claims such as > a run-time with real concurrency and unrivalled performance
- stephen 14y ago> -file system access is convoluted with HTTP handling: req.response.sendFile() I haven't looked in to it, but just guessing this is probably so that it can do 0-copy sending of files (e.g. doesn't have to buffer/stream the contents through the JVM).
- purplefox 14y agoThat's right. If you use the sendFile() method and you're on an OS that supports it, then the kernel will do the copying directly from file to socket for you. You can also serve files in the more conventional "node.js-style" way (i.e. pump the buffers manually from file to socket) if you like. It's just slower than getting the kernel to do the work for you.
- dap 14y agoBut you have to dedicate a thread to sendFile() (by nature).
- jbooth 14y agoNot really, typically you'd have one thread handling all sendFiles through a single selector over the destination sockets. As a matter of fact, it's actually really painful to do sendFile in Java from a single thread, because when the channel isn't ready for sending, rather than returning EAGAIN and letting you busy-loop or wait/retry or whatever, it throws an exception. So you have to use a selector to do sendfile, and in that case, why not use multiple tasks with the same selector?
- mattgreenrocks 14y agoI was hoping it provided an alternative ideology to node.js in the form of fibers.
- purplefox 14y agoFibers (or equivalent constructs) aren't supported by all the languages that Vert.x supports (e.g. Java) so we can't really support something like that until we can do it in all the langs. I know Fibers/Green threads are all the rage right now, and it is certainly something to keep an eye on, but I am not entirely convinced that roll your own threading is going to be any more performant than what the kernel can do. If we can find a way of implementing fibers efficiently, that supports millions of fibers on a single JVM instance, I would be interested.
- sehugg 14y agoLooks like a user-friendly interface to Netty and Hazelcast with some special sauce sprinkled in. I love Netty, and Hazelcast is, er, interesting and hopefully getting more reliable. Should be fun.
- ww520 14y agoNetty and Hazelcast are amazing pieces of software. I've used them with good success. Hazelcast is another unique enabler that makes the impossible or difficult to do trivial.
- Uchikoma 14y agoFinagle works fine. Thank you. Love it. But it does not take off. Why? What all the JVM Node.js clones are missing and what Node.js sets apart are async libraries. There is no async (MySQL) JDBC driver for starters. If your IO drivers are not async, your async container is not very useful in real life.
- kyleburton 14y agoThis. The biggest difference is in the two cultures: blocking is anathema to the Node.js community - they will literally reject libraries or code that blocks because it destroys the entire model; the JVM community does not value non-blocking code - most of the core (JDBC, Networking in general, File system operations) is all written in a blocking style - the JVM community accepts this with the implicit assumption that threads will help assuage those issues. Python, Ruby and Perl all have the same cultural tolerance for blocking code. The Node.js community has a complete lack of tolerance for blocking code. I work with the JVM every day (Clojure) and wish it was different wrt the common use of non-blocking code, but it's going to be a long road to get there on the JVM. Kyle
- Locke1689 14y agoWhat are you talking about? libevent invented everything Node.js uses and Python's Twisted had and has everything Node.js could dream of. Node.js is just a reinvention of old technologies in Javascript. Edit: Removed flame about Javascript because I don't want to have this debate again.
- kyleburton 14y agoI am talking about the cultures surrounding these languages and frameworks. Node's community rejects blocking libraries. Java's does not. I've used the non-blocking frameworks in Perl (POE and my own), C (select, and some of the poll variants), Ruby (event machine) and they are fine if you can avoid blocking libraries -- in these communities it is generally acceptable to write blocking libraries. I don't see it as a technical hurdle, I see it as a cultural one.
- andrewvc 14y agoI'm really excited about this. While node-js is a great project, it still doesn't have the awesome instrumentation and tooling around it the JVM does. Additionally, real threading is damn nice, and the JVM definitely has that. Combining this with languages like ruby, clojure, and scala seems like a definite win.
- Zak 14y agoI'm not sure. Async-by-default doesn't seem like a great model for programming the server-side part of most things that are done over HTTP. Three use cases jump out at me: 1. Javascript doesn't have threads, but you want to write a usable HTTP server in it. 2. Threads are scary. 3. You want to make certain actions asynchronous over HTTP (i.e. client says "start", then server maybe says "done" later). Now consider Clojure: 1. Clojure has threads (on the JVM, at least) and one typically uses an existing Java web server when a web server is called for. Unlike Javascript when node.js came out, Clojure isn't lacking options for running or writing a web server. 2. Clojure makes a lot of threaded operations pretty non-scary. Its native data structures are all immutable and it has constructs for concurrent state. These are not any harder to work with than the async/callback model. I find it more natural, but I'm used to Clojure so that could be bias. 3. Async-when-desired is already easy in Clojure. Futures provide a very easy way to do stuff in a thread pool without blocking. Agents provide the same thing for state changes. It really is as easy as (future do-blocking-thing) and (send-off an-agent do-blocking-thing some-args). I can imagine why I might want this sort of thing in certain languages in addition to Javascript, but why would I want it in Clojure?
- anuraj 14y agoThis is most welcome. Hope they continue to support this effort. We need more light weight approaches in established languages like Java.
- jhspaybar 14y agoMaybe I'm one of the weird ones, but I absolutely love types and would probably write everything in JS if it had typing similar to Java or C++. As it is, I'm using Java on Jetty instead for my current web application but would love to see a really solid event Node.js style typed framework. With that said, at this point I'm not sure I'd give up my Servlets, frameworks(like CometD) for doing WebSockets, and the other niceties that a true servlet container gives me. I can't wait to see where this goes though!
- stcredzero 14y agoThere's only two kinds of weirdos in this world. Those who love types, and those who don't.
- dap 14y agoFrom the article: > InfoQ: What about running a real-time app on the JVM vs. on Node.js, with respect to debugging, monitoring and operations? > Answer: I'd say monitoring and operations are really the concern of the environment in which you deploy vert.x than vert.x itself. e.g. if you deployed vert.x in a cloud, the cloud provider would probably provide monitoring for you. This makes it sound like a toy. How can I deploy something to production when I have no way of seeing what it's doing? How is a cloud provider supposed to provide debugging/introspection for JavaScript running on the JVM (by means of a brand new facility)?
- almost 14y agoreq.response.sendFile('webroot/' + file); !!!! I'll have file='../../secret.txt' thanks
- purplefox 14y agoYes, of course in a real web server you'd make sure you do the checks ;) The documentation actually mentions this point explicitly :)
- almost 14y agoI'm pretty sure I don't want to use a web server by people who think a 5 line demo that gives unrestricted access to the hosts file system is the best way to show off it's capabilities. Sorry, but that's just stupid.
- purplefox 14y agohttp://vertx.io/core_manual_js.html#serving-files-directly-disk http://vertx.io/core_manual_js.html#serving-files-directly-d...
- almost 14y agoI'm unsure what you're trying to say there. Yes, I am aware that it's possible to serve files without exposing your whole file system. Did you think that was something that might be in doubt?
- sausagefeet 14y agoFrustrating to see a library like this be called "Next generation" when the code structure is a step backwards as far as I can tell. We have had green threads, and more than that green threads that can multiplex over multiple cores for a long time. Let's move on, people.
- dotborg 14y agoThis is not anything new, this funcionality is part of Apache Cocoon since almost 10 years and is called Flowscript: http://cocoon.apache.org/2.1/userdocs/flow/api.html http://cocoon.apache.org/2.1/userdocs/flow/api.html You can use and create Java objects from your JavaScript.
- salimmadjd 14y agoI went through their tutorial and it seems very enticing. hopefully it'll get some real traction and broader support.
- emblemparade 14y agoThere are other alternatives for polyglot JVM goodness, for example this based on Restlet: http://threecrickets.com/prudence/ http://threecrickets.com/prudence/ Plus a whole framework based around MongoDB: http://threecrickets.com/savory/ http://threecrickets.com/savory/