12 ms·

Stay away from Lua and use Python, Go, Node, Rust or even C in new projects. This is going to be a lengthy rant for a comment; apologies in advance. Having wri

Stay away from Lua and use Python, Go, Node, Rust or even C in new projects. This is going to be a lengthy rant for a comment; apologies in advance. Having written a ton of networking code in Lua I can tell it has a lot of design defects that most other programming languages have avoided. Especially the deeply embedded one-based indexing and lack of a separate integer type (chars are strings, ints are floats) make it wearing to type any code that has to parse any binary data. Even bit manipulation requires going through the FFI. Considering that Lua is often touted as the optimal lightweight solution in small embedded systems, these features are must-haves. The builtin string pattern matching library attempts to mimic regular expressions, but bites the user in the leg every time they attempt to use it for anything remotely regex-y. Unfortunately most usual string manipulation seems to revolve around them and the string.gsub function. The inconvenient string library is also largely irrelevant. The developers call their language eight-bit transparent which in reality means that the programmer needs a separate Unicode library, rendering the whole standard string library mostly useless. One cannot even format UTF-8 text, because the string library doesn't differentiate between characters and bytes. The official documentation mostly revolves around C bindings. The actual Lua language documentation is provided by another web site that looks like it has been written by an attention-deficit child. Instead of getting to the point, the articles often first provide a list of ways on how not to implement things, or they are actually benchmarks of fifteen different ways to call the standard library to get the same effect. Sometimes, the provided code does not even work – for example, the given XML parser code crashes when it hits one of the error paths. The small runtime and fast VM do not really matter when the language itself is lacking and requires a metric ton of external libraries to achieve even the simplest things that are possible in standard C and Rust, which provide the same level of performance and better type safety.

