brimworks

Here are some things that I think are "beautiful" about Lua:

[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.

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.

That was a mistake in the article. I should have said "ANSI C". I'll see about getting it corrected.

Thanks!

@rifung - Thanks for the kind words.

@Chris2048 - Distelli is hiring. If you want to make your own assessment of my skill, then join us :).

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.

The "luvi" part of "luvit" is what the agent uses :).

Lua 5.3 has a utf8 library standard now:

http://www.lua.org/manual/5.3/manual.html#6.5

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.

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.