> 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-pu

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