Love the author's mentality. While I would almost definitely not pick Lua (I'd probably pick Go), I like how they arrived at their decision. Nicely done.
Why I chose Lua for this blog
121–130 of 159 posts
Re: Why I chose Lua for this blog
#122I worked with Lua for awhile but never got over the 1-based indexing.
Re: Why I chose Lua for this blog
#123Kinda curious why you did not go with OpenResty?
Re: Why I chose Lua for this blog
#124Kinda curious why you did not go with OpenResty?
I guess it provides less freedom/flexibility on the dev side. You're forced to use LuaJIT, and you're forced to buy into OpenResty's coroutine paradigm where global variables act weird, and stuff like that. Also I bet it doesn't play super nice with LuaRocks. Totally valid choice to make, but in my opinion OP is missing out. OpenResty is state of the art and has a ton of great libraries embedded in it. It's "batterie…
Re: Why I chose Lua for this blog
#125Re: Why I chose Lua for this blog
#126Earlier quoted context omitted.
Nah. There are ways to mitigate the blast radius of experiments like this. You can't utterly wrap developers up in cotton wool. Ultimately, people learn strong lessons from screwing up. You can at least make sure they're doing this learning within a sandbox in which the damage is contained. Like, maybe containerising it so it has limited access to anything that could do any real damage. If somebody builds a blogging…
I am not exactly sure about using containers (most likely you mean docker/podman) as sandboxes... Please correct me wrong but for a better form of sandboxing, I would recommend something like microvm and the bottlefire thing which was recently shared if that might pique your interest as I found it to be interesting and then using it with something like https://github.com/Zouuup/landrun There is also tinykvm and other…
Re: Why I chose Lua for this blog
#127For example, take Javascript. With a runtime like Bun, you would have the primitives to serve some HTTP and talk to SQLite right there in the core. And here's the good news, if you carefully implement only the things that you need for your project, you probably don't need NPM. You can write it all on your own, you can peek at how NPM authors solved the problems you run into, but you still can make it all your own. This would leave you with this amazing retrocompatible language with lots of mindshare to boot.
Really, you don't need that whole ecosystem if you're solving your own problems and are not required to interface with someone else's library. And no one is forcing you to use it.
Or you could take Python, and it has a few single-file web frameworks. You can go with one of them and the standard library a very long way. No one tells you you must use any of FastAPI, Jinja, Flask, Django (anyone remembering Pyramid?), SQLAlchemy...
Or you could write it in Go, SQLite module being your only external dependency. You can even pin your go.mod to a particular version of the compiler so you're not bothered with incompatible changes, or changes at all.
Or, you could whip up Perl... but yeah. CGI.pm and DBD::SQLite are not in the core. And anything else has a litany of CPAN dependencies with their quirks. No, don't whip up Perl.
All I'm saying there's nothing that makes Lua somehow inherently more suited to your philosophy than any other mainstream language. Except maybe to be different. And you're still pulling in 29 luarocks, aren't you?
Re: Why I chose Lua for this blog
#128Earlier quoted context omitted.
But "broken your blog" could mean "shell access to your blog server" -- is there no risk of illegal activities happening on that server that put the owner at risk? Like, I don't know, drug trade or child porn or whatever?
Philosophically: L'État, c'est moi, build your crappy cgi scripts with nginx or apache all from the CLI and all in vim and you will understand. Practically: Ports 22, 80, and 443 open and directly accessible from 0.0.0.0/0 is extremely manageable.
Re: Why I chose Lua for this blog
#129I don't know man, every time I tried to learn Lua (to write nvim plugins and HammerSpoon spoons) I disliked the ergonomics of the language. I don't understand why people say it's an easy language— easy ≠ simple
It all depends on what you been exposed to in the past, right? I find Lua simple because it is a minimalist language in which there are very few things to learn. You can buy "Programming in Lua" for the version you want to use and with a single book you learn about basically all of the language and its internals. That is not the same with some other languages.
> I find Lua simple
The comment you've replied to is correct: "easy ≠ simple". Lua is indeed simple, but it chooses simplicity over ease-of-use. For example, even printing the contents of a table requires explicit logic.
OTOH Python, for example, prioritises ease-of-use: `l = [1, 2, 3]; print(l)` does what you'd expect. But Python only achieves this ease at the expense of simplicity: not only does the implementation of `print` need to be more complex, its output can be complex and unpredictable as well - for example, in the case where `l` refers to itself.
Re: Why I chose Lua for this blog
#130Earlier quoted context omitted.
Philosophically: L'État, c'est moi, build your crappy cgi scripts with nginx or apache all from the CLI and all in vim and you will understand. Practically: Ports 22, 80, and 443 open and directly accessible from 0.0.0.0/0 is extremely manageable.
Why would anyone today leave port 80 open? I do https by default even for my blog.