8 ms·
If this had been available in 2010, Redis scripting would have been JavaScript and not Lua. Lua was chosen based on the implementation requirements, not on the
by antirez 10mo ago
If this had been available in 2010, Redis scripting would have been JavaScript and not Lua. Lua was chosen based on the implementation requirements, not on the language ones... (small, fast, ANSI-C). I appreciate certain ideas in Lua, and people love it, but I was never able to like Lua, because it departs from a more Algol-like syntax and semantics without good reasons, for my taste. This creates friction for newcomers. I love friction when it opens new useful ideas and abstractions that are worth it, if you learn SmallTalk or FORTH and for some time you are lost, it's part of how the languages are different. But I think for Lua this is not true enough: it feels like it departs from what people know without good reasons.
- cxr 10mo agoIt wouldn't fix the issue of semantics, but "language skins"[1][2] are an underexplored area of programming language development. People go through all this effort to separate parsing and lexing, but never exploit the ability to just plug in a different lexer that allows for e.g. "{" and "}" tokens instead of "then" and "end", or vice versa. 1. <https://hn.algolia.com/?type=comment&prefix=true&query=cxr%20language%20skin https://hn.algolia.com/?type=comment&prefix=true&query=cxr%2...> 2. <https://old.reddit.com/r/Oberon/comments/1pcmw8n/is_this_sacrilege/nt18w18/?context=3 https://old.reddit.com/r/Oberon/comments/1pcmw8n/is_this_sac...>
- nine_k 10mo agoNot "never exploit"; Reason and BuckleScript are examples of different "language skins" for OCaml. The problem with "skins" is that they create variety where people strive for uniformity to lower the cognitive load. OTOH transparent switching between skins (about as easy as changing the tab sizes) would alleviate that.
- cibyr 10mo agoPeople fight about tab sizes all the time though.
- dbdr 10mo agoThat's precisely the point of using tabs for indentation: you don't need to fight over it, because it's a local display preference that does not affect the source code at all, so everyone can just configure whatever they prefer locally without affecting other people. The idea of "skins" is apparently to push that even further by abstracting the concrete syntax.
- lucketone 10mo ago> you don't need to fight over it, because it's a local display preference This has limits. Files produced with tab=2 and others with tab=8, might have quite different result regarding nesting. (pain is still on the menu)
- philsnow 10mo agoDo you mean that files produced with "wide" tabs might have hard newlines embedded more readily in longer lines? Or that maybe people writing with "narrow" tabs might be comfortable writing 6-deep if/else trees that wrap when somebody with their tabs set to wider opens the same file?
- fc417fc802 10mo agoI don't see why? Your window width will presumably be tailored to accommodate common scenarios in your preferred tab width. More than that, in the general case for common C like languages things should almost never be nested more than a few levels deep. That's usually a sign of poorly designed and difficult to maintain code. Lisps are a notable exception here, but due to limitations (arguably poor design) with how the most common editors handle lines that contain a mix of tabs and spaces you're pretty much forced to use only spaces when writing in that family of languages. If anything that language family serves as case in point - code written with an indentation width that isn't to one's preference becomes much more tedious to adapt due to alternating levels of alignment and indentation all being encoded as spaces (ie loss of information which automated tools could otherwise use).
- brabel 10mo ago> OTOH transparent switching between skins (about as easy as changing the tab sizes) would alleviate that. That's one of my hopes for the future of the industry: people will be able to just choose the code style and even syntax family (which you're calling skin) they prefer when editing code, and it will be saved in whatever is the "default" for the language (or even something like the Unison Language: store the AST directly which allows cool stuff like de-duplicating definitions and content-addressable code - an idea I first found out on the amazing talk by Joe Armstrong, "The mess we're in" [1]). Rust, in particular, would perhaps benefit a lot given how a lot of people hate its syntax... but also Lua for people who just can't stand the Pascal-like syntax and really need their C-like braces to be happy. [1] https://www.youtube.com/watch?v=lKXe3HUG2l4 https://www.youtube.com/watch?v=lKXe3HUG2l4
- nine_k 10mo agoAlso consider translation to non-English languages, including different writing and syntax systems (e.g. Arabic or Japanese). Some languages have tools for more or less straightforward skinning. Clojure to Tamil: https://github.com/echeran/clj-thamil/blob/master/src/clj_thamil/%E0%AE%AE%E0%AF%8A%E0%AE%B4%E0%AE%BF%E0%AE%AF%E0%AE%BF%E0%AE%AF%E0%AE%B2%E0%AF%8D.cljc https://github.com/echeran/clj-thamil/blob/master/src/clj_th... C++ to distorted Russian: https://sizeof.livejournal.com/23169.html https://sizeof.livejournal.com/23169.html
- deleted 10mo ago[deleted]
- dualogy 10mo ago> transparent switching between skins (about as easy as changing the tab sizes) One of my pet "not today but some day" project ideas. In my case, I wanted to give Python/Gdscript syntax to any & all the curly languages (a potential boon to all users of non-Anglo keyboard layouts), one by one, via VSCode extension that implements a virtual filesystem over the real one which translates back & forth the syntaxes during the load/edit/save cycle. Then the whole live LSP background running for the underlying real source files and resurfacing that in the same extension with line-number matchings etc. Anyone, please steal this idea and run with it, I'm too short on time for it for now =)
- Orygin 10mo agoI want to do the opposite: Give curly braces to all the indentation based languages. Explicit is better than implicit, auto format is better than guessing why some block of code was executed outside my if statement.
- xigoi 10mo agoIndentation is just as explicit as braces.
- scns 10mo agoI wanted to give Python/Gdscript syntax to any & all the curly languages (a potential boon to all users of non-Anglo keyboard layouts) Neo makes it really easy to type those https://neo-layout.org https://neo-layout.org
- procaryote 10mo agoLowering the barrier to create your own syntax seems like a bad thing though. C.f. perl.
- rao-v 10mo agoOne day Brython (python with braces allowing copy paste code to autoindent) will be well supported by LSPs and world peace will ensure
- twic 10mo agoSyntaxError: not a chance
- xigoi 10mo agoWhat editor are you using that does not have a way to paste code with proper indentation?
- rao-v 9mo agoThere is not enough information in pasted code for a language server to indent pasted in python code. Try copy pasting a random stackoverflow snippet into deeply indented python code.
- xigoi 9mo agoWhy would you need a language server for that? You simply prepend the indentation of the current line to every line of the pasted text.
- kevin_thibedeau 10mo agoVB.Net is mostly a reskin of C# with a few extras to smooth the transition from VB.
- IshKebab 10mo agoNot to mention the 1-based indexing sin. JavaScript has a lot of WTFs but they got that right at least.
- idle_zealot 10mo agoDoes it count as 0-indexing when your 0 is a floating point number?
- krackers 10mo agoActually in JS array indexing is same as property indexing right? So it's actually looking up the string '0', as in arr['0']
- idle_zealot 10mo agoHuh. I always thought that JS objects supported string and number keys separately, like lua. Nope! [Documents]$ cat test.js let testArray = []; testArray[0] = "foo"; testArray["0"] = "bar"; console.log(testArray[0]); console.log(testArray["0"]); [Documents]$ jsc test.js bar bar [Documents]$
- aidenn0 10mo agoThey do, but strings that are numbers will be reinterpreted as numbers. [edit] let testArray = []; testArray[0] = "foo"; testArray["0"] = "bar"; testArray["00"] = "baz"; console.log(testArray[0]); console.log(testArray["0"]); console.log(testArray["00"]);
- minitech 10mo agoThat example only shows the opposite of what it sounds like you’re saying, although you could be getting at a few different true things. Anyway: - Every property access in JavaScript is semantically coerced to a string (or a symbol, as of ES6). All property keys are semantically either strings or symbols. - Property names that are the ToString() of a 31-bit unsigned integer are considered indexes for the purposes of the following two behaviours: - For arrays, indexes are the elements of the array. They’re the properties that can affect its `length` and are acted on by array methods. - Indexes are ordered in numeric order before other properties. Other properties are in creation order. (In some even nicher cases, property order is implementation-defined.) { let a = {}; a['1'] = 5; a['0'] = 6; Object.keys(a) } // ['0', '1'] { let a = {}; a['1'] = 5; a['00'] = 6; Object.keys(a) } // ['1', '00']
- rweichler 10mo agoI read this comment, about to snap back with an anecdote how I as a 13 year old was able to learn Lua quite easily, and then I stopped myself because that wasn't productive, then pondered what antirez might think of this comment, and then I realized that antirez wrote it.
- aidenn0 10mo agoI think the older you are the harder Lua is to learn. GP didn't say it made wrong choices, just choices that are gratuitously different from other languages in the Algol family.
- le-mark 10mo agoI’m tickled that one of my favorite developers is commenting on another of my favorites work. Would be great if Nicolas Cannasse were also in this thread!
- brabel 10mo ago> it feels like it departs from what people know without good reasons. Lua was first released in 1993. I think that it's pretty conventional for the time, though yeah it did not follow Algol syntax but Pascal's and Ada's (which were more popular in Brazil at the time than C, which is why that is the case)! Ruby, which appeared just 2 years later, departs a lot more, arguably without good reasons either? Perl, which is 5 years older and was very popular at the time, is much more "different" than Lua from what we now consider mainstream.
- rwmj 10mo agoWe had a lot problems embedding Ruby in a multithreaded C program as the garbage collector tries to scan memory between the threads (more details here: https://gitlab.com/nbdkit/nbdkit/-/commit/7364cbaae809b5ffb6b4dd847cbdd0b368a20024 https://gitlab.com/nbdkit/nbdkit/-/commit/7364cbaae809b5ffb6... ) Perl, Python, OCaml, Lua and Rust were all fine (Rust wasn't around in 2010 of course).
- rurban 10mo agoI'm reving _why's syck right now. Turns out my fork from 2013 was still the most advanced. It doesn't implement the latest YAML specs, and all of it's new insecurities, which is a good thing. And it's much, much faster than the sax-like libyaml. But since syck uses the ruby hashtable internally, I got stuck in the gem for a while. It fell out of their stdlib, and is not really maintained neither. PHP had the latest updates for it. And perl (me) extended it to be more recursion safe, and added more policies (what to do on duplicate keys: skip or overwrite). So the ruby bindings are troublesome because of its GC, which with threading requires now7 a global vm instance. And using the ruby alloc/free pairs. PHP, perl, python, Lua, IO, cocoa, all no problem. Just ruby, because of its too tight coupling. Looks I have to decouple it finally from ruby.
- zeckalpha 10mo agoPascal and Ada are Algol syntaxed relative to most languages.
- rapind 10mo ago
- rwmj 10mo agoOut of interest, was Tcl considered? It's the original embeddable language.
- andrewshadura 10mo agoWasn't the original Redis prototype written in Tcl?
- dontdoxxme 10mo agoYes, previously: https://news.ycombinator.com/item?id=35989909 https://news.ycombinator.com/item?id=35989909 The Redis test suite is still written in Tcl: https://news.ycombinator.com/item?id=9963162 https://news.ycombinator.com/item?id=9963162 (although more recently antirez said somewhere he wished he'd written it in C for speed)
- rogerbinns 10mo agoIn 1994 at the second WWW conference we presented "An API to Mosaic". It was TCL embedded inside the (only![1]) browser at the time - Mosaic. The functionality available was substantially similar to what Javascript ended up providing. We used it in our products especially for integrating help and preferences - for example HTML text could be describing color settings, you could click on one, select a colour from the chooser and the page and setting in our products would immediately update. In another demo we were able to print multiple pages of content from the start page, and got a standing ovation! There is an alternate universe where TCL could have become the browser language. For those not familiar with TCL, the C API is flavoured like main. Callbacks take a list of strings argv style and an argc count. TCL is stringly typed which sounds bad, but the data comes from strings in the HTML and script blocks, and the page HTML is also text, so it fits nicely and the C callbacks are easy to write. [1] Mosaic Netscape 0.9 was released the week before
- spacechild1 10mo ago> it feels like it departs from what people know without good reasons. Lua is a pretty old language. In 1993 the world had not really settled on C style syntax. Compared to Perl or Tcl, Lua's syntax seems rather conventional. Some design decisions might be a bit unusual, but overall the language feels very consistent and predictable. JS is a mess in comparison. > because it departs from a more Algol-like syntax Huh? Lua's syntax is actually very Algol-like since it uses keywords to delimit blocks (e.g. if ... then ... end)
- lioeters 10mo ago> consistent and predictable That's what matters to me, not how similar Lua is to other languages, but that the language is well-designed in its own system of rules and conventions. It makes sense, every part of it contributes to a harmonious whole. JavaScript on the other hand. When speaking of Algol or C-style syntax, it makes me imagine a "Common C" syntax, like taking the best, or the least common denominator, of all C-like languages. A minimal subset that fits in your head, instead of what modern C is turning out to be, not to mention C++ or Rust.
- procaryote 10mo agoIs modern C really much more complicated than old C? C++ is a mess of course.
- lioeters 10mo agoI don't write modern C for daily use, so I can't really say. But I've been re-learning and writing C99 more these days, not professionally but personal use - and I appreciate the smallness of the language. Might even say C peaked at C99. I mean, I'd be crazy to say that C-like languages after C99, like Java, PHP, etc., are all misguided for how unnecessarily big and complex they are. It might be that I'm becoming more like a caveman programmer as I get older, I prefer dumb primitive tools.
- procaryote 10mo ago
- norir 10mo agoI 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.
- garganzol 10mo agoJavaScript in 2010 was a totally different beast, standartization-wise. Lots of sharp corners and blank spaces were still there. So, even if an implementation like MicroQuickJS existed in 2010, it's unlikely that too many people would have chosen JS over Lua, given all the shortcomings that JavaScript had at the time.
- kybernetikos 10mo agoWhile you're not wrong that JS has come a long way in that time, it's not the case that it was an extremely unusual choice at the time - Ryan Dahl chose it for node in 2009.
- hnlmorg 10mo agoLua only departs from norms if you’ve had a very narrow experience with other programming languages. Frankly, I welcome the fact that Redis doesn’t use JavaScript. It’s an abomination of a language. The fewer times I need to use it the better.
- DebugDruid 10mo agoI think criticizing JavaScript has become a way of signaling "I'm a good programmer." Yes, good programmers ten years ago had valid reasons to criticize it. But today, attacking the efforts of skilled engineers who have improved the language (given the constraints and without breaking half of the web) seems unfair. They’ve achieved a Herculean task compared to the Python dev team, which has broken backward compatibility so many times yet failed to create a consistent language, lacking a single right way to do many things.
- hnlmorg 10mo ago> But today, attacking the efforts of skilled engineers who have improved the language (given the constraints and without breaking half of the web) seems unfair. I was criticising a thing not a person. Also your comment implies it was ok to be critical of a language 10 years ago but not ok today because a few more language designers might get offended. Which is a weird argument to make.
- TheTaytay 10mo agoI think he’s saying it’s a fundamentally improved language at this point?
- ezst 10mo agoNot OP, but the case can be made that it's still the same very ugly language of 10 years ago, with few layers of sugar coating on top. The ugly hasn't gone anywhere. You still have to deal with it and suffer the cognitive burden.
- zeckalpha 10mo agoRedis' author also made jimtcl, so I don't think the lack of a small engine was the gap
- andrewstuart 10mo agoLua - an entire language off by one.
- rurban 10mo agoSure, because the first element is at index 1, not zero. Ha
- vegabook 10mo agoLua has been a wild success considering it was born in Brazil, and not some high wealth, network-effected country with all its consequent influential muscle (Ruby? Python? C? Rust? Prolog? Pascal? APL? Ocaml? Show me which one broke out that wasn't "born in the G7"). We should celebrate its plucky success which punches waaay above its adoption weight. It didn't blindly lockstep ALGOL citing "adooooption!!", but didn't indulge in revolution either, and so treads a humble path of cooperative independence of thought. Come to think of it I don't think I can name a single mainstream language other than Lua that wasn't invented in the G7.
- dustbunny 10mo agoI also strongly disliked luas syntax at first but now I feel like the meta tables and what not and pcall and all that stuff is kinda worth it. I like everything about Lua except some of the awkward syntax but I find it so much better then JS, but I haven't been a web dev in over a decade
- junon 10mo agoThe only thing I dislike about Lua is the 1-indexing. I know they had reasons for it but it always caused issues.
- silisili 10mo agoI'm torn on this. Initially I agreed, just because so many other languages do it that way. But if you ignore that and clean slate it, IMO, 1 based makes more sense. I feel like 0 based mainly gained foothold because of C's bastardization of arrays vs pointers and associated tricks. But most other languages don't even support that. You can only see :len(x)-1 so many times before you realize how ridiculous it is.
- bvrmn 10mo agoI could live with 1-indexing but a closed range array unpack (slices) is quite big toll and breaks nice intuitive invariant.
- junon 10mo ago0 based has a LOT of benefits whereas the reasoning, if I recall, for 1-indexing in Lua was to make the language more approachable to non-devs. Having written a game in it (via LÖVE), the 1-indexing was a continued source of problems. On the other hand, I rarely need to use len-1, especially since most languages expose more readable methods such as `last()`.
- deleted 10mo ago[deleted]
- 10mo ago
- CapsAdmin 10mo agoIt sounds like you're trying to articulate why you don't like Lua, but it seems to just boil down to syntax and semantics unfamiliarity? I see this argument a lot with Lua. People simply don't like its syntax because we live in a world where C style syntax is more common, and the departure from that seem unnecessary. So going "well actually, in 1992 when Lua was made, C style syntax was more unfamiliar" won't help, because in the current year, C syntax is more familiar. The first language I learned was Lua, and because of that it seems to have a special place in my heart or something. The reason for this is because in around 2006, the sandbox game "Garry's Mod" was extended with scripting support and chose Lua for seemingly the same reasons as Redis. The game's author famously didn't like Lua, its unfamiliarity, its syntax, etc. He even modified it to add C style comments and operators. His new sandbox game "s&box" is based on C#, which is the language closest to his heart I think. The point I'm trying to make is just that Lua is familiar to me and not to you for seemingly no objective reason. Had Garry chosen a different language, I would likely have a different favorite language, and Lua would feel unfamiliar and strange to me.
- junon 10mo agoGP is the creator of Redis. I would imagine he knows Lua well given that Redis has embedded it for around a decade.
- CapsAdmin 10mo agoIn that case, my point about Garry not liking Lua despite choosing it for Garrysmod, for seemingly the same reason as antirez is very appropriate. I haven't read antirez'/redis' opinions about Lua, so I'm just going off of his post. In contrast I do know more about what Garry's opinion on Lua is as I've read his thoughts on it over many years. It ultimately boils down to what antirez said. He just doesn't like it, it's too unfamiliar for seemingly no intentional reason. But Lua is very much an intentionally designed language, driven in cathedral-style development by a bunch of professors who seem to obsess about language design. Some people like it, some people don't, but over 15 years of talking about Lua to other developers, "I don't like the syntax" is ultimately the fundamental reason I hear from developers. So my main point is that it just feels arbitrary. I'm confident the main reason I like Lua is because garry's mod chose to implement it. Had it been "MicroQuickJS", Lua would likely feel unfamiliar to me as well.
- atdt 10mo agoMy hunch is that the same is true of Wikipedia's choice of Lua for template scripting, made back in 2012. https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/43FHW22UIXT6CDEFNJLWX5MI6RE7GQRP/5 https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists...
- avaer 10mo agoWhat are the chances of switching to MQJS or something like it in the future?
- Hendrikto 10mo ago> If this had been available in 2010, Redis scripting would have been JavaScript and not Lua. Thank god it wasn’t then.
- petters 10mo agoLua having a JIT compiler seems like a big difference though. It was a while since that got major updates, but probably relevant at the time?
- jacobs101 10mo ago[dead]
- kiririn 10mo agoI’m always surprised people pick Lua when Pawn exists. I think I’d even still choose it over MicroQuickJS https://www.compuphase.com/pawn/pawn.htm https://www.compuphase.com/pawn/pawn.htm
- bnolsen 10mo agoI remember seeing this a long time ago and liking it, I just didn't have a use for it at the time. How does it stack up against luahit for perf and memory, and threading? It also looks like it could be worth looking at porting the compiler to zig which excels at both compiler writing and cross platform tooling.
- 3eb7988a1663 10mo agoLuaJIT is best in class performance for a scripting language -by a huge margin. In very specific problems, it can outperform C. Surely anything else is going to come up lacking if you are only considering raw benchmarks.
- nxobject 10mo ago+1 for the incredibly niche (but otherwise make-it-or-break-it) fact that PUC-Rio is and likely always will be strict C89 (i.e. ANSI C). I think this was (and still is?) most relevant to gamedev on Windows using older versions of MSVC, which has until recently been a few pennies short of a full C99 implementation. I did once manage to compile Lua 5.4 on a Macintosh SE with 4MB of RAM, and THINK C 5.0 (circa 1991), which was a sick trick. Unfortunately, it took about 30 seconds for the VM to fully initialize, and it couldn't play well with the classic MacOS MMU-less handle-based memory management scheme.
- c-smile 10mo agoLua syntax is pretty good for DSL (domain specific language) cases / configuration definitions. For example Premake[1] uses Lua as it is - without custom syntax parser but with set of domain specific functions. This is pure Lua: workspace "MyWorkspace" configurations { "Debug", "Release" } project "MyProject" kind "ConsoleApp" language "C++" files { "**.h", "**.cpp" } filter { "configurations:Debug" } defines { "DEBUG" } symbols "On" filter { "configurations:Release" } defines { "NDEBUG" } optimize "On" In that sense Premake looks significantly better than CMake with its esoteric constructs. Having regular and robust PL to implement those 10% of configuration cases that cannot be defined with "standard" declarations is the way to go, IMO. [1] https://premake.github.io/docs/What-Is-Premake https://premake.github.io/docs/What-Is-Premake
- TimTheTinker 10mo agoI for one would be would be very interested in a Redbean[0] implementation with MicroQuickJS instead of Lua, though I lack the resources to create it myself. [0] https://redbean.dev/ https://redbean.dev/ - the single-file distributable web server built with Cosmopolitan as an αcτµαlly pδrταblε εxεcµταblε
- lacoolj 10mo agoNormally I'd say "it's never too late!" but clearly would diverge and require an entirely new project, maintaining two bases for the same thing, etc. Good to see you alive and kicking. Happy holidays
- MangoToupe 10mo ago> If this had been available in 2010, Redis scripting would have been JavaScript and not Lua. This would have been a catastrophic loss. Lua is better than javascript in every single way except for ordinal indexing
- pmarreck 10mo agoLuaJIT’s C FFI integration is super useful in a scripting language and I’ve replaced numerous functions previously written in things like Bash with it. it also helps that it has ridiculously high performance for a scripting language