...compare that to Perl where there is no "complete syntax" of Perl. This shows how simple it is and thus it is easier to write tools for and teach others how to use it.
[b] The complete default API consists of ~200 functions:
Simplicity is beauty IMHO. I would expect any competent developer to get up to speed on the Lua language within a week, it would then take them another couple of weeks to get up to speed on the libraries we use with Lua.
The real power in Lua comes when you couple it with competent APIs that do the "real" work. The Distelli Agent uses libuv for the OS interface, libcrypto (part of openssl) for the crypto primitives, zlib for compression, LPeg for parsing, sqlite for an embedded DB, etc.
The job of the Lua code is simply to "tie" these core components together.
The point of the Distelli Agent is to deploy software. Think of it as the "bootstrapper". Serious customers would rather use that 200MB for their own software, not for the "bootstrapper" :). Here at Distelli we optimize for the customer, not for our own internal developer productivity.
Good soundbite, but if using 200MB of extra space would let you lower your prices while offering the same service (by increasing developer productivity) then I bet many customers would take that.
And did you try spending a person-week or so of dev time trying to minimize the size of the Python version? That would be a much smaller one-off cost than the costs of migrating everything to Lua, and I could easily imagine you'd get it down by one or two orders of magnitude. (You could do the same for Lua too I'm sure, but if we're talking about say 5mb vs 200k then that's "who cares?" size for most customers).
1) All features/algorithms were ported, and we only added new functionality that never existed in the old Python code base. A few of the features that got added include: dispatching builds, getting live logs, re-encrypt keys, deploy encrypted artifacts, fix many bugs, support running multiple agents on a single computer, etc. I should also mention that we previously had two separate downloads: a CLI used for uploading releases, and the agent used for dispatching deployments. The functionality of both of these code bases where merged into our new Lua based "client" so customers only have to install a single binary that is less than 10MB (the binary size depends on your platform).
2) Deployments with the new agent were noticeably faster, (like 1 second deployments that used to take 20+ seconds). However, this speed up was largely due to the Python codes design which had a "continuation" loop which was polling based, but the Lua code used coroutines and simply continued the threads when the steps were complete.
Overall, I think the choice to use Lua (or more specifically luvi) was a great decision. Note that it did take a few iterations in order to come up with the optimal way of using Lua + libuv. Originally I was taking the Node.JS approach of using callbacks, but that approach has two problems:
[a] It is difficult to properly implement "back pressure" so that all queues between producer and consumer are bounded.
[b] It is difficult to handle errors properly.
Lua coroutines allowed me to write a simple "green thread" library that encapsulated these challenges.
Full unicode support is rarely necessary in my experience. Lua "strings" are raw byte arrays. It is the job of the programmer to validate the byte arrays are in the character set of your choosing and doing appropriate conversions and validation when necessary.
Docker is a great tool, but not all customers will have that available to them, and the docker experience isn't great for customers on Windows/Mac since they have to run Linux in a VM, which means the agent would have the footprint of an entire OS on those platforms.
uuid.get_node(): ...and which iface's address will I get if I'm on a multi-interface machine (not to mention that it was added in 2.5 version of Python)?
netifaces: ...would require me to build a C extension which would mean going down the rabbit hole of building and bundling python and this library.
As opposed to shipping LUA with C extensions? Also, there are things like shedskin: https://github.com/shedskin/shedskin - you don't even have to ship python. Or micropython: https://github.com/micropython/micropython with the code embedded. Then you can easily either shell out or include any C extensions you want.
This article does not say Lua is "better" than Python, it simply describes why we choose Lua. Bundling Python and rebuilding for each platform was certainly an option. However, luvi has the advantage that it has many platform specific builds prebuilt and extending luvi with more CMake files + C libraries is easy.
Plus me (the author of the Lua agent) was already familiar with Lua, so the easiest way to get from A to B was for me to use a known-good tool.
Exactly. It wasn't about Lua being better than Python, just that "in this challenge, the solution was Lua". Another challenge will have another solution.
I've only ever done game development in Lua and have never considered it for anything else honestly. Very cool use case here.
[a] Here is the complete syntax of Lua:
http://www.lua.org/manual/5.2/manual.html#9
...compare that to Perl where there is no "complete syntax" of Perl. This shows how simple it is and thus it is easier to write tools for and teach others how to use it.
[b] The complete default API consists of ~200 functions:
http://www.lua.org/manual/5.2/contents.html#index
[c] The defacto book on learning the complete language (including the C interface) is 366 pages:
http://www.amazon.com/dp/859037985X
Simplicity is beauty IMHO. I would expect any competent developer to get up to speed on the Lua language within a week, it would then take them another couple of weeks to get up to speed on the libraries we use with Lua.
The real power in Lua comes when you couple it with competent APIs that do the "real" work. The Distelli Agent uses libuv for the OS interface, libcrypto (part of openssl) for the crypto primitives, zlib for compression, LPeg for parsing, sqlite for an embedded DB, etc.
The job of the Lua code is simply to "tie" these core components together.