4 ms·

To me, the fundamental problem is that Lua is designed to be an embedded extension language. But the vast majority of the publicly available extension modules a

To me, the fundamental problem is that Lua is designed to be an embedded extension language. But the vast majority of the publicly available extension modules are provided as shared libraries. If you have embedded Lua in your application, you are forced to use dynamic linking to use those modules. And if you use an OS that doesn't gracefully support dynamic linking (like uClinux on some platforms), you are screwed. A second problem is that those modules tend to be kitchen sinks. For instance if you want UDP networking, and pick one of half-dozen modules that provide that, nearly all of them also provide other things you don't need. Why do people choose Lua? Small footprint, often. Why then provide bloated modules? In other words, the module ecosystem only addresses one use case of Lua - as an extensible scripting language - and misses all of the others. And the end result is that it actually has Zero utility for most Lua users.

catwell 12y ago
A lot of modules are pure Lua. They may depend on a few critical C libraries though. But with just LuaSocket, LuaFileSystem and maybe LPEG you can use most modules. There are several ways to build those critical Lua modules statically, one being https://github.com/stevedonovan/luabuild https://github.com/stevedonovan/luabuild Even without those, it is not very hard to modify the makefiles to build statically. About the bloat: this is certainly true for some modules and not others. As I said in the talk, everybody uses Lua differently and nobody will use all the modules and tools available, but there is still some amount of code that can be shared. I mean: you could say exactly the same thing about C, and it still has a lot of libraries.
- virtue3 12y ago
  the Lua interpreter is so small and simple that if you really needed libraries and couldnt' dynamically link them in you could easily compile them into the lua interpreter and push the module onto the global table :/. It's really not hard.
Xeoncross 12y ago
> To me, the fundamental problem is that Lua is designed to be an embedded extension language. This. When people like myself want to use it outside that small goal we end up switching to python or go despite how amazing projects like openresty are.
- otikik 12y ago
  It is not a small goal; it's a different goal. You should use the right tools for the right job. If you need a general purpose language, use one.
  - astrobe_ 12y ago
    That's the contradiction I wanted to underline with my two first sentences. When you browse the community-run Lua Wiki, Lua looks like a general purpose scripting language. But not everyone agrees on this. I see no reason it cannot be both. As someone said in this thread, with so many uses cases how can we hope to build a useful ecosystem? I think the first step is to acknowledge this community fragmentation and deal with it.
    - otikik 12y ago
      > When you browse the community-run Lua Wiki, Lua looks like a general purpose scripting language. I don't agree with that. > I see no reason it cannot be both. There are several. The first one is that some design decisions in the language (like restricting all the C code to C99) rule out some features which would be considered basic in a general purpose language (like listing the contents of a folder, or using sockets). These decisions make it good in other areas (like running in a very memory-constrained environment, like an embedded microprocessor). Making it fully-featured risks throwing all that away. The second one is that its creators don't want to transform it into a general purpose language. > I think the first step is to acknowledge this community fragmentation and deal with it. I am sorry, but what you are referring to is not community fragmentation; it's people who are familiar with the language, on one hand, and people who ... are not. And thus come into it with the wrong expectations. I'm not saying this to be offensive. If you want a language which is at the same time embedded and general-purpose I think your best option is looking elsewhere. I've heard good things about mruby, perhaps it'll interest you: https://github.com/mruby/mruby https://github.com/mruby/mruby
otikik 12y ago
> To me, the fundamental problem is that Lua is designed to be an embedded extension language. I see that as an advantage. We already have plenty of general-purpose languages. > If you have embedded Lua in your application, you are forced to use dynamic linking to use those modules. And if you use an OS that doesn't gracefully support dynamic linking (like uClinux on some platforms), you are screwed. Even if you are in that particular tiny niche, you are not screwed. You can still download the source code and recompile (which will be second nature for you, if you are doing uClinux). > A second problem is that those modules tend to be kitchen sinks. [...] Why do people choose Lua? Small footprint, often. Why then provide bloated modules? Some modules are like you say. Others aren't. I am very careful not to put more than is necessary in my modules. > In other words, the module ecosystem only addresses one use case of Lua - as an extensible scripting language - and misses all of the others. And the end result is that it actually has Zero utility for most Lua users. Even if that was true, you are assuming that using it as a scripting language is not the main usage. Maybe it is, and the "other cases" are a small minority. But it is not true. As others are saying, plenty of modules in luarocks are pure-Lua, and completely cross-platform.

