lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

March 25, 2017 3:27 PM, "Peter Aronoff" <> wrote:

> Rodrigo Azevedo <> wrote:
>> This is not an exclusion, but C libraries are harder to maintain than "Pure
>> Lua".
> I’m going to sound like a broken record, but really? Why? I’ve never
> thought of it as being the case—again from experience with other languages.
> What I have seen is that *any* library in a language’s stdlib often ends up
> being maintained more slowly, and less well, than non-stdlib equivalents.

Those two statements are not incompatible.

I agree about standard libraries. I have said the same thing at the Workshop
in 2013 and I state by it: a lot of things don't belong in a standard library.

However I do believe pure Lua libraries are easier to maintain than C
libraries, for several reasons:

- They are more portable. Lua is relatively straightforward, whereas
  C standards are underspecified and C code written for one OS with
  a specific compiler typically does not work on others, except if
  a lot of care is take. This is the case for the Lua interpreter,
  which is why writing code in Lua is a good recipe for portability.

- There are more Lua programmers who know Lua than Lua programmers
  who know C. Every dynamic language should expect higher contribution
  in pure libraries than in C libraries. It is the case for Python,
  Ruby, etc as well.

- It is easier to write Lua code that works well in all of Lua's
  different ecosystems (PUC Lua embedded or not, LuaJIT,
  OpenResty, etc) than C code. For instance, libraries built on
  top of LuaSocket are reusable in OpenResty and they will be
  non-blocking, because OpenResty has re-implemented a compatible
  socket API. It would not be the case of C modules.

- The Lua language is slightly more stable across Lua versions
  than the Lua C API.

Pierre Chapuis