I use Lua for almost all my custom tools these days. https://akkartik.name/freewheeling-apps https://git.sr.ht/~akkartik/gen_site
Why not Fennel?
Why I chose Lua for this blog
51–60 of 159 posts
Re: Why I chose Lua for this blog
#52Earlier quoted context omitted.
What? Are you serious? If you roll your own little cgi-bin perl script behind Apache you're far from vulnerable compared to, say, a WordPress website.
In any web application all data that comes from the outside world is potentially hostile. A decent web framework takes care of basic security measures, does input sanitation, provides referer checking and csrf for forms, etc. When you roll your own, your _are_ on your own to do that all properly yourself, if you even know all the potential pitfalls. And if you write your own cgi library like the op even more so. I'm…
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 app and the worst thing that happens is that they learn the value of sanitising your input, preventing SQL injection, that spam is an unfortunate fact of life, and that you should be very careful with how you manage cookies, I would consider that a _very_ big win for that novice developer.
Because we're talking about _developers_ here.
Re: Why I chose Lua for this blog
#53Earlier quoted context omitted.
In any web application all data that comes from the outside world is potentially hostile. A decent web framework takes care of basic security measures, does input sanitation, provides referer checking and csrf for forms, etc. When you roll your own, your _are_ on your own to do that all properly yourself, if you even know all the potential pitfalls. And if you write your own cgi library like the op even more so. I'm…
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 projects too which can simply take a binary and run it and I think that maybe developers should also try out all the different sandboxes and different things just for understanding as well I suppose too. To me, I really like playing with different form of sandboxes or such technologies in general.
Also do note that I am not sure if bottlefire provides sandbox/isolation by default as they mention Sandbox with Landlock seperately so I am now a bit confused if they provide sandbox by default or not as I previously thought it might have.
Re: Why I chose Lua for this blog
#54I liked this post, and I can totally understand where you’re coming from… But couldn’t anything you say about Lua also be said about JS? You mentioned how Lua wasn’t batteries included, so you try to limit your libraries. Couldn’t you say the same for JS? JS itself doesn’t change much, it’s the ecosystem. Couldn’t you just pick out some small and stable libraries the same way you could with Lua?
For me, it isn't 100% language warts. It is the customer experience that matters the most for me. Can I compile and ship my products to my customers without having them to install a VMs, container runtime or a language runtime? That the question that is critical for me.
I agree, I think that you must really like golang and how easy it can make cross compilation and how fast it is to build.
Golang has one of the best developer experiences and there are only very very few minor nitpicks I might have of the language but the whole ecosystem on packaging software and what not is just so easy and I love golang.
Re: Why I chose Lua for this blog
#55Earlier quoted context omitted.
Perhaps people's tastes vary? I find Lua an easy to use language. Easy to embed into C/C++ projects for scripting purposes. Also great when you can only spare 100 kB or so for an interpreter. (Arguably that was more important in the past.)
For me it is a much easier language than, say, Erlang.
but Erlang isn't a scripting language, it's a full-blown language with a rich ecosystem and framework (BEAM).
Re: Why I chose Lua for this blog
#56Earlier quoted context omitted.
For me it is a much easier language than, say, Erlang.
but Erlang isn't a scripting language, it's a full-blown language with a rich ecosystem and framework (BEAM).
Lua is also a full blown language, with an ecosystem as well.
Perhaps the road block that you've run into is because you've been treating it as just a scripting language.
Re: Why I chose Lua for this blog
#57I miss the days when "implement your own blogging engine" was one of the most popular learning projects for engineers. We should bring that back! Its such a great way to play around with client- and server-side development options in an almost zero-risk environment.
Everything web-facing, if it's not a static website delivered by a well-tested web server, happens in a high-risk environment. And doubly so, if, like in this case, stuff like custom cgi libraries are involved. One has to be either very confident in their skills to do that or very, very brave.
Ok. I'll bite. What are the risks? As I see it, if you screw up and someone get root access on your server, it's the worse that may happens and then shut down the whole thing is a click away.
Re: Why I chose Lua for this blog
#58I use Lua for almost all my custom tools these days. https://akkartik.name/freewheeling-apps https://git.sr.ht/~akkartik/gen_site
Why not Fennel?
Fennel looks quite great! And I love Lisp so there is definitely some allure there. I don't use it for mostly the reasons mentioned in OP:
* to minimize dependencies. Lua * for even greater stability. Fennel is pretty stable, but I use Lua 5.1 for the most part which hasn't changed since 2008 or so. I'm more extreme than OP in even avoiding later versions of Lua.
Bottomline: the reasons I like Lua have nothing to do with syntax and are much more about these operational meta characteristics of the language. If I cared more about syntax I'd be on Fennel in a heartbeat.
Re: Why I chose Lua for this blog
#59Lua 5.1 to 5.2 was a fairly significant breaking change; one that has forked the community to this day with luaJIT never coming on board. 5.2 to 5.3 also broke things with the introduction of integers but mostly at the level of bindings. There is also very little included in terms of standard library and while luarocks exists many significant packages go abandoned. There are breaking language changes in the upcoming 5.5 as well though they are relatively minor.[1]
All to say I think if long term compatibility is the primary goal there are probably better languages.
Have you already discounted php or perl?
Re: Why I chose Lua for this blog
#60I spend a lot of time blogging but all I use is a ~50 line Python file that converts my markdown pages to HTML, adds my template, and generates the ToC page. Then I push to GitHub Pages. I can't imagine needing more than that. Why are these blog stacks so complex?
I just write HTML directly (and use GitHub pages)