I've been playing around with node.js (nodejs) for the past few day and it is fantastic. As far as I can tell, lua doesn't have a similar integration of libev and libio which let's one avoid almost any blocking calls and interact with the network and the filesystem in an asynchronous manner.
I'm slowly porting my java implementation to nodejs, but I'm shocked that luajit is much faster than v8 JavaScript AND uses far less memory!
I imagine writing my server in such an environment (very fast and responsive, very low memory usage, very expressive) will improve my project immensly.
Being new to lua, I'm just not sure if such a thing exists. I'll appreciate any pointers.
Thanks
A recent corresponding project is Luvit "(Lua + libUV + jIT = pure awesomesauce)".
From the announcement:
this is basically luajit2 + libuv (the event loop library behind
nodejs). It compiles as a single executable just like nodejs and can
run .lua files. What makes it different from the stock luajit
distribution is it has several built-in modules added and some
slightly different semantics.
Notice that we're not running as a CGI script to apache or anything
like that. The lua script is the http server. You get your
callback called every time an http request is made to the server.
Looks like the following is exactly what I was looking for:
LuaNode https://github.com/ignacio/LuaNode
See lualibevent and lua-ev and also Lua Gem #27
You might also have a look at luv:
https://github.com/richardhundt/luv
from the lua mailing list:
How does luv relate to Luvit - LuaJIT + libuv (Node.js:s/JavaScript/Lua/)?
It doesn't really. Luvit borrows heavily from node.js's architecture
(reactor callbacks, etc.), links statically against luajit, provides
it's own module system and executable. Luv is just a Lua module which
binds to libuv. The key difference is that Luv is more like an m-n
threading engine combining coroutines and OS threads while using the
libuv event loop under the hood.
So other than the fact that they both bind to libuv, they don't have
much in common.
You might want to take a look at Luvit or a gander at the Lua Github site. I think it takes the approach of implementing Node.js functionality right inside Lua. You write Lua code on the client side and on the server side. Here is a description of Luvit approach to doing Node.js functionality in Lua.
if i understood the question right, take a look at http://openresty.com/
luvit aims to be to Lua exactly what Node.js is to Javascript. Definitely a promising project.
You can get node.js style non-blocking IO with lua-handlers.
It even has an async. HTTP Client, which makes it really easy to start parallel HTTP requests. See the test_http_client.lua file as a example of the HTTP client interface.
You should also check out Lapis. It's a very lightweight and fast framework for OpenResty: http://leafo.net/lapis/
I've really been enjoying it and predict it will have a bright future!
As you would expect with anything built to leverage OpenResty, it's benchmarks are insanely good: https://www.techempower.com/benchmarks/#section=data-r12&hw=peak&test=query
The author of Lapis also wrote a CoffeeScript-like language for Lua called MoonScript which is quite nice:
http://moonscript.org/
Related
I have a program and I want that program to work for several users, with different passwords. How can I solve this problem with using node js?
I use instagram-private-api and want to login multiple accounts.
I think you are missing the point of node js. The reason why many other languages use threading (C#, java, c++, etc) is because all the code written is synchronous. Rather, it executes line by line. Line 10 doesn't execute until line 9 finishes. However, this is not to say they don't have asynchronous implementations. These days there are ways to write asynchronous syntax in those languages, but generally speaking, they're mostly all synchronous.
Enter javascript and the nodejs platform. 95% of it is asynchronous (95% is a total guess and more of a figure of speech, but there are "synchronous" functions... which should be used very rarely and, generally just avoided). So node uses a "single thread", but operates around something called an event loop. Not going to go into details about that here, but you can google on what the event loop is and how it works... other folks will explain it better than I can. Thus, because of that design, and because of the asynchronous nature, you really don't need threading in your nodejs application.
Sounds like you need to just go get your feet wet with node. Take some tutorials, etc. It's quite trivial to handle multiple users at once, and no threading is necessary.
Also, if none of that makes sense, then also go read up on "synchronous vs asynchronous".
Node js is a single threaded language but has asynchronous functions. For example if we use a loop in node js then as node js is single threaded then nothing can be executed until that loop finishes but this is not the case. We can use async functions which will run in event loop side by side with the main thread.
As a platform for handling concurrent problems, Elixir/OTP seems to be the best suited solution.
When writing an application with a web interface, consider the case in which I want to reason about, and decouple, the application logic using another functional language - namely haskell (due to benefits like its advanced detection of errors at compile time, static typing, etc). I would then handle concurrency using GenServers, and attach a web interface using Phoenix.Channels.
Is this setup even possible using NIFs? Also, would true concurrency be maintained? I'm not sure that I'm following the correct line of reasoning here, but would a new haskell process be able to be spawned in line with GenServer demands, and would the two be able communicate efficiently?
This setup is certainly possible using NIFs and GHC's FFI with a small amount of boilerplate written in C. But NIFs are best used for short synchronous computations with no side effects and I get the feeling that that isn't what these operations are.
You'd probably be better off with C Nodes for the Haskell parts of the application. Most of the documentation you'll find for that will be for Erlang and not Elixir, but given Elixir's easy interop with Erlang, it should be pretty straight forward (someone's even written an example). Most of the hard work will be to do with writing a Haskell "C Node", for which a cursory glance at hackage and github turns up nothing.
I am just reading a bit, trying to understand new concepts. Hence my question.
If I understand correctly the concept of webAssembly is to simply load a code base from another language (C++, C...) and run it inside the Javascript run time.
So, If I follow correctly, I could write some intensive calculation (e.g. Image manipulation) using C++. Compile the code for webAssembly and simply use it inside Nodejs?
Is there a code play environment where I could examine the principles in more depth?
Yes, there are many things which could be ported to WebAssembly for a performance improvement. Something that is CPU intensive but with minimal interactivity is ideal, and image manipulation could well be a good candidate for using WASM. There's no guarantee of course that it would be worth the development time compared to writing it natively in JS.
Just today I've discovered two online test environments (from the same team):
https://wasdk.github.io/WasmFiddle/
https://webassembly.studio/
The readline library and most other modules are geared towards asynchronous/event-based user input handling.
I need my application to block and wait for input before continuing. Is there a way to do this or is this simply not supported in Node.js?
I know this goes against the philosophy of Node.js but this is not what I am worried about - the application I am developing is not a conventional web application, I am just using Node.js to develop it.
There are numerous libraries for javascript that makes it easier to work with async. You can look here for one example: https://github.com/creationix/step .
I do most of my node.js programming using CoffeeScript, and there is a fork of the official compiler called IcedCoffeeScript that has support for await and defer keywords, that allows you to write CPS/callback-style programming without endless cascading of callbacks. You can find it here: http://maxtaco.github.com/coffee-script/ .
And finally, a free tip. When/if you start writing your own modules you may struggle with figuring out whether you should write it in a CPS/callback-style or not. When you struggle with this choice, always write it in a CPS/callback style, and use await/defer or any other javascript library to make it look and feel like traditional synchronous programming. Writing your own functions in a non-callback style and using libraries that primarily support callback-style programming is a recipe for disaster.
At http://nodejs.org/#about it says the following:
"Node is similar in design to and
influenced by systems like Ruby's
Event Machine or Python's Twisted.
Node takes the event model a bit
further—it presents the event loop as
a language construct instead of as a
library."
Are there other frameworks or languages that likewise expose the event loop?
Tcl has had this capability all along (last 2 decades). See http://www.tcl.tk/about/netserver.html
This is not to say Tcl does -- or should do -- everything Javascript and/or node.js does. But it is a valid answer to the question as to what "other frameworks or languages ... likewise expose the event loop?"
To be honest, I don't think there is something that's comparable to Node.js at the moment.
Why? Well basically because of the fact that JavaScript was single threaded from the start off, this made the language evolve in what it is today, a language that's perfectly fit for asynchronous programming, like you do it in Node.js.
Functions being first class objects, as well as having closures is a must if you want a Node like experience. For example you could just as well wrap plain C around the event lib and use that. But how much fun would that be? Even with twisted, you don't get even near the Node.js experience.
Second point is that Node.js has - except for the sync functions of the fs modules - no blocking functions, so while you can certainly do this style of programming in Python, you never know for sure if that library call isn't going to block your whole program. And kill the throughput of your server.
Also Node is fast, like in REALLY fast. V8 is definitely way ahead of Python and Ruby, yes you can write C-Extensions for both, but you can just as well do that for Node.js. Another plus point of using V8, Google is investing a ton of time/money into that Engine, another up to 2x improvement is already on the way with Crankshaft.
Node.js has more plus points, it's a complete framework (while Twisted is mainly async networking) and it's JavaScript.
The latter one may sound stupid, but the ability to re-use code and not having to do context switching , as well as being able to use mature frameworks for DOM manipulation (well, that is as soon as jsom gets into a more stable state) is another killer feature.
If you haven't done yet, I recommend you watch a couple of the talks listed on our Tag Wiki.
Especially the YUI one shows what possibilities await us in the near future.
So to sum it all up:
Although there are quite some frameworks out there that have an event loop, just having the loop itself won't give you the same experience as Node.js, so you should not expect a comparable experience when doing stuff in C or Java for example.
For the java platform I guess you could compare netty to node.js