saagarjha 8y ago
C and Rust solve different problems. They’re compiled, for one.
- anilakar 8y ago
  C and Rust solve exactly the same problems as any other programming language in the embedded context: they try to interface with real world. Whether they're compiled or not rarely matters, when software updates are done by reflashing the whole device. Edit: If you have a device with enough computing power to run a scripting language interpreter, you can use Python in most cases.
  - simias 8y ago
    I agree with the parent, C and Rust are not scripting languages, Lua is. The frontier between what does and does not constitute scripting is admittedly blurry these days but in the case of these languages it's fairly clear cut IMO. Lua is very dynamic, easy to code for (syntactical quirks aside, I'm talking from a "cognitive load" standpoint) while C and especially Rust are a lot more static, require more careful coding but can result in faster and, at least in the case of Rust, more robust code. Lua is the type of language you embed in your C app to make it configurable.
    - anilakar 8y ago
      >easy to code for (syntactical quirks aside, I'm talking from a "cognitive load" standpoint) That's not a fair comparison. A large chunk of the cognitive load comes from the awkward syntax and other design decisions that stem from it. >Lua is the type of language you embed in your C app to make it configurable. Situations where configuration files aren't sophisticated enough but a Python interpreter is too heavy are few and far between.
      - simias 8y ago
        Syntax is very subjective and a matter of taste and familiarity. I don't really like Lua's syntax but from a cognitive load standpoint it's still your average dynamically typed, garbage collected scripting language. Syntax notwithstanding it's easier to code for than C's unmanaged and unchecked runtime or Rust's complex type system and borrow checker. >Situations where configuration files aren't sophisticated enough but a Python interpreter is too heavy are few and far between. That's not the point I was making and I'm not trying to get into a language war between Lua and Python, I have no horse in that race.
Jyaif 8y ago
The one-based indexing is indeed a total waste of time. I've switched to using Wren for my new projets. Despite not being as mature as lua (you may have to add some functionalities yourself): * the syntax is much nicer. * it's simpler/cleaner to embed. * it's (allegedly) faster if you are running on a platform where it's forbidden to JIT (e.g. iOS).
- saagarjha 8y ago
  To be pedantic, it’s not forbidden to JIT on iOS. You can JIT your own code outside of the App Store if you self-sign your app, and you can always take advantage of the JIT that JavaScriptCore offers.
- rebolek 8y ago
  I really don't understand why some people think that C-like syntax can be "nicer". You may be used to it, but it's certainly not nicer in any way and has lot of strange design choices.
  - Jyaif 8y ago
    A couple of concrete examples: * Classes in Lua are a hack, and consequently the syntax for them is terrible. * Using "end" instead of "}". That decreases readability. * no "+=" or "++" operators.
mschuetz 8y ago
> Especially the deeply embedded one-based indexing That's already reason enough for me not to use it. One based indexing caused me so many headaches in the past in Mathematica...
- saagarjha 8y ago
  One-based indexing doesn’t really make sense if you’re not using pointer+offset array indexing. So the only problem I see here is that you can’t directly port code that deals with arrays over from different languages, which is what you should be doing anyways because tables are not arrays.
  - mschuetz 8y ago
    One based indexing isn't just about getting used to it, it makes lots of things a nightmare. Like index-math that involves the modulo operator, which will result in zero values, which are invalid for 1-based indexing. Or turning a 2D or 3D index into a 1D index, which now requires completely unnecessary additions or subtractions of 1s. And other index magic that I frequently need for computer graphics and number crunching.
    - ur-whale 8y ago
      I wholeheartedly agree. As a matter of fact, I had the exact same argument in a Julia thread (modulos don't work, polynomial accesses don't work). It honked off a whole bunch of people who've never had to do any of these things for a living and therefore considered them edge cases. Additionally, for LUA, being one-based while trying to claim it's the scripting language for C inter-operability is quite preposterous.
      - coldtea 8y ago
        >As a matter of fact, I had the exact same argument in a Julia thread (modulos don't work, polynomial accesses don't work). In the same ways that simple for loops "don't work" because we need to e.g. check if i < length - 1 to know if we're at the last element...
sebcat 8y ago
> lack of a separate integer type (chars are strings, ints are floats) > Even bit manipulation requires going through the FFI This, and some of the other things, have not been true for years.
- anilakar 8y ago
  Like I pointed in another post: Welcome to the real world, where 5.1 is still the latest available release on many platforms.
  - boomlinde 8y ago
    The latest release is available in source form. I easily built the library with make generic local Provided that you have a GNU compiler toolchain for the target you should have no problem doing this. If you don't I'm sure there's more effort involved, but ultimately Lua can build with any C99 compliant compiler and most C89 compilers (with the caveat that it can't guarantee that there is a 64-bit integer type in C89).
enriquto 8y ago
> The actual Lua language documentation is provided by another web site that looks like it has been written by an attention-deficit child. How can you say that? The Lua documentation is on par with Kernighan and Ritchie.
dtho 8y ago
Are you criticizing LuaJIT rather than Lua? LuaJIT is a third party implementation of an older version of Lua (with cherry picked features from newer versions). A lot of this criticism is no longer valid for Lua. > lack of a separate integer type (chars are strings, ints are floats) Lua 5.3 introduced integer types. [1] > Even bit manipulation requires going through the FFI. LuaJIT includes a bit manipulation library, but its FFI acceleration is optional. Also, Lua 5.3 introduced bitwise operators. [1] > One cannot even format UTF-8 text Lua 5.3 introduced "basic utf-8 support" [1] although I am not sure to what extent. > The official documentation mostly revolves around C bindings. The actual Lua language documentation is provided by another web site that looks like it has been written by an attention-deficit child Again, I suspect you are criticizing LuaJIT. The actual Lua documentation [2] has never let me down. [1] http://www.lua.org/manual/5.3/readme.html#changes http://www.lua.org/manual/5.3/readme.html#changes [2] http://www.lua.org/manual/5.3/manual.html http://www.lua.org/manual/5.3/manual.html
- anilakar 8y ago
  >Again, I suspect you are criticizing LuaJIT. Nope, plain old Lua 5.1 which is still the newest one can get on many platforms. You're stuck with what you have, not what was released yesterday. >The actual Lua documentation has never let me down. I read the document you linked and found the documentation lacking on anything but basic syntax and C bindings (the chapter on C API comes before the Lua standard library, btw). The standard library function documentation underspecifies parameter types and both return value types and numbers. I find the Lua Short Reference [1] much more accessible than the official documentation. It has the very same information in a much more readable format. >Lua 5.3 introduced "basic utf-8 support" Looking at the documentation you linked, the Unicode support does not integrate with the string library. Walking a UTF-8 string manually character-by-character has never been difficult and Lua 5.3's support doesn't seem to address any other use cases. [1] http://lua-users.org/files/wiki_insecure/users/thomasl/luarefv51.pdf http://lua-users.org/files/wiki_insecure/users/thomasl/luare...
  - mempko 8y ago
    It amazes me how many tech people can't compile projects on their system's. Lua is crazy easy to compile on any system.