catwell 12y ago

A lot of modules are pure Lua. They may depend on a few critical C libraries though. But with just LuaSocket, LuaFileSystem and maybe LPEG you can use most modules. There are several ways to build those critical Lua modules statically, one being https://github.com/stevedonovan/luabuild https://github.com/stevedonovan/luabuild Even without those, it is not very hard to modify the makefiles to build statically. About the bloat: this is certainly true for some modules and not others. As I said in the talk, everybody uses Lua differently and nobody will use all the modules and tools available, but there is still some amount of code that can be shared. I mean: you could say exactly the same thing about C, and it still has a lot of libraries.

virtue3 12y ago
the Lua interpreter is so small and simple that if you really needed libraries and couldnt' dynamically link them in you could easily compile them into the lua interpreter and push the module onto the global table :/. It's really not hard.

Xeoncross 12y ago

> To me, the fundamental problem is that Lua is designed to be an embedded extension language. This. When people like myself want to use it outside that small goal we end up switching to python or go despite how amazing projects like openresty are.

otikik 12y ago
It is not a small goal; it's a different goal. You should use the right tools for the right job. If you need a general purpose language, use one.
- astrobe_ 12y ago
  That's the contradiction I wanted to underline with my two first sentences. When you browse the community-run Lua Wiki, Lua looks like a general purpose scripting language. But not everyone agrees on this. I see no reason it cannot be both. As someone said in this thread, with so many uses cases how can we hope to build a useful ecosystem? I think the first step is to acknowledge this community fragmentation and deal with it.
  - otikik 12y ago
    > When you browse the community-run Lua Wiki, Lua looks like a general purpose scripting language. I don't agree with that. > I see no reason it cannot be both. There are several. The first one is that some design decisions in the language (like restricting all the C code to C99) rule out some features which would be considered basic in a general purpose language (like listing the contents of a folder, or using sockets). These decisions make it good in other areas (like running in a very memory-constrained environment, like an embedded microprocessor). Making it fully-featured risks throwing all that away. The second one is that its creators don't want to transform it into a general purpose language. > I think the first step is to acknowledge this community fragmentation and deal with it. I am sorry, but what you are referring to is not community fragmentation; it's people who are familiar with the language, on one hand, and people who ... are not. And thus come into it with the wrong expectations. I'm not saying this to be offensive. If you want a language which is at the same time embedded and general-purpose I think your best option is looking elsewhere. I've heard good things about mruby, perhaps it'll interest you: https://github.com/mruby/mruby https://github.com/mruby/mruby

otikik 12y ago

> To me, the fundamental problem is that Lua is designed to be an embedded extension language. I see that as an advantage. We already have plenty of general-purpose languages. > If you have embedded Lua in your application, you are forced to use dynamic linking to use those modules. And if you use an OS that doesn't gracefully support dynamic linking (like uClinux on some platforms), you are screwed. Even if you are in that particular tiny niche, you are not screwed. You can still download the source code and recompile (which will be second nature for you, if you are doing uClinux). > A second problem is that those modules tend to be kitchen sinks. [...] Why do people choose Lua? Small footprint, often. Why then provide bloated modules? Some modules are like you say. Others aren't. I am very careful not to put more than is necessary in my modules. > In other words, the module ecosystem only addresses one use case of Lua - as an extensible scripting language - and misses all of the others. And the end result is that it actually has Zero utility for most Lua users. Even if that was true, you are assuming that using it as a scripting language is not the main usage. Maybe it is, and the "other cases" are a small minority. But it is not true. As others are saying, plenty of modules in luarocks are pure-Lua, and completely cross-platform.