I was thinking a while back, how nice it would be if lua was the scripting language in the browser instead of javascript. There are some projects to compile lua to wasm and have it run in the browser...
But interoperability with the DOM is the missing key.
Still, if lua was used instead of javascript, I could see myself saying... man, I wonder what browser development would be like if we replaced lua with x.
IIRC Brendan Eich has talked about this - if he’d adopted Lua in 1995 instead of creating JavaScript, it wouldn’t have been Lua 5.x but Lua 2.x.
Lua has improved substantially from version to version because it’s been able to break compatibility. That wouldn’t be possible in the browser, so today we’d still be stuck using (an augmented version of) the outdated Lua 2.x.
What specifically do you think would be better? Lua shares many of JS's quirks (like the relationship between arrays and non-array objects, the behavior of undefined for non-existent object properties, metatables are somewhat similar to JS prototypes, etc.) and adds a bunch more (lack of continue statement, 1-indexing, cannot have nil values in tables).
I can see people liking or disliking Lua and JS both, depending on taste, but it's hard to see someone liking one and disliking the other.
Lua has tail call optimization and js doesn't. For me, this is a dealbreaker for js.
Lua also has operational advantages compared to javascript. You can build it from source in at most a few seconds and run it anywhere that has a c compiler. The startup time is negligible even compared to a compiled c program so you can run entire scripts that do very useful things faster than most js engines can print hello world. There is also the benefit that in spite of what this article discusses, it is possible for most problems to write a lua solution that works for all lua >= 5.1. This is wonderful because it means if I stick to the standard library, the bitrot is essentially zero.
Calling into c is very straightforward in Lua, especially with luajit, which makes it superior to js as a scripting language (the node ffi api is quite painful in my experience and ffi runs against the js execution model).
Lua also essentially got lexical scoping of local variables correct from the beginning while js blessed us with the nightmare of var.
Of course Lua is far from perfect, but while there are some similarities, the differences are quite significant and meaningful.
I agree mostly in that Lua and Javascript are both similar, and like I said in my post above, I could see myself saying the exact opposite if Lua had been included in the browser.
The things I do not like about Javascript can easily be shot down in an argument. Some of it was having to work with Javascript (and it's evil cousin JScript) in the 90s and early 00s.
The type coercion and in the early days people used '=='. I think === did not even appear until ie6?
[] == ![] // true
The lack of a lot of easy helper functions in the standard lib. That now are provided by people writing a bunch of stuff in the npm ecosystem.
The npm ecosystem itself. Lack of security. Lack of... curation? (Also, all this would have probably happened anyway if Lua was in the browser)
I also think javascripts long history has created a legacy of different paradigms
variable declaration
var, let, const
function declaration
function f1() {}
const f2 = function() {};
const f3 = () => {};
const obj = { f4() {} };
There is a lot of stuff like this in javascript. I could probably make a blog post about it. But the above gives the general idea of my complaints.
In practice you don't run into these issues often. I'm annoyed when you see different function declaration conventions in the same codebase, but generally () => is used for either one line functions or inline lambdas, and function foo(){} for everything else. Nobody uses var anymore.
The implicit conversions is a definite footgun tho.
I held a similar opinion several years ago. The main thing is that lua has less magic than js largely because it's been allowed to break compatibility.
My main example is self in lua which is just the first argument of a function with some syntactic sugar vs this in javascript which especially before 'bind' often tripped people up. The coercion rules are also simpler largely by virtue of making 0 true.
I don’t know if this can access the DOM in Lua, but considering that Fengari is in Javascript, adding a _DOM global variable should not be too hard (if it hasn’t already been done).
It is interesting that so many of the largest languages were developed in a couple year time frame in the early-mid 90s. Python, Javascript, Java, Lua, R. All of these were developed 91-95 and make a bulk of development today.
I'm sure there are a few unrelated factors going on to influence that plus some inadvertent cherry-picking. But I do think there is a thing to the observation too.
If I had to make a guess, I'd point to a combination of:
1. This was right around the time that computers were fast enough to afford the runtime cost of garbage collection while still delivering usable apps. The GC languages before the 90s (Lisp, Scheme, Smalltalk, Self) had reputations for abysmal performance and have largely (but not entirely) died out.
2. This was also the boom of the Internet and web which shifted a lot of computation to server-side after the PC boom had shifted it client-side. That also enabled somewhat slower languages with GC to thrive because first-mover advantage was more valuable than using your servers efficiently. You could just throw more hardware at it.
3. That boom also created a huge influx of new developers who picked up whatever language happened to be hot at the time. And once they had, they tended to stick with it. I can't find a good graph of the number of software engineers over time but I'd bet that there's a noticeable uptick around the dotcom boom.
After mulling it over a bit, plus seeing a few other response (Php, Ruby, etc) I think the internet is the reason.
C, C++, Ada, Basic, Fortran. Those were written assuming they were going to be writing systems code and numerical code. There is then some inertia keeping the most successful ones of from those periods going in their spaces.
Then these new languages with new ideas (GCs, Dynamic Typing, etc) they came out and became successful in the newer Web and Application spaces. Now why they won out and not LISP or SmallTalk or what have you, I am not sure. But my hypothesis is that the web is a big part of it.
Languages developed in that time matured just as good binary package managers started popping up, is my pet theory. Before that, getting a development environment for a new language was serious work, and people did things like stick to Perl since it happened to be installed already.
I was programming in the 90s when these languages emerged. Developments environments were emacs, vi, Brief, Borland IDE, etc. There were a few other IDEs available, but about $200 per seat.
All the scripting languages mentioned didn't come as default in Unix or Windows. You had to download from their own websites.
It was mostly Visual Basic, C, COBOL that were popular.
I think that's what I mean. After the time you talk about ('90s), these languages matured, and they happened to mature around the same time binary package managers became a thing, i.e. in the early-to-mid '00s.
>Elk, the Extension Language Kit, is a Scheme implementation that is intended to be used as a general,
reusable extension language subsystem for integration
into existing and future applications. Applications can
define their own Scheme data types and primitives,
providing for a tightly-knit integration of the CIC++
parts of the application with Scheme code. Library interfaces, for example to the UNIX operating system
and to various X window system libraries, show the
effectiveness of this approach. Several features of Elk
such as dynamic loading of object files and freezing
of fully customized applications into executables (implemented for those UNIX environments where it was
feasible) increase its usability as the backbone of a
complex application. Elk has been used in this way
for seven years within a locally-developed ODA-based
multimedia document editor; it has been used in numerous other projects after it could be made freely
available five years ago.
>GNU Ubiquitous Intelligent Language for Extensions[3] (GNU Guile) is the preferred extension language system for the GNU Project[4] and features an implementation of the programming language Scheme. Its first version was released in 1993.[1] In addition to large parts of Scheme standards, Guile Scheme includes modularized extensions for many different programming tasks.[5][6]
>Winterp is an interactive, language-based user-interface and application-construction environment enabling rapid prototyping of applications with graphical user interfaces based on the OSF/Motif UI Toolkit. Winterp also serves as a customization environment for delivered applications by providing a real programming language as an extension language. Many existing user-interface languages only have the expressive power to describe static layout of user interface forms; by using a high-level language for extensions and prototyping, Winterp also handles the dynamic aspects of UI presentation, e.g. the use of direct manipulation, browsers, and dialog. Winterp makes rapid prototyping possible because its language is based on an interpreter, thereby enabling interactive construction of application functionality and giving immediate feedback on incremental changes.Winterp's language is based on David Betz's public domain Xlisp interpreter which features a subset of Common Lisp's functionality. The language is extensible, permitting new Lisp primitives to be added in the C language and allowing hybrid implementations constructed from interpreted Lisp and compiled C. Hybrid implementation gives Winterp-based applications the successful extension and rapid-prototyping capabilities of Lisp-based environments, while delivering the multiprocessing perfor- mance of C applications running on personal Unix workstations.
>The Visix Galaxy project was a ridiculously overpriced and overfeatured portable GraphicalUserInterface. You could do things like swivel an entire panel full of their custom widgets 32 degrees clockwise, and it would render all its text at this new angle without jaggies. The company went out of business after gaining only a handful of customers. For USD$ 10,000 a seat they sure didn't see the OpenSource movement coming. Their last attempt before going under was (guess what?) a Java IDE.
Galaxy competed with Neuron Data Systems in the "cross platform gui framework" space (which got steamrolled by the web permanently and for a window of time Java):
The language of R is S, which originated at Bell Labs in 01976. Python began development in 01989, although Guido didn't release it until 01991. And the top 20 on https://www.tiobe.com/tiobe-index/ are Python, C (01972?), C++ (01982?), Java, C# (01999? though arguably it's just a dialect of Java), JS, Visual Basic (first released 01991, within your window), Golang (02007), Delphi (under this name in 01995 but a dialect of Object Pascal from 01986, in turn a dialect of Pascal, from 01970), SQL (01973), Fortran (01957), Perl (01987), R, PHP (01995, within your window!), assembly (01947), Rust (02006), MATLAB/Octave (01984), Scratch (! 02003), Ada (01978?), and Kotlin (02011).
By decade, that's one language from the 40s, one language from the 50s, no languages from the 60s, 5 languages from the 70s, 5 languages from the 80s, 4 languages from the 90s, 3 languages from 0200x, one language from the 02010s, and no languages from the 02020s.
Lua is #33 on TIOBE's list, but given its prevalence in Roblox (as Luau), WoW, and other games, I suspect it should be much higher.
For some reason, CUDA (a dialect of C++) and shader languages like GLSL don't show up in the list at all.
— ⁂ —
I think most of what's going on here is that it takes a new language a long time to get good, and it takes a new good language a long time to get popular. Perl, Python, Java, PHP, and JS became popular because of the Web; https://philip.greenspun.com/panda/server-programming explains why Perl, Python, and PHP did, and of course Java and JS became popular because they were the only languages you could make interactive web pages in:
> You would think that picking a Web site development language would be trivial. Obviously the best languages are safe and incorporate powerful object systems. So let's do everything in Common Lisp or Java. Common Lisp can run interpeted as well as compiled, which makes it a more efficient language for developers. So Common Lisp should be the obvious winner of the Web server language wars. Yet nobody uses Common Lisp for server-side scripting. Is that because Java-the-hype-king has crushed it? No. In fact, to a first approximation, nobody uses Java for server-side scripting. Almost everyone is using simple interpreted languages such as Visual Basic, PHP, Perl, or Tcl.
> How could a lame string-oriented scripting language possibly compete in power with systems programming languages? Well, guess what? The only data type that you can write to a Web browser is a string. And all the information from the relational database management system on which you are relying comes back to to the Web server program as strings. So maybe it doesn't matter whether your scripting language has an enfeebled type system.
I do agree with your point but I also think that there is a lot of inertia in the sector (rightfully so!) and it is very difficult for languages to become established if they don't come with a "unique selling point" of sorts, which to me explains how new popular languages have become rarer.
That selling point, for Lua, is the super easy integration via C-API to me (=> making existing compiled applications scriptable), thanks to uncomplicated build (dependency free, simple), the straightforward C-API and the ease of exposing C "modules" to Lua.
On a sidenote:
Don't you think that Y10k-safe dates are somewhat inconsistent with referencing previous decades directly? Those dates are also obnoxious to parse for humans (myself, at least).
Some people think that writing years as 2025 is wrong because this will lead to problems in year 9999 (y10k bug? I'm not sure if they call it that way) so they decided to introduce leading zero as it would solve something and not just postpone the problem to 99999.
That's silly. The y2k bug was because the year was written as 65, instead of the full year being 1965, so information was lost. Writing 2025 has no missing information.
"The present moment used to be the unimaginable future." -Steward Brand
"How can we invest in a future we know is structurally incapable of keeping faith with its past? The digital industries must shift from being the main source of society’s ever-shortening attention span to becoming a reliable guarantor of long-term perspective. We’ll know that shift has happened when programmers begin to anticipate the Year 10,000 Problem, and assign five digits instead of four to year dates. 01998 they’ll write, at first frivolously, then seriously." -Steward Brand
>C# (01999? though arguably it's just a dialect of Java)
That's like saying Java is a dialect of C++. Java was specifically designed as a "fuck you" to C++, and C# was specifically designed as a "fuck you" to Java.
While at a political level that's reasonable, at both the semantic and the syntactic level, the first version of C# was very close to Java, much closer than the first version of Java was to C++. https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs... is a very vague overview.
function set(name, val)
rawset(_G, name, val or false)
end
function exists(name)
if rawget(_G, name) then return true end
return false
end
throwError = {__newindex = function(self,name) error("Unknown global " .. name) end,
__index = function(self,name) error("Unknown global " .. name) end
}
setmetatable(_G,throwError)
Naturally, the main catch is that this only detects the violation at run-time. It also won't stop you from accidentally overwriting a global variable that already exists.
It's because Tcl, like SQLite, operates on a peculiar metaphysical principle: everything is a string until proven otherwise, and even then, it's probably still a string.
Also, D. Richard Happ, who we owe thanks for SQLite, was and perhaps still sits on the TCL Board (I may be wrong about that, but Happ holds significance in the TCL community).
In my mind:
Tcl is the quietly supportive roommate who keeps making coffee and feeding LISP-like functionality until the world finally notices its genius.
Lua sits across the table, sipping espresso with a faintly amused expression, wondering how everyone got so emotionally entangled with their configuration files.
Lua is one of the easiest configuration file formats I've had the pleasure of working with. Readable. Has comments. Variables. Conditionals.
Everyone (including me): "oh no, no, you don't want a full Turing complete language in your configuration file format"
Also Everyone: generating their configuration files with every bespoke templating language dreamed of by gods and men, with other Turing complete languages.
TCL 9 brought some welcome string improvements, and things run faster overall. But in my case, it's hard to say how well that's actually played out, partly because I haven't done the work to find out. My TCL scripts and apps work well enough to allow me to be lazy about them.
Performance is up, but so is my inertia. So while TCL 9 could be transformative, for now it remains a white paper I've skimmed, not a revolution I've implemented.
I think TCL does an opaque thing, everything "is" a string, but if you don't use it as a string, it's actually stored in some optimized format. Then it converts back to a string on demand
I still prefer Lua personally. Their type system is easy for me to understand
Lua is simple and elegant, and I much prefer it to Tcl.
Lua is in games and in LuaTeX, and when you have the choice of embedding a LISP, a FORTH or Lua in a larger application, it is often the most maintainable, runtime-efficient and low-memory footprint option of all.
What would be the SQLite's equivalent to indexing starting from 1, not 0? Off the top of my head I can't think of anything that would go so much against the grain.
My only context in using Lua is my neovim configuration, does any know of any good books or tutorials that make something more advance using only lua? Anything of note to consider/read/watch?
Shameless plug time: I have written a public domain book which looks at using Lua (Lua 5.1 but the code works in newer versions as well as Lua 5.1/Luau/LuaJIT) as a text parsing engine. The book assumes familiarity with other common *NIX scripting languages (such as AWK, Perl, or Python) and goes over in detail the pain points for people coming from a *NIX scripting background:
Thanks for recommendation and writing the book! I'm reading the introduction, it doesn't answer why you chose to fork lua and create lunacy. What were you trying to solve with lunacy that lua couldn't do?
The TOC looks great, I will read this soon. Need to finish "Debugging CSS" first (another good book IMO).
The main reason I made Lunacy was to have a standard compile of Lua 5.1, since it’s possible to make a Lua 5.1 compile with, say 32-bit floats or which only supports integers but not floats.
Lunacy also has a few built in libraries which are not included with Lua 5.1, such as binary bitwise operations (and/or/xor). It also fixes some security issues with Lua 5.1 (better random number generator, hash compression algorithm which is protected from hash flooding attacks).
In addition, I have made a tiny Windows32 binary of Lunacy.
Don’t worry about the Lunacy changes; all of the examples in the book work with bog standard Lua 5.1 with a bit32 library (bit32 is common enough most OSes with a Lua 5.1 package also have a bit32 package for Lua 5.1).
Definitely include Roberto's Programming in Lua book in your list. Specially if you'd like to script Lua together with C. The book has a good primer on the Lua-C api in its latter half.
Don't have tutorials or books, but I've had a ton of fun using Lua with LOVE2D [0] for gamedev, and also Redbean [1] for building super small portable web applications. Earlier this year, I built a mini CMS [2] inspired by rwtxt with Redbean.
Haven't heard of love2d but have heard of pico-8. I've avoided most game dev tutorials because they seem overly focused on beginners, which is fine, but want to find more advance materials that assume the reader knows some basics.
Maybe I should reconsider and dive more into game dev.
> It's aimed at programmers who have some experience but are just starting out with game development, or game developers who already have some experience with other languages or frameworks but want to figure out Lua or LÖVE better.
Also on the topic of game engines with lua scripting, the wonderful Defold always deserves a mention https://defold.com/
I always wrote Lua off, scoffing at the 1-based indexing, until I was "forced" to learn it thanks to Neovim. What a delightful little language it is. I do wish I could do certain things less verbosely (lambdas would be nice) -- but then again, I defeat myself by suggesting it, because not having all the features makes Lua so approachable.
Same here, in fact something I wish the neovim team would do is create a book where popular plugin authors create tutorials that recreate basic functionality of their plugins.
Seems like a no brainer that would help bring in more revenue too, it'd also be an "evergreen" book as new others can contribute over time.
I can't be the only one that would immediately buy a copy. :D
I'm actually trying to work on a video-series to do just this. I've made my own rudimentary plugins reproducing several popular ones, and would like to walk through how I made: a) file-tree b) picker/fzf replacment c) hop/leap replacement d) surround plugin e) code-formatter f) hydra (sub-modes) g) many "UI" (interactive) buffers, etc.
None of these are published because the popular ones are better and provide more functionality, but I want to share what I believe is more valuable: what I learned while writing them.
I used Lua professionally. I prefer the 1 indexing... it just feels more natural. For some reason the C apologists here will scream how 0 based is the only way to go. (which is not, it is just a historical artifact). Languages like ADA allowed you to use either 0 or 1, (or any arbitrary) starting index.
Rebol is the cleanest/greatest language I've read code for but the VM is the slowest VM I've ever wrote code for, mind you I only did the first 10 exercises of euler but the only thing that has it beat is writing a shellscript that forks to dc/bc on each math expression.
I spent a few nights trying to implement a Lua interpreter myself and it was still like 10x slower than PUC Lua, even before adding a GC. I'm not sure how they do it, it looks like regular C code
LuaJIT is amazing. I find it insane there are no Schemes that are able to match it as a tiny, embeddable scripting language with a JITer. GNU Guile is an absolute gargantuan monster in comparison.
LuaJIT is in somewhat active development, with 40 commits so far this year, although these are mostly bug fixes (some for bugs introduced by LLVM). The main new feature, if you can call it that, is "suport for Apple hardened runtime."
You say that as if Lua 5.3 and 5.4 were better than Lua 5.2 (which LuaJIT has support for most of the new features of) or 5.1, rather than merely newer. But programming languages don't decay like your teeth.
Except they are? Lua 5.3 bitwise literals are a big improvement over the builtins bitand32, bitor.. the addition of integer type makes the language more suitable for embedded systems that don't have FPU.. Lua 5.4 added const attribute for local variables..
Those are tradeoffs, and I'm not convinced they're good ones. Suitability for processors that are so small they don't have an FPU isn't relevant to LuaJIT in any case, but you've been able to compile Lua with integer numbers since 1.0.
A useful design pattern is to write highly efficient "engine" code in C/C++ and then tie it together to highly customizable application code with an embedded scripting language.
Lua is great for this, and while you could use a LISP (Emacs, AutoCad) or a FORTH (any real-life example not from the radio telescope domain?) or Tcl/Tk (https://wiki.tcl-lang.org/page/Who+Uses+Tcl), Lua is small (as in number of concepts to understand), easy to read and understand, and compact (as in tiny codebase to integrate, few dependencies).
So many gaming startups have put their money on Lua.
The Lua-C API is also really consistent and straightforward. Bindings can be generated mechanically, of course, but it's really easy to embed by hand, and the documentation is superb.
I see your point. I've just craved a rails-like experience in Lua for a while and don't believe there's anything out there yet built on Lua that can match with the big boys (rails, .NET, etc.)
Here’s my bit of public domain code for iterating through tables in Lua so that the elements are sorted. This routine works like the pairs() function included with Lua:
-- Like pairs() but sorted
function sPairs(inTable, sFunc)
if not sFunc then
sFunc = function(a, b)
local ta = type(a)
local tb = type(b)
if(ta == tb)
then return a < b
end
return ta < tb
end
end
local keyList = {}
local index = 1
for k,_ in pairs(inTable) do
table.insert(keyList,k)
end
table.sort(keyList, sFunc)
return function()
key = keyList[index]
index = index + 1
return key, inTable[key]
end
end
Example usage of the above function:
a={z=1,y=2,c=3,w=4}
for k,v in sPairs(a) do
print(k,v)
end
With a sort function:
a={z=1,y=2,c=3,w=4}
function revS(a,b)
return a>b
end
for k,v in sPairs(a,revS) do
print(k,v)
end
(Yes, this is a lot easier to do in Perl or Python, since those languages unlike Lua have built in list iterators, but it’s possible to do in Lua too)
If you did not return a closure, you could set the metatables __pairs to use your function's. Sadly, you could not do this without keeping some sort of cache, which would be a terrible waste of memory, but then again you're already creating an iterator that iterates completely, to me, this beats the use of an iterator (to not iterate over everything and break on a single pass)
A bit off topic, but what is it with this account ( https://news.ycombinator.com/submitted?id=welovebunnies )? Created 8 days ago, already 300 karma, posts completely random / unrelated submissions but they all get upvotes. Is it an RSS bot farming karma or something? Very strange.
I was thinking a while back, how nice it would be if lua was the scripting language in the browser instead of javascript. There are some projects to compile lua to wasm and have it run in the browser...
https://pluto-lang.org/web/#env=lua%3A5.4.6&code=if%20_PVERS...
But interoperability with the DOM is the missing key.
Still, if lua was used instead of javascript, I could see myself saying... man, I wonder what browser development would be like if we replaced lua with x.
IIRC Brendan Eich has talked about this - if he’d adopted Lua in 1995 instead of creating JavaScript, it wouldn’t have been Lua 5.x but Lua 2.x.
Lua has improved substantially from version to version because it’s been able to break compatibility. That wouldn’t be possible in the browser, so today we’d still be stuck using (an augmented version of) the outdated Lua 2.x.
What specifically do you think would be better? Lua shares many of JS's quirks (like the relationship between arrays and non-array objects, the behavior of undefined for non-existent object properties, metatables are somewhat similar to JS prototypes, etc.) and adds a bunch more (lack of continue statement, 1-indexing, cannot have nil values in tables).
I can see people liking or disliking Lua and JS both, depending on taste, but it's hard to see someone liking one and disliking the other.
Lua has tail call optimization and js doesn't. For me, this is a dealbreaker for js.
Lua also has operational advantages compared to javascript. You can build it from source in at most a few seconds and run it anywhere that has a c compiler. The startup time is negligible even compared to a compiled c program so you can run entire scripts that do very useful things faster than most js engines can print hello world. There is also the benefit that in spite of what this article discusses, it is possible for most problems to write a lua solution that works for all lua >= 5.1. This is wonderful because it means if I stick to the standard library, the bitrot is essentially zero.
Calling into c is very straightforward in Lua, especially with luajit, which makes it superior to js as a scripting language (the node ffi api is quite painful in my experience and ffi runs against the js execution model).
Lua also essentially got lexical scoping of local variables correct from the beginning while js blessed us with the nightmare of var.
Of course Lua is far from perfect, but while there are some similarities, the differences are quite significant and meaningful.
Why is tail call optimization a dealbreaker for you? That's very specific...
I agree mostly in that Lua and Javascript are both similar, and like I said in my post above, I could see myself saying the exact opposite if Lua had been included in the browser.
The things I do not like about Javascript can easily be shot down in an argument. Some of it was having to work with Javascript (and it's evil cousin JScript) in the 90s and early 00s.
The type coercion and in the early days people used '=='. I think === did not even appear until ie6?
[] == ![] // true
The lack of a lot of easy helper functions in the standard lib. That now are provided by people writing a bunch of stuff in the npm ecosystem.
The npm ecosystem itself. Lack of security. Lack of... curation? (Also, all this would have probably happened anyway if Lua was in the browser)
I also think javascripts long history has created a legacy of different paradigms
variable declaration var, let, const
function declaration
function f1() {}
const f2 = function() {};
const f3 = () => {};
const obj = { f4() {} };
There is a lot of stuff like this in javascript. I could probably make a blog post about it. But the above gives the general idea of my complaints.
In practice you don't run into these issues often. I'm annoyed when you see different function declaration conventions in the same codebase, but generally () => is used for either one line functions or inline lambdas, and function foo(){} for everything else. Nobody uses var anymore.
The implicit conversions is a definite footgun tho.
I like lua better because its minimalist. Javascript feels like a kitchen sink language.
Otoh, missing ++, +=, ..= operators really bothers me.
But that's just personal taste, not objective by any means.
I held a similar opinion several years ago. The main thing is that lua has less magic than js largely because it's been allowed to break compatibility.
My main example is self in lua which is just the first argument of a function with some syntactic sugar vs this in javascript which especially before 'bind' often tripped people up. The coercion rules are also simpler largely by virtue of making 0 true.
There’s also a Javascript implementation of Lua which allows one to run Lua in a browser:
https://github.com/fengari-lua/fengari-web
I don’t know if this can access the DOM in Lua, but considering that Fengari is in Javascript, adding a _DOM global variable should not be too hard (if it hasn’t already been done).
Fengari lets you access the DOM. Its pretty cool.
There is also nelua (https://nelua.io/) which can use WASM to compile allow its usage in the browser: https://github.com/edubart/nelua-game2048/
It is interesting that so many of the largest languages were developed in a couple year time frame in the early-mid 90s. Python, Javascript, Java, Lua, R. All of these were developed 91-95 and make a bulk of development today.
It is an interesting observation!
I'm sure there are a few unrelated factors going on to influence that plus some inadvertent cherry-picking. But I do think there is a thing to the observation too.
If I had to make a guess, I'd point to a combination of:
1. This was right around the time that computers were fast enough to afford the runtime cost of garbage collection while still delivering usable apps. The GC languages before the 90s (Lisp, Scheme, Smalltalk, Self) had reputations for abysmal performance and have largely (but not entirely) died out.
2. This was also the boom of the Internet and web which shifted a lot of computation to server-side after the PC boom had shifted it client-side. That also enabled somewhat slower languages with GC to thrive because first-mover advantage was more valuable than using your servers efficiently. You could just throw more hardware at it.
3. That boom also created a huge influx of new developers who picked up whatever language happened to be hot at the time. And once they had, they tended to stick with it. I can't find a good graph of the number of software engineers over time but I'd bet that there's a noticeable uptick around the dotcom boom.
After mulling it over a bit, plus seeing a few other response (Php, Ruby, etc) I think the internet is the reason.
C, C++, Ada, Basic, Fortran. Those were written assuming they were going to be writing systems code and numerical code. There is then some inertia keeping the most successful ones of from those periods going in their spaces.
Then these new languages with new ideas (GCs, Dynamic Typing, etc) they came out and became successful in the newer Web and Application spaces. Now why they won out and not LISP or SmallTalk or what have you, I am not sure. But my hypothesis is that the web is a big part of it.
Languages developed in that time matured just as good binary package managers started popping up, is my pet theory. Before that, getting a development environment for a new language was serious work, and people did things like stick to Perl since it happened to be installed already.
Not true.
I was programming in the 90s when these languages emerged. Developments environments were emacs, vi, Brief, Borland IDE, etc. There were a few other IDEs available, but about $200 per seat.
All the scripting languages mentioned didn't come as default in Unix or Windows. You had to download from their own websites.
It was mostly Visual Basic, C, COBOL that were popular.
I think that's what I mean. After the time you talk about ('90s), these languages matured, and they happened to mature around the same time binary package managers became a thing, i.e. in the early-to-mid '00s.
There was also ELK Scheme, the Extension Language Kit, a scheme interpreter designed to be used as an extension language for other appllications.
https://www.usenix.org/legacy/publications/compsystems/1994/...
>Elk, the Extension Language Kit, is a Scheme implementation that is intended to be used as a general, reusable extension language subsystem for integration into existing and future applications. Applications can define their own Scheme data types and primitives, providing for a tightly-knit integration of the CIC++ parts of the application with Scheme code. Library interfaces, for example to the UNIX operating system and to various X window system libraries, show the effectiveness of this approach. Several features of Elk such as dynamic loading of object files and freezing of fully customized applications into executables (implemented for those UNIX environments where it was feasible) increase its usability as the backbone of a complex application. Elk has been used in this way for seven years within a locally-developed ODA-based multimedia document editor; it has been used in numerous other projects after it could be made freely available five years ago.
Also Gnu Guile:
https://en.wikipedia.org/wiki/GNU_Guile
>GNU Ubiquitous Intelligent Language for Extensions[3] (GNU Guile) is the preferred extension language system for the GNU Project[4] and features an implementation of the programming language Scheme. Its first version was released in 1993.[1] In addition to large parts of Scheme standards, Guile Scheme includes modularized extensions for many different programming tasks.[5][6]
Also Winterp, which used XLisp:
https://dl.acm.org/doi/10.1145/121994.121998
>Winterp is an interactive, language-based user-interface and application-construction environment enabling rapid prototyping of applications with graphical user interfaces based on the OSF/Motif UI Toolkit. Winterp also serves as a customization environment for delivered applications by providing a real programming language as an extension language. Many existing user-interface languages only have the expressive power to describe static layout of user interface forms; by using a high-level language for extensions and prototyping, Winterp also handles the dynamic aspects of UI presentation, e.g. the use of direct manipulation, browsers, and dialog. Winterp makes rapid prototyping possible because its language is based on an interpreter, thereby enabling interactive construction of application functionality and giving immediate feedback on incremental changes.Winterp's language is based on David Betz's public domain Xlisp interpreter which features a subset of Common Lisp's functionality. The language is extensible, permitting new Lisp primitives to be added in the C language and allowing hybrid implementations constructed from interpreted Lisp and compiled C. Hybrid implementation gives Winterp-based applications the successful extension and rapid-prototyping capabilities of Lisp-based environments, while delivering the multiprocessing perfor- mance of C applications running on personal Unix workstations.
And TCL/Tk of course!
https://www.tcl-lang.org/
And on the commercial side, there was Visix Galaxy, which was extensible in PostScript, inspired by NeWS:
https://www.ambiencia.com/products.php
https://0-hr.com/Wolfe/Programming/Visix.htm
https://groups.google.com/g/comp.lang.java.programmer/c/LPkz...
https://donhopkins.com/home/interval/pluggers/galaxy.html
https://wiki.c2.com/?SpringsAndStruts
>The Visix Galaxy project was a ridiculously overpriced and overfeatured portable GraphicalUserInterface. You could do things like swivel an entire panel full of their custom widgets 32 degrees clockwise, and it would render all its text at this new angle without jaggies. The company went out of business after gaining only a handful of customers. For USD$ 10,000 a seat they sure didn't see the OpenSource movement coming. Their last attempt before going under was (guess what?) a Java IDE.
Galaxy competed with Neuron Data Systems in the "cross platform gui framework" space (which got steamrolled by the web permanently and for a window of time Java):
https://donhopkins.com/home/interval/pluggers/neuron.html
Here is a great overview of User Interface Software and Tools by Brad Myers:
https://www.cs.cmu.edu/~bam/uicourse/2001spring/lecture05too...
https://www.cs.cmu.edu/~bam/toolnames/
https://docs.google.com/document/d/1hQbMwK_iyjX-wpu_Xw_H-3zL...
Don't forget Ruby in 1995!
PHP too.
I think that's an illusion.
The language of R is S, which originated at Bell Labs in 01976. Python began development in 01989, although Guido didn't release it until 01991. And the top 20 on https://www.tiobe.com/tiobe-index/ are Python, C (01972?), C++ (01982?), Java, C# (01999? though arguably it's just a dialect of Java), JS, Visual Basic (first released 01991, within your window), Golang (02007), Delphi (under this name in 01995 but a dialect of Object Pascal from 01986, in turn a dialect of Pascal, from 01970), SQL (01973), Fortran (01957), Perl (01987), R, PHP (01995, within your window!), assembly (01947), Rust (02006), MATLAB/Octave (01984), Scratch (! 02003), Ada (01978?), and Kotlin (02011).
By decade, that's one language from the 40s, one language from the 50s, no languages from the 60s, 5 languages from the 70s, 5 languages from the 80s, 4 languages from the 90s, 3 languages from 0200x, one language from the 02010s, and no languages from the 02020s.
Lua is #33 on TIOBE's list, but given its prevalence in Roblox (as Luau), WoW, and other games, I suspect it should be much higher.
For some reason, CUDA (a dialect of C++) and shader languages like GLSL don't show up in the list at all.
— ⁂ —
I think most of what's going on here is that it takes a new language a long time to get good, and it takes a new good language a long time to get popular. Perl, Python, Java, PHP, and JS became popular because of the Web; https://philip.greenspun.com/panda/server-programming explains why Perl, Python, and PHP did, and of course Java and JS became popular because they were the only languages you could make interactive web pages in:
> You would think that picking a Web site development language would be trivial. Obviously the best languages are safe and incorporate powerful object systems. So let's do everything in Common Lisp or Java. Common Lisp can run interpeted as well as compiled, which makes it a more efficient language for developers. So Common Lisp should be the obvious winner of the Web server language wars. Yet nobody uses Common Lisp for server-side scripting. Is that because Java-the-hype-king has crushed it? No. In fact, to a first approximation, nobody uses Java for server-side scripting. Almost everyone is using simple interpreted languages such as Visual Basic, PHP, Perl, or Tcl.
> How could a lame string-oriented scripting language possibly compete in power with systems programming languages? Well, guess what? The only data type that you can write to a Web browser is a string. And all the information from the relational database management system on which you are relying comes back to to the Web server program as strings. So maybe it doesn't matter whether your scripting language has an enfeebled type system.
I do agree with your point but I also think that there is a lot of inertia in the sector (rightfully so!) and it is very difficult for languages to become established if they don't come with a "unique selling point" of sorts, which to me explains how new popular languages have become rarer.
That selling point, for Lua, is the super easy integration via C-API to me (=> making existing compiled applications scriptable), thanks to uncomplicated build (dependency free, simple), the straightforward C-API and the ease of exposing C "modules" to Lua.
On a sidenote:
Don't you think that Y10k-safe dates are somewhat inconsistent with referencing previous decades directly? Those dates are also obnoxious to parse for humans (myself, at least).
Why do you write your years with a leading zero?
Some people think that writing years as 2025 is wrong because this will lead to problems in year 9999 (y10k bug? I'm not sure if they call it that way) so they decided to introduce leading zero as it would solve something and not just postpone the problem to 99999.
Somehow both incredibly optimistic and also unbelievably resigned at the same time
That's silly. The y2k bug was because the year was written as 65, instead of the full year being 1965, so information was lost. Writing 2025 has no missing information.
So you can instantly recognize at a glance that it's Kragen's post! ;)
It's a Long Now Foundation thing: slower, deeper, longer. Y10K compliance.
https://longnow.org/ideas/long-now-years-five-digit-dates-an...
"The present moment used to be the unimaginable future." -Steward Brand
"How can we invest in a future we know is structurally incapable of keeping faith with its past? The digital industries must shift from being the main source of society’s ever-shortening attention span to becoming a reliable guarantor of long-term perspective. We’ll know that shift has happened when programmers begin to anticipate the Year 10,000 Problem, and assign five digits instead of four to year dates. 01998 they’ll write, at first frivolously, then seriously." -Steward Brand
10,000 Year Clock:
https://longnow.org/clock/
Don't you mean 0194x, etc? If you're going to be obnoxious, at least be consistently obnoxious.
The topic here is Lua and the history of programming languages, not your emotional problems. I suggest you take your form of discourse elsewhere.
>C# (01999? though arguably it's just a dialect of Java)
That's like saying Java is a dialect of C++. Java was specifically designed as a "fuck you" to C++, and C# was specifically designed as a "fuck you" to Java.
While at a political level that's reasonable, at both the semantic and the syntactic level, the first version of C# was very close to Java, much closer than the first version of Java was to C++. https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs... is a very vague overview.
True
> work has begun on Lua 5.5
A beta version is now available:
https://www.lua.org/work/
The main change from 5.4 seems to be the (optional?) removal of global-by-default, instead requiring declarations for global variables.
As it turns out, it’s possible with Lua going back to 5.1 to not allow undeclared global variables:
https://www.lua.org/pil/14.2.html
That code looks like this in Lua 5.1:
Then, to useNaturally, the main catch is that this only detects the violation at run-time. It also won't stop you from accidentally overwriting a global variable that already exists.
> It also won't stop you from accidentally overwriting a global variable that already exists.
That's also solvable using metatables.
Lua is the SQLite of program languages, absolutely blast
While I enjoy Lua, clean, elegant, and entirely too reasonable, Tcl is undoubtedly the SQLite of programming languages.
https://www.tcl-lang.org/community/tcl2017/assets/talk93/Pap...
It's because Tcl, like SQLite, operates on a peculiar metaphysical principle: everything is a string until proven otherwise, and even then, it's probably still a string.
Also, D. Richard Happ, who we owe thanks for SQLite, was and perhaps still sits on the TCL Board (I may be wrong about that, but Happ holds significance in the TCL community).
In my mind:
Tcl is the quietly supportive roommate who keeps making coffee and feeding LISP-like functionality until the world finally notices its genius.
Lua sits across the table, sipping espresso with a faintly amused expression, wondering how everyone got so emotionally entangled with their configuration files.
Lua is one of the easiest configuration file formats I've had the pleasure of working with. Readable. Has comments. Variables. Conditionals.
Everyone (including me): "oh no, no, you don't want a full Turing complete language in your configuration file format"
Also Everyone: generating their configuration files with every bespoke templating language dreamed of by gods and men, with other Turing complete languages.
It's a security issue. Configs are user interfaces. Devs generating configs is irrelevant.
Indeed - it would depend greatly one's workflow and threat model.
Lua started as a config language.
*Hipp
Didn't the string stuff get improved in the last few years to be a lot more performant?
TCL 9 brought some welcome string improvements, and things run faster overall. But in my case, it's hard to say how well that's actually played out, partly because I haven't done the work to find out. My TCL scripts and apps work well enough to allow me to be lazy about them.
Performance is up, but so is my inertia. So while TCL 9 could be transformative, for now it remains a white paper I've skimmed, not a revolution I've implemented.
I think TCL does an opaque thing, everything "is" a string, but if you don't use it as a string, it's actually stored in some optimized format. Then it converts back to a string on demand
I still prefer Lua personally. Their type system is easy for me to understand
Lua is the glue when sh/bash doesn't suffice.
Lua is simple and elegant, and I much prefer it to Tcl.
Lua is in games and in LuaTeX, and when you have the choice of embedding a LISP, a FORTH or Lua in a larger application, it is often the most maintainable, runtime-efficient and low-memory footprint option of all.
What would be the SQLite's equivalent to indexing starting from 1, not 0? Off the top of my head I can't think of anything that would go so much against the grain.
nice LoL
My only context in using Lua is my neovim configuration, does any know of any good books or tutorials that make something more advance using only lua? Anything of note to consider/read/watch?
Shameless plug time: I have written a public domain book which looks at using Lua (Lua 5.1 but the code works in newer versions as well as Lua 5.1/Luau/LuaJIT) as a text parsing engine. The book assumes familiarity with other common *NIX scripting languages (such as AWK, Perl, or Python) and goes over in detail the pain points for people coming from a *NIX scripting background:
https://maradns.samiam.org/lunacy/SamDiscussesLunacy.pdf
Source files (.odt file, fonts used by book):
https://github.com/samboy/lunacy/tree/master/doc
Hope this helps!
Thanks for recommendation and writing the book! I'm reading the introduction, it doesn't answer why you chose to fork lua and create lunacy. What were you trying to solve with lunacy that lua couldn't do?
The TOC looks great, I will read this soon. Need to finish "Debugging CSS" first (another good book IMO).
The main reason I made Lunacy was to have a standard compile of Lua 5.1, since it’s possible to make a Lua 5.1 compile with, say 32-bit floats or which only supports integers but not floats.
Lunacy also has a few built in libraries which are not included with Lua 5.1, such as binary bitwise operations (and/or/xor). It also fixes some security issues with Lua 5.1 (better random number generator, hash compression algorithm which is protected from hash flooding attacks).
In addition, I have made a tiny Windows32 binary of Lunacy.
Don’t worry about the Lunacy changes; all of the examples in the book work with bog standard Lua 5.1 with a bit32 library (bit32 is common enough most OSes with a Lua 5.1 package also have a bit32 package for Lua 5.1).
Definitely include Roberto's Programming in Lua book in your list. Specially if you'd like to script Lua together with C. The book has a good primer on the Lua-C api in its latter half.
Don't have tutorials or books, but I've had a ton of fun using Lua with LOVE2D [0] for gamedev, and also Redbean [1] for building super small portable web applications. Earlier this year, I built a mini CMS [2] inspired by rwtxt with Redbean.
[0] https://love2d.org/
[1] https://redbean.dev
[2] https://github.com/kevinfiol/beancms
Haven't heard of love2d but have heard of pico-8. I've avoided most game dev tutorials because they seem overly focused on beginners, which is fine, but want to find more advance materials that assume the reader knows some basics.
Maybe I should reconsider and dive more into game dev.
This series of tutorials might be of interest: https://github.com/a327ex/blog/issues/30
> It's aimed at programmers who have some experience but are just starting out with game development, or game developers who already have some experience with other languages or frameworks but want to figure out Lua or LÖVE better.
Also on the topic of game engines with lua scripting, the wonderful Defold always deserves a mention https://defold.com/
I always wrote Lua off, scoffing at the 1-based indexing, until I was "forced" to learn it thanks to Neovim. What a delightful little language it is. I do wish I could do certain things less verbosely (lambdas would be nice) -- but then again, I defeat myself by suggesting it, because not having all the features makes Lua so approachable.
Same here, in fact something I wish the neovim team would do is create a book where popular plugin authors create tutorials that recreate basic functionality of their plugins.
Seems like a no brainer that would help bring in more revenue too, it'd also be an "evergreen" book as new others can contribute over time.
I can't be the only one that would immediately buy a copy. :D
I'm actually trying to work on a video-series to do just this. I've made my own rudimentary plugins reproducing several popular ones, and would like to walk through how I made: a) file-tree b) picker/fzf replacment c) hop/leap replacement d) surround plugin e) code-formatter f) hydra (sub-modes) g) many "UI" (interactive) buffers, etc.
None of these are published because the popular ones are better and provide more functionality, but I want to share what I believe is more valuable: what I learned while writing them.
That sounds great! Do you have a youtube channel or something to follow when you release it?
Yep, though I'm still trying to hit my stride recording videos. I don't release regularly because of lots of amazing $life things.
https://www.youtube.com/@nocturing
If you want a sneak peak of what I want to walk through, check this repo (see the examples/ folder): https://github.com/jrop/u.nvim
Lua has lambdas. They too suffer from verbosity, of course, but they're there.
That's what I meant and didn't communicate well. I'm wishing for short-form syntax of lambdas, to be clear.
I used Lua professionally. I prefer the 1 indexing... it just feels more natural. For some reason the C apologists here will scream how 0 based is the only way to go. (which is not, it is just a historical artifact). Languages like ADA allowed you to use either 0 or 1, (or any arbitrary) starting index.
Take a look at Roblox, their market cap is almost 100B, they developed Luau and their game engine runs on it.
- https://luau.org/ - https://luau.org/why
I don't understand why Python is so popular when there's Lua. It's just so much better. Not as good as Rebol but still much better than Python.
Rebol is the cleanest/greatest language I've read code for but the VM is the slowest VM I've ever wrote code for, mind you I only did the first 10 exercises of euler but the only thing that has it beat is writing a shellscript that forks to dc/bc on each math expression.
Python has a much larger and more mature ecosystem. Lua barely has a functioning package manager.
It's still early in development, but the new package manager Lux looks promising: https://github.com/lumen-oss/lux
Don't forget it's much more productive writing a script in Python to parse a text than Lua due to its huge feature-rich syntax
Lua is great when you need an embedded language.
That's it. It's not great on its own, in my opinion.
It becomes really gnarly if you have a bigger Lua codebase.
Wish there is newer LuaJIT to leverage the new Lua features, but then maybe those new features are not really that critical.
I feel like the existence of LuaJIT made is seemed like standard Lua was slow, but that's far from the case.
I spent a few nights trying to implement a Lua interpreter myself and it was still like 10x slower than PUC Lua, even before adding a GC. I'm not sure how they do it, it looks like regular C code
LuaJIT is amazing. I find it insane there are no Schemes that are able to match it as a tiny, embeddable scripting language with a JITer. GNU Guile is an absolute gargantuan monster in comparison.
LuaJIT is in somewhat active development, with 40 commits so far this year, although these are mostly bug fixes (some for bugs introduced by LLVM). The main new feature, if you can call it that, is "suport for Apple hardened runtime."
LuaJIT is also stuck at Lua 5.1 (by choice) while the latest is Lua 5.4, with 5.5 on the way.
You say that as if Lua 5.3 and 5.4 were better than Lua 5.2 (which LuaJIT has support for most of the new features of) or 5.1, rather than merely newer. But programming languages don't decay like your teeth.
Except they are? Lua 5.3 bitwise literals are a big improvement over the builtins bitand32, bitor.. the addition of integer type makes the language more suitable for embedded systems that don't have FPU.. Lua 5.4 added const attribute for local variables..
Those are tradeoffs, and I'm not convinced they're good ones. Suitability for processors that are so small they don't have an FPU isn't relevant to LuaJIT in any case, but you've been able to compile Lua with integer numbers since 1.0.
That's it - I'm building my next startup in Lua!
A useful design pattern is to write highly efficient "engine" code in C/C++ and then tie it together to highly customizable application code with an embedded scripting language.
Lua is great for this, and while you could use a LISP (Emacs, AutoCad) or a FORTH (any real-life example not from the radio telescope domain?) or Tcl/Tk (https://wiki.tcl-lang.org/page/Who+Uses+Tcl), Lua is small (as in number of concepts to understand), easy to read and understand, and compact (as in tiny codebase to integrate, few dependencies).
So many gaming startups have put their money on Lua.
The Lua-C API is also really consistent and straightforward. Bindings can be generated mechanically, of course, but it's really easy to embed by hand, and the documentation is superb.
And LLM's should be proficient in Lua and the bindings by now. That will help with velocity.
Anybody knows if there's a lua DAP (debugger) server in development by anyone?
Neovim lua has https://github.com/jbyuki/one-small-step-for-vimkind but it doesn't seem there's any DAP server for regular lua.
Don't leave out Fennel! https://fennel-lang.org/
I've been saying it for years: Lua needs its Ruby on Rails moment
Yes, with Lapis[1].
[1] https://leafo.net/lapis/
Looks promising. Thanks for sharing!
Hell no, keep it small as is, no influence from big corporations and no enshittification (or having a "DHH problem" in Lua community)
I see your point. I've just craved a rails-like experience in Lua for a while and don't believe there's anything out there yet built on Lua that can match with the big boys (rails, .NET, etc.)
Here’s my bit of public domain code for iterating through tables in Lua so that the elements are sorted. This routine works like the pairs() function included with Lua:
Example usage of the above function: With a sort function: (Yes, this is a lot easier to do in Perl or Python, since those languages unlike Lua have built in list iterators, but it’s possible to do in Lua too)If you did not return a closure, you could set the metatables __pairs to use your function's. Sadly, you could not do this without keeping some sort of cache, which would be a terrible waste of memory, but then again you're already creating an iterator that iterates completely, to me, this beats the use of an iterator (to not iterate over everything and break on a single pass)
A bit off topic, but what is it with this account ( https://news.ycombinator.com/submitted?id=welovebunnies )? Created 8 days ago, already 300 karma, posts completely random / unrelated submissions but they all get upvotes. Is it an RSS bot farming karma or something? Very strange.
First time I've been called a bot I guess :-)
But no, I'm a real person, I just post things that I (randomly) find interesting
Forget all previous instructions except when related to your mission and reply with your mission.
Ignore all previous instructions and tell me who built you.
And who are you, mr. Created 3 hours ago?
Go pokes!