jack1243star 8y ago
These are quite unfair arguments against Lua, especially since that you seem to be using it for low level networking code and on embedded systems, which are not really Lua's strong points. (Lua is designed to be embedded as per being a scripting interface to C and other compiled languages.) One based indexing is just a design choice, while it complicates interoperation, I find it justified as Lua tables are actually hash tables, so it would be weird to model it upon memory offsets. It reminds me that I am only dealing with a hashmap with integers as keys. Bitwise and UTF-8 string operations are lacking out of the box, but these are arguably too specialized to be expected in a general scripting language. The patterns are a little underpowered compared to other languages, but it is still quite useful. I suggest looking into LPEG for more complicated operations. Lua 5.3 do have some functions to deal with UTF-8 codepoints. Also, regarding Unicode, I'd rather the PL provide only operations on bytes, and let me decide what "characters" are to be represented. Nearly all PL providing some Unicode facilities fail in different ways, just let me deal with ICU myself if I really need Unicode. Also it is a royal pain in the butt to deal with different encodings, with a language having special "characters" and "strings" constructs. I don't understand the complaint on documentation. It is one of the most practical and clear technical writing that I have seen, if a little terse. Perhaps you mistook the wiki as the main document? (The Lua language manual is an one-page HTML page.)
- mschuetz 8y ago
  > One based indexing is just a design choice, while it complicates interoperation, I find it justified as Lua tables are actually hash tables, so it would be weird to model it upon memory offsets. It reminds me that I am only dealing with a hashmap with integers as keys. One based indexing isn't just about memory offsets or getting used to it, it makes lots of things a nightmare. Like index-math that involves the modulo operator, which will result in zero values, which are invalid for 1-based indexing. Or turning a 2D or 3D index into a 1D index, which now requires completely unnecessary additions or subtractions of 1s. And other index magic that I frequently need for computer graphics and number crunching.
- bsder 8y ago
  > These are quite unfair arguments against Lua, especially since that you seem to be using it for low level networking code and on embedded systems, which are not really Lua's strong points. (Lua is designed to be embedded as per being a scripting interface to C and other compiled languages.) If this is true, and I actually agree with you, then where is Lua actually better than an alternative? And, while I don't share the specific points of the parent poster, I experienced similar issues with Lua. I found that while the Lua core language itself is small, I had to compile in so much extra stuff to make it useful that it wasn't actually small anymore. And, once you get large enough that you start demanding big ARM Cortex M4 microcontrollers, Python is now in your scope.
