6 ms·
I don't love a good deal of Lua's syntax, but I do think the authors had good reasons for their choices and have generally explained them. Even if you disagree,
by norir 10mo ago
I don't love a good deal of Lua's syntax, but I do think the authors had good reasons for their choices and have generally explained them. Even if you disagree, I think "without good reasons" is overly dismissive.
Personally though, I think the distinctive choices are a boon. You are never confused about what language you are writing because Lua code is so obviously Lua. There is value in this. Once you have written enough Lua, your mind easily switches in and out of Lua mode. Javascript, on the other hand, is filled with poor semantic decisions which for me, cancel out any benefits from syntactic familiarity.
More importantly, Lua has a crucial feature that Javascript lacks: tail call optimization. There are programs that I can easily write in Lua, in spite of its syntactic verbosity, that I cannot write in Javascript because of this limitation. Perhaps this particular JS implementation has tco, but I doubt it reading the release notes.
I have learned as much from Lua as I have Forth (SmallTalk doesn't interest me) and my programming skill has increased significantly since I switched to it as my primary language. Lua is the only lightweight language that I am aware of with TCO. In my programs, I have banned the use of loops. This is a liberation that is not possible in JS or even c, where TCO cannot be relied upon.
In particular, Lua is an exceptional language for writing compilers. Compilers are inherently recursive and thus languages lacking TCO are a poor fit (even if people have been valiantly forcing that square peg through a round hole for all this time).
Having said all that, perhaps as a scripting language for Redis, JS is a better fit. For me though Lua is clearly better than JS on many different dimensions and I don't appreciate the needless denigration of Lua, especially from someone as influential as you.
- lioeters 10mo ago> as my primary language I'd love to hear more how it is, the state of the library ecosystem, language evolution (wasn't there a new major version recently?), pros/cons, reasons to use it compared to other languages. About tail-calls, in other languages I've found sometimes a conversion of recursive algorithm to a flat iterative loop with stack/queue to be effective. But it can be a pain, less elegant or intuitive than TCO.
- alexdowad 10mo agoLua isn't my primary programming language now, but it was for a while. My personal experience on the library ecosystem was: It's definitely smaller than many languages, and this is something to consider before selecting Lua for a project. But, on the positive side: With some 'other' languages I might find 5 or 10 libraries all doing more or less the same thing, many of them bloated and over-engineered. But with Lua I would often find just one library available, and it would be small and clean enough that I could easily read through its source code and know exactly how it worked. Another nice thing about Lua when run on LuaJIT: extremely high CPU performance for a scripting language. In summary: A better choice than it might appear at first, but with trade-offs which need serious consideration.
- tracker1 10mo agoYeah, you can usually write a TCO based algorithm differently without recursion though it's often more messy of an implementation... In practice, with JS, I find that if I know I'm going to wind up more/less than 3-4 calls deep I'll optimize or not to avoid the stack overflow. Also worth noting that some features in JS may rely on application/environment support and may raise errors that you cannot catch in JS code. This is often fun to discover and painful to try to work around.
- xonix 10mo agoRe: TCO Does the language give any guarantee that TCO was applied? In other words can it give you an error that the recursion is not of tail call form? Because I imagine a probability of writing a recursion and relying on it being TCO-optimized, where it's not. I would prefer if a language had some form of explicit TCO modifier for a function. Is there any language that has this?
- stellartux 10mo agoSounds a bit like Clojure's "recur". https://clojuredocs.org/clojure.core/recur https://clojuredocs.org/clojure.core/recur
- ZiiS 10mo agoAt least in Lua then the rule is simply 'last thing a function dose' this is unambiguous. `return f()` is always a tail call and `return f() + 1` never is.
- deleted 10mo ago[deleted]
- normie3000 10mo agoWhat about: return 1 + f() ?
- ZiiS 10mo agoNo, the last thing is the +; which can't run till it knows both values. (Reverse Polish notation is clearer, but humans prefer infix operators for some reason)
- draven 10mo agoScala has the @tailrec annotation which will raise a warning if the function can’t be TCO’d
- alexisread 10mo agoAlthough it’s a bit weird, Able Forth has the explicit word ~ https://github.com/ablevm/able-forth/blob/current/forth.scr https://github.com/ablevm/able-forth/blob/current/forth.scr I do prefer this as it keeps the language more regular (fewer surprises)
- shawn_w 10mo ago>Lua is the only lightweight language that I am aware of with TCO. Scheme is pretty lightweight.
- bch 10mo agoTcl too, fwiw[0]. [0] https://wiki.tcl-lang.org/page/NRE https://wiki.tcl-lang.org/page/NRE
- shawn_w 10mo agoTcl needs a special command for tail calls though, instead of it Just Working (tm). It's kind of awkward.
- fnord123 10mo agoWhich scheme implementation? Guile?
- deleted 10mo ago[deleted]
- NuclearPM 10mo agoAll of them.
- unclad5968 10mo ago> I do think the authors had good reasons for their choices and have generally explained them I'm fairly certain antirez is the author of redis
- rapind 10mo agoPretty sure he's talking about Lua's authors.
- pedroza_alex 10mo agoThe word "authors" in that phrase refers to the authors of Lua, not Redis.
- bakkoting 10mo agoFormally JavaScript is specified as having TCO as of ES6, although for unfortunate and painful reasons this is spec fiction - Safari implements it, but Firefox and Chrome do not. Neither did QuickJS last I checked and I don't think this does either.
- deleted 10mo ago[deleted]
- tracker1 10mo agoES is now ES2025, not ES6/2015. There are still platforms that don't even fully implement enough to shim out ES5 completely, let alone ES6+. Portions of ES6 require buy in from the hosting/runtime environment that aren't even practical for some environments... so I feel the statement itself is kind of ignorant.
- teo_zero 10mo ago> Lua has a crucial feature that Javascript lacks: tail call optimization. I'm not familiar with Lua, but I expect tco to be a feature of the compiler, not of the language. Am I wrong?
- naasking 10mo agoIf the language spec requires TCO, I think you can reasonably call it part of the language.
- teo_zero 10mo agoIt wouldn't be the first time the specs have gone too far and beyond their perimeter. C's "register" variables used to have the same issue, and even "inline" has been downgraded to a mere hint for the compiler (which can ignore it and still be a C compiler).
- tracker1 10mo agoIIRC, ES6+ includes TCO, but no actual implementation/engine has implemented it.
- graftak 9mo agoSafari has
- kerkeslager 10mo ago
- kbenson 10mo ago> For me though Lua is clearly better than JS on many different dimensions and I don't appreciate the needless denigration of Lua, especially from someone as influential as you. Is it needless? It's useful specifically because he is someone influential, and someone might say "Lua was antirez's choice when making redis, and I trust and respect his engineering, so I'm going to keep Lua as a top contender for use in my project because of that" and him being clear on his choices and reasoning is useful in that respect. In any case where you think he has a responsibility to be careful what he says because of that influence, that can also be used in this case as a reason he should definitely explain his thoughts on it then and now.
- kerkeslager 10mo ago> More importantly, Lua has a crucial feature that Javascript lacks: tail call optimization. There are programs that I can easily write in Lua, in spite of its syntactic verbosity, that I cannot write in Javascript because of this limitation. Perhaps this particular JS implementation has tco, but I doubt it reading the release notes. > [...] In my programs, I have banned the use of loops. This is a liberation that is not possible in JS or even c, where TCO cannot be relied upon. This is not a great language feature, IMO. There are two ways to go here: 1. You can go the Python way, and have no TCO, not ever. Guido van Rossum's reasoning on this is outlined here[1] and here[2], but the high level summary is that TCO makes it impossible to provide acceptably-clear tracebacks. 2. You can go the Chicken Scheme way, and do TCO, and ALSO do CPS conversion, which makes EVERY call into a tail call, without language user having to restructure their code to make sure their recursion happens at the tail. Either of these approaches has its upsides and downsides, but TCO WITHOUT CPS conversion gives you the worst of both worlds. The only upside is that you can write most of your loops as recursion, but as van Rossum points out, most cases that can be handled with tail recursion, can AND SHOULD be handled with higher-order functions. This is just a much cleaner way to do it in most cases. And the downsides to TCO without CPS conversion are: 1. Poor tracebacks. 2. Having to restructure your code awkwardly to make recursive calls into tail calls. 3. Easy to make a tail call into not a tail call, resulting in stack overflows. I'll also add that the main reason recursion is preferable to looping is that it enables all sorts of formal verification. There's some tooling around formal verification for Scheme, but the benefits to eliminating loops are felt most in static, strongly typed languages like Haskell or OCaml. As far as I know Lua has no mature tooling whatsoever that benefits from preferring recursion over looping. It may be that the author of the post I am responding to finds recursion more intuitive than looping, but my experience contains no evidence that recursion is inherently more intuitive than looping: which is more intuitive appears to me to be entirely a function of the programmer's past experience. In short, treating TCO without CPS conversion as a killer feature seems to me to be a fetishization of functional programming without understanding why functional programming is effective, embracing the madness with none of the method. EDIT: To point out a weakness to my own argument: there are a bunch of functional programming language implementations that implement TCO without CPS conversion. I'd counter by saying that this is a function of when they were implemented/standardized. Requiring CPS conversion in the Scheme standard would pretty clearly make Scheme an easier to use language, but it would be unreasonable in 2025 to require CPS conversion because so many Scheme implementations don't have it and don't have the resources to implement it. EDIT 2: I didn't mean for this post to come across as negative on Lua: I love Lua, and in my hobby language interpreter I've been writing, I have spent countless hours implementing ideas I got from Lua. Lua has many strengths--TCO just isn't one of them. When I'm writing Scheme and can't use a higher-order function, I use TCO. When I'm writing Lua and can't use a higher order function, I use loops. And in both languages I'd prefer to use a higher order function. [1] https://neopythonic.blogspot.com/2009/04/tail-recursion-elimination.html https://neopythonic.blogspot.com/2009/04/tail-recursion-elim... [2] https://neopythonic.blogspot.com/2009/04/final-words-on-tail-calls.html https://neopythonic.blogspot.com/2009/04/final-words-on-tail...
- ksec 10mo ago> I think the distinctive choices are a boon. You are never confused about what language you are writing because Lua code is so obviously Lua. There is value in this. This. And not just Lua , but having different kind of syntax for scripting languages or very high level languages signal it is something entirely different, and not C as in system programming language. The syntax is also easier for people who dont intend to make programming as their profession, but simply want something done. It used to be the case in the old days people would design simple PL for new beginners, ActionScript / Flash era and even Hypercard before that. Unfortunately the industry is no longer interested in it, and if anything intend to make every as complicated as possible.
- vanviegen 10mo agoI do not think your compiler argument in support of TCO is very convincing. Do you really need to write compilers with limitless nesting? Or is nesting, say, 100.000 deep enough, perhaps? Also, you'll usually want to allocate some data structure to create an AST for each level. So that means you'll have some finite limit anyway. And that limit is a lot easier to hit in the real world, as it applies not just to nesting depth, but to the entire size of your compilation unit.
- lpribis 10mo agoTCO is not just for parse trees or AST, but in imperative languages without TCO this is the only place you are "forced" to use recursion. You can transform any loop in you program to recursion if you prefer, which is what the author does.
- znpy 10mo agoNo offence but it seems that all of the people that are replying to this comment are essentially screaming in the void, if anything among each other. I scrolled most of this sub thread and gp seem to not be replying to any of the replies they got.
- jacobs101 10mo ago[dead]
- justin66 10mo ago> In my programs, I have banned the use of loops. Rather, you no longer see what they're doing clearly.
- TimTheTinker 10mo agoThere's value in both implicit and explicit loops. Some highly recursive programming styles are really just using the call stack as a data structure... which is valid but can be restrictive.
- jimbokun 10mo agoHow so? I suppose if you don’t understand recursion.
- hajile 10mo agoJS has required proper tail calls (PTC) for a decade now. Safari's JavascriptCore and almost every implementation except v8/spidermonkey (and the now defunct chakra) have PTC. v8 had PTC, but removed it because they insisted it MUST have a new tail call keyword. When they were shot down, they threw a childish fit and removed the PTC from their JIT.