State of the
The main goal of this talk is to foster discussion for the
rest of the Workshop.
I have been working at Moodstocks, a small Paris-based company,
for 4 years.
We write software for mobile applications,
mostly image recognition and data management.
I work on the server side,
where most software is written in Lua.
Lua-the-language is successful...
games
extension language
embedded
web
...
Lua as a language is 20 years old and everywhere.
community
The Lua community (conferences, meetups, discussion online,
open source...) is smaller than it should & could be (IMO).
Lua grows in popularity, slowly and steadily...
No one starts projects in Smalltalk anymore. And this is not because Smalltalk isn't wonderful to work with - it is.
But... try just posting a question about Smalltalk to Stack Overflow and see how long it takes just to get answered. Try hiring a senior Smalltalk developer - good luck.
[One of them] told me that he comes to a couple of Ruby conferences every year, and I said "why don't you go to Smalltalk conferences?" and he said "because there aren't any."
Language quality != ecosystem quality. A good language is not enough
for "success". There are few Smalltalk conferences, and there are few Lua
conferences as well.
Importance of different factors when picking a language.
Top position: OSS libs.
Two main reasons to want popularity:
1) vendor support, 2) jobs.
It's not only Academia that thinks libraries matter.
This is an old but telling screenshot from Hacker News.
We must make a distinction between standard libs and
additional contributed modules. Lua has a very reduced
standard library for good reasons including portability.
Five years ago, I always assumed
Other dynamic languages such as Python have large standard libraries
but this causes problems, especially stagnation.
The standard library
The author of this quote wrote a HTTP client library that
is widely recognized as much better as the one
in the standard library.
It is not only Python. This is Ruby...
Sometimes we still want a batteries.
Penlight has most of what you need, start with it.
With the standard library issue behind us,
let us turn to the meat of this talk: Open Source modules.
Wanted
quantity: There is no module to solve my problem.
quality: New dependency, new bugs :( Where is the maintainer?
ease of use: How do I install this without breaking my system?
consistency: Why does my application depend on 25 object libraries?
discoverability: I cannot find what module solves that problem.
There are properties we want from those modules.
Quantity
There is no module
First we need a lot of them, enough to serve most use cases.
This is an example of a user not finding what he wants.
There are many others.
Ruby and Python have over 100x more modules than us.
Even Elixir has 100 modules.
Quality (1)
New dependency,
Next up, quality. Most important property:
adding a new module to an application should not introduce bugs.
On that front I think we are better than Ruby,
but worse than Python.
Actually happened to me: switching Redis to Unix sockets makes
a completely unrelated module crash. WTF?
The root of all Evil
Avoid globals in modules.
local foo = require "foo"
Use pl.strict in your test suite (please).
You have tests, don't you?!
Always be explicit when you monkey-patch or use globals.
Test with strictures, otherwise anybody who does cannot
use your module. Broken under strictures = broken.
If you really want to avoid namespacing,
let the user choose with this nice pattern.
Quality (2)
Where is the maintainer?
The 2nd part of quality is maintenance.
Maintained = someone answers issues.
Too many modules unmaintained and not flagged as such.
Do not abandon, propose for adoption on lua-l!
Ease of use
How do I install this
Modules should be easy to install,
in development and production environments.
LuaRocks is usually the way to go. It is growing
but still not used enough.
Pester maintainers, it works!
A simple trick to improve the ecosystem:
annoy maintainers until they submit rockspecs.
Note: this is bcrypt. How were you storing passwords?!
Consistency
Why does
Another property we want from a module ecosystem is consistency.
You don't want to learn 25 object models and make them inter-operate.
It is not only object libraries.
We have way too many JSON modules for instance.
If you want a module, look if it exists.
If it does but does not fit your use case completely for some reason,
consider contributing instead of making yours.
I wrote the first nanomsg FFI binding,
one of the first across all languages.
S.o. wrote another one, I asked to merge. Now it is "official",
under the nanomsg organization.
Sometimes you have valid reasons to make a new module
(e.g. pure v.s. binding).
There are no formal interfaces in Lua
but this doesn't mean the concept isn't good.
Examples: json / cjson, fakeredis...
Incompatible ecosystems
5.2
LuaJIT
Luvit
OpenResty
probably others
I have no answer to that.
A reason for the recent increase in the number of similar modules
is the rise of incompatible ecosystems. I don't know if its is
good or bad. They do increase the popularity of Lua.
5.2 is different; the transition probably works better than Ruby 1.9,
certainly than Python 3000.
Discoverability
I cannot find
Related to quantity and consistency.
It is not enough that module exists,
we have to find them.
Finding a module
LuaRocks
Lua Wiki
Google
Github
Mailing List
Stack Overflow
There are many ways to find modules to solve a problem.
They work more or less.
the best module
Sometimes it is harder to find which module you should use.
I am making a website to solve this :)
Inspired by the old Ruby Toolbox, but not a clone.
Written in OpenResty with Lua and Redis.
I wish I had more time. Contributors welcome.
Let's open discussions.
Before we end this talk, a few proposals
to give us topics of discussion.
Programmatic releases for LuaRocks
Why is our package manager not used as much as other languages'?
A difference is programmatic push. Moonrocks already does this.
Should this go into mainline LuaRocks?
Multiple maintainers
LuaSocket
LuaFileSystem
LuaSec / LuaCrypto
LuaExpat
There are a few very important libraries that would be
in the standard library in another language.
Recently the LuaSocket has been less available for very
good personal reasons ;)
But maybe we should make sure there are more than a
single maintainer for those libs. Also, bus factor.
style guide
Some languages have an officially sanctioned style guide (PEP8).
This is not Lua's philosophy but it helps with OSS contribution.
Olivine Labs have a style guide with external contributors,
including me.
Yes, I know that Lua module naming in the wild is a total train
wreck. This is one of the biggest failures of the Lua ecosystem.
Language ecosystems with user-contributed modules demand curation.
Or at least some officially sanctioned conventions. Remember that
next time you create your own language.
Anything that attempts to retain the illusion that a flat namespace
is somehow a workable solution is NOT helpful.
Mike Pall recently ranted about module naming.
Not sure if he proposes organizational prefixes à la Java.
If yes, I do not like the idea. But a few principles
(same name in LuaRocks as require, no lua- prefix...)
could help.
I didn't say it enough during this talk: *you* are the ecosystem.
So if you or your company has unpublished general purpose code,
consider releasing it. Also, report bugs, submit patches, talk
about Lua...