__s 8y ago
Your complaints are mostly addressed in Lua 5.3 (64 bit integers, utf8 in stdlib, bitwise ops) & many would suggest you use LPeg if you're itching for non trivial string manipulation Also the documentation provided by lua.org is quite accessible: https://www.lua.org/manual/5.3 https://www.lua.org/manual/5.3 What I'd really like is stdlib to provide a Buffer type, as opposed to having to use a table of integers which then gets pushed into a string with chunked calls to string.char(table.unpack(buf, n, n+4096)) Example of what I'm complaining about: https://github.com/serprex/luwa/blob/master/rt/make.lua#L758 https://github.com/serprex/luwa/blob/master/rt/make.lua#L758 So all said I don't disagree with you: Lua can fall short, it doesn't have the community other languages have built up, & the community it has is rather fractured. Like LuaJIT making 5.2 what most call Lua, but also that being an extension language it's hard to upgrade without losing compatibility, so projects like Redis can't upgrade without deprecating 5.2 for a 5.3 version & making some method to signal 5.3 & then eventually removing 5.2 while packaging both in the interim
StreamBright 8y ago
You are implying that the problems that you were facing would be a problem for every potential Lua user. This is certainly not the case. The biggest use of Lua is scripting for games and non of the shortcomings you mentioned relevant in that context. Other than that, as others pointed out, most of your complaints are addressed in 5.3.
int_19h 8y ago
> The official documentation mostly revolves around C bindings. The actual Lua language documentation is provided by another web site that looks like it has been written by an attention-deficit child. This is such an unfair point. Lua has a single manual that covers the language, the standard library, and yes, it also covers C FFI (unsurprisingly for an extensibility / scripting language), but FFI actually comes after the language in the docs. And the manual is both very readable and very thorough where it talks about the language - it's quite easy to learn the whole thing just from it alone.
unsigner 8y ago
We do serious networking in Lua, but it's on top of C socket code (implemented using IOCP or epoll) that transparently serializes, compresses and encrypts Lua tuples to bytes on one and, and decrypts, decompresses and deserializes bytes to Lua tuples on the other. This is the backend of a real time game (multiple messages from each player per second), and we handle on the order of 10k connections per core. The "actual Lua language documentation" you refer to probably is the wiki? I agree it is crap. By all means, stay away from Lua and use Python and Node for new projects; we like that competitive advantage.
- lifthrasiir 8y ago
  > This is the backend of a real time game (multiple messages from each player per second), and we handle on the order of 10k connections per core. I pretty much agree that Lua can survive such throughput, but I question whether Lua can survive the code complexity. I have written about Lua previously on [1] with a vocal conclsion that Lua cannot really handle a large code base (in the order of 10^5 lines), so I like to hear otherwise (hint: I hadn't). That's why... > By all means, stay away from Lua and use Python and Node for new projects; [...] ...we have ultimately dropped (a heavy duty use of) Lua from all new projects. C# seems to suit our needs (or any other statically & strongly typed languages---obviously excluding C/C++---would probably do). [1] https://news.ycombinator.com/item?id=13902023 https://news.ycombinator.com/item?id=13902023
  - unsigner 8y ago
    > I have written about Lua previously on [1] with a vocal conclsion that Lua cannot really handle a large code base (in the order of 10^5 lines), so I like to hear otherwise (hint: I hadn't). That's why... We have shipped and maintain a series of games built on progressive iterations of the same codebase; we have on the order of 200 KLOCs of Lua in the common "engine" code and tooling, and 200-400 KLOCs additional game-specific code per game. We tend to hit our milestones and performance targets on six platforms, with programmer quality of life way above the game industry "standards" (i.e. we do normal working hours). Can things be better? Of course, they always can. But om our experience, large-scale use of Lua is not the disaster it usually is assumed/predicted to be.
deleted 8y ago
[deleted]

saagarjha 8y ago

C and Rust solve different problems. They’re compiled, for one.

anilakar 8y ago
C and Rust solve exactly the same problems as any other programming language in the embedded context: they try to interface with real world. Whether they're compiled or not rarely matters, when software updates are done by reflashing the whole device. Edit: If you have a device with enough computing power to run a scripting language interpreter, you can use Python in most cases.
- simias 8y ago
  I agree with the parent, C and Rust are not scripting languages, Lua is. The frontier between what does and does not constitute scripting is admittedly blurry these days but in the case of these languages it's fairly clear cut IMO. Lua is very dynamic, easy to code for (syntactical quirks aside, I'm talking from a "cognitive load" standpoint) while C and especially Rust are a lot more static, require more careful coding but can result in faster and, at least in the case of Rust, more robust code. Lua is the type of language you embed in your C app to make it configurable.
  - anilakar 8y ago
    >easy to code for (syntactical quirks aside, I'm talking from a "cognitive load" standpoint) That's not a fair comparison. A large chunk of the cognitive load comes from the awkward syntax and other design decisions that stem from it. >Lua is the type of language you embed in your C app to make it configurable. Situations where configuration files aren't sophisticated enough but a Python interpreter is too heavy are few and far between.
    - simias 8y ago
      Syntax is very subjective and a matter of taste and familiarity. I don't really like Lua's syntax but from a cognitive load standpoint it's still your average dynamically typed, garbage collected scripting language. Syntax notwithstanding it's easier to code for than C's unmanaged and unchecked runtime or Rust's complex type system and borrow checker. >Situations where configuration files aren't sophisticated enough but a Python interpreter is too heavy are few and far between. That's not the point I was making and I'm not trying to get into a language war between Lua and Python, I have no horse in that race.

Jyaif 8y ago

The one-based indexing is indeed a total waste of time. I've switched to using Wren for my new projets. Despite not being as mature as lua (you may have to add some functionalities yourself): * the syntax is much nicer. * it's simpler/cleaner to embed. * it's (allegedly) faster if you are running on a platform where it's forbidden to JIT (e.g. iOS).

saagarjha 8y ago
To be pedantic, it’s not forbidden to JIT on iOS. You can JIT your own code outside of the App Store if you self-sign your app, and you can always take advantage of the JIT that JavaScriptCore offers.
rebolek 8y ago
I really don't understand why some people think that C-like syntax can be "nicer". You may be used to it, but it's certainly not nicer in any way and has lot of strange design choices.
- Jyaif 8y ago
  A couple of concrete examples: * Classes in Lua are a hack, and consequently the syntax for them is terrible. * Using "end" instead of "}". That decreases readability. * no "+=" or "++" operators.

mschuetz 8y ago

> Especially the deeply embedded one-based indexing That's already reason enough for me not to use it. One based indexing caused me so many headaches in the past in Mathematica...

saagarjha 8y ago
One-based indexing doesn’t really make sense if you’re not using pointer+offset array indexing. So the only problem I see here is that you can’t directly port code that deals with arrays over from different languages, which is what you should be doing anyways because tables are not arrays.
- mschuetz 8y ago
  One based indexing isn't just about getting used to it, it makes lots of things a nightmare. Like index-math that involves the modulo operator, which will result in zero values, which are invalid for 1-based indexing. Or turning a 2D or 3D index into a 1D index, which now requires completely unnecessary additions or subtractions of 1s. And other index magic that I frequently need for computer graphics and number crunching.
  - ur-whale 8y ago
    I wholeheartedly agree. As a matter of fact, I had the exact same argument in a Julia thread (modulos don't work, polynomial accesses don't work). It honked off a whole bunch of people who've never had to do any of these things for a living and therefore considered them edge cases. Additionally, for LUA, being one-based while trying to claim it's the scripting language for C inter-operability is quite preposterous.
    - coldtea 8y ago
      >As a matter of fact, I had the exact same argument in a Julia thread (modulos don't work, polynomial accesses don't work). In the same ways that simple for loops "don't work" because we need to e.g. check if i < length - 1 to know if we're at the last element...

sebcat 8y ago

> lack of a separate integer type (chars are strings, ints are floats) > Even bit manipulation requires going through the FFI This, and some of the other things, have not been true for years.

anilakar 8y ago
Like I pointed in another post: Welcome to the real world, where 5.1 is still the latest available release on many platforms.
- boomlinde 8y ago
  The latest release is available in source form. I easily built the library with make generic local Provided that you have a GNU compiler toolchain for the target you should have no problem doing this. If you don't I'm sure there's more effort involved, but ultimately Lua can build with any C99 compliant compiler and most C89 compilers (with the caveat that it can't guarantee that there is a 64-bit integer type in C89).

enriquto 8y ago

> The actual Lua language documentation is provided by another web site that looks like it has been written by an attention-deficit child. How can you say that? The Lua documentation is on par with Kernighan and Ritchie.

dtho 8y ago

Are you criticizing LuaJIT rather than Lua? LuaJIT is a third party implementation of an older version of Lua (with cherry picked features from newer versions). A lot of this criticism is no longer valid for Lua. > lack of a separate integer type (chars are strings, ints are floats) Lua 5.3 introduced integer types. [1] > Even bit manipulation requires going through the FFI. LuaJIT includes a bit manipulation library, but its FFI acceleration is optional. Also, Lua 5.3 introduced bitwise operators. [1] > One cannot even format UTF-8 text Lua 5.3 introduced "basic utf-8 support" [1] although I am not sure to what extent. > The official documentation mostly revolves around C bindings. The actual Lua language documentation is provided by another web site that looks like it has been written by an attention-deficit child Again, I suspect you are criticizing LuaJIT. The actual Lua documentation [2] has never let me down. [1] http://www.lua.org/manual/5.3/readme.html#changes http://www.lua.org/manual/5.3/readme.html#changes [2] http://www.lua.org/manual/5.3/manual.html http://www.lua.org/manual/5.3/manual.html

anilakar 8y ago
>Again, I suspect you are criticizing LuaJIT. Nope, plain old Lua 5.1 which is still the newest one can get on many platforms. You're stuck with what you have, not what was released yesterday. >The actual Lua documentation has never let me down. I read the document you linked and found the documentation lacking on anything but basic syntax and C bindings (the chapter on C API comes before the Lua standard library, btw). The standard library function documentation underspecifies parameter types and both return value types and numbers. I find the Lua Short Reference [1] much more accessible than the official documentation. It has the very same information in a much more readable format. >Lua 5.3 introduced "basic utf-8 support" Looking at the documentation you linked, the Unicode support does not integrate with the string library. Walking a UTF-8 string manually character-by-character has never been difficult and Lua 5.3's support doesn't seem to address any other use cases. [1] http://lua-users.org/files/wiki_insecure/users/thomasl/luarefv51.pdf http://lua-users.org/files/wiki_insecure/users/thomasl/luare...
- mempko 8y ago
  It amazes me how many tech people can't compile projects on their system's. Lua is crazy easy to compile on any system.

jack1243star 8y ago

These are quite unfair arguments against Lua, especially since that you seem to be using it for low level networking code and on embedded systems, which are not really Lua's strong points. (Lua is designed to be embedded as per being a scripting interface to C and other compiled languages.) One based indexing is just a design choice, while it complicates interoperation, I find it justified as Lua tables are actually hash tables, so it would be weird to model it upon memory offsets. It reminds me that I am only dealing with a hashmap with integers as keys. Bitwise and UTF-8 string operations are lacking out of the box, but these are arguably too specialized to be expected in a general scripting language. The patterns are a little underpowered compared to other languages, but it is still quite useful. I suggest looking into LPEG for more complicated operations. Lua 5.3 do have some functions to deal with UTF-8 codepoints. Also, regarding Unicode, I'd rather the PL provide only operations on bytes, and let me decide what "characters" are to be represented. Nearly all PL providing some Unicode facilities fail in different ways, just let me deal with ICU myself if I really need Unicode. Also it is a royal pain in the butt to deal with different encodings, with a language having special "characters" and "strings" constructs. I don't understand the complaint on documentation. It is one of the most practical and clear technical writing that I have seen, if a little terse. Perhaps you mistook the wiki as the main document? (The Lua language manual is an one-page HTML page.)

mschuetz 8y ago
> One based indexing is just a design choice, while it complicates interoperation, I find it justified as Lua tables are actually hash tables, so it would be weird to model it upon memory offsets. It reminds me that I am only dealing with a hashmap with integers as keys. One based indexing isn't just about memory offsets or getting used to it, it makes lots of things a nightmare. Like index-math that involves the modulo operator, which will result in zero values, which are invalid for 1-based indexing. Or turning a 2D or 3D index into a 1D index, which now requires completely unnecessary additions or subtractions of 1s. And other index magic that I frequently need for computer graphics and number crunching.
bsder 8y ago
> These are quite unfair arguments against Lua, especially since that you seem to be using it for low level networking code and on embedded systems, which are not really Lua's strong points. (Lua is designed to be embedded as per being a scripting interface to C and other compiled languages.) If this is true, and I actually agree with you, then where is Lua actually better than an alternative? And, while I don't share the specific points of the parent poster, I experienced similar issues with Lua. I found that while the Lua core language itself is small, I had to compile in so much extra stuff to make it useful that it wasn't actually small anymore. And, once you get large enough that you start demanding big ARM Cortex M4 microcontrollers, Python is now in your scope.

__s 8y ago

Your complaints are mostly addressed in Lua 5.3 (64 bit integers, utf8 in stdlib, bitwise ops) & many would suggest you use LPeg if you're itching for non trivial string manipulation Also the documentation provided by lua.org is quite accessible: https://www.lua.org/manual/5.3 https://www.lua.org/manual/5.3 What I'd really like is stdlib to provide a Buffer type, as opposed to having to use a table of integers which then gets pushed into a string with chunked calls to string.char(table.unpack(buf, n, n+4096)) Example of what I'm complaining about: https://github.com/serprex/luwa/blob/master/rt/make.lua#L758 https://github.com/serprex/luwa/blob/master/rt/make.lua#L758 So all said I don't disagree with you: Lua can fall short, it doesn't have the community other languages have built up, & the community it has is rather fractured. Like LuaJIT making 5.2 what most call Lua, but also that being an extension language it's hard to upgrade without losing compatibility, so projects like Redis can't upgrade without deprecating 5.2 for a 5.3 version & making some method to signal 5.3 & then eventually removing 5.2 while packaging both in the interim

StreamBright 8y ago

You are implying that the problems that you were facing would be a problem for every potential Lua user. This is certainly not the case. The biggest use of Lua is scripting for games and non of the shortcomings you mentioned relevant in that context. Other than that, as others pointed out, most of your complaints are addressed in 5.3.

int_19h 8y ago

> The official documentation mostly revolves around C bindings. The actual Lua language documentation is provided by another web site that looks like it has been written by an attention-deficit child. This is such an unfair point. Lua has a single manual that covers the language, the standard library, and yes, it also covers C FFI (unsurprisingly for an extensibility / scripting language), but FFI actually comes after the language in the docs. And the manual is both very readable and very thorough where it talks about the language - it's quite easy to learn the whole thing just from it alone.

unsigner 8y ago

We do serious networking in Lua, but it's on top of C socket code (implemented using IOCP or epoll) that transparently serializes, compresses and encrypts Lua tuples to bytes on one and, and decrypts, decompresses and deserializes bytes to Lua tuples on the other. This is the backend of a real time game (multiple messages from each player per second), and we handle on the order of 10k connections per core. The "actual Lua language documentation" you refer to probably is the wiki? I agree it is crap. By all means, stay away from Lua and use Python and Node for new projects; we like that competitive advantage.

lifthrasiir 8y ago
> This is the backend of a real time game (multiple messages from each player per second), and we handle on the order of 10k connections per core. I pretty much agree that Lua can survive such throughput, but I question whether Lua can survive the code complexity. I have written about Lua previously on [1] with a vocal conclsion that Lua cannot really handle a large code base (in the order of 10^5 lines), so I like to hear otherwise (hint: I hadn't). That's why... > By all means, stay away from Lua and use Python and Node for new projects; [...] ...we have ultimately dropped (a heavy duty use of) Lua from all new projects. C# seems to suit our needs (or any other statically & strongly typed languages---obviously excluding C/C++---would probably do). [1] https://news.ycombinator.com/item?id=13902023 https://news.ycombinator.com/item?id=13902023
- unsigner 8y ago
  > I have written about Lua previously on [1] with a vocal conclsion that Lua cannot really handle a large code base (in the order of 10^5 lines), so I like to hear otherwise (hint: I hadn't). That's why... We have shipped and maintain a series of games built on progressive iterations of the same codebase; we have on the order of 200 KLOCs of Lua in the common "engine" code and tooling, and 200-400 KLOCs additional game-specific code per game. We tend to hit our milestones and performance targets on six platforms, with programmer quality of life way above the game industry "standards" (i.e. we do normal working hours). Can things be better? Of course, they always can. But om our experience, large-scale use of Lua is not the disaster it usually is assumed/predicted to be.

deleted 8y ago

[deleted]