I use Lua for almost all my custom tools these days.
Why I chose Lua for this blog
31–40 of 159 posts
Re: Why I chose Lua for this blog
#32I 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's easy, but the 1 indexes and global by default suck
Re: Why I chose Lua for this blog
#33I 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's easy, but the 1 indexes and global by default suck
The 1 indexes are only a difference from what you're used to. Lua was made by mathematicians, who of course wanted to address the first element as 1, the second element as 2, etc.
0-indexing makes sense in the context of C where the index operator is syntactic sugar for pointer arithmetic. In higher-level languages like C# and Python and others, it's pretty much just a leftover habit from C devs that we all got used to.
Global by default is a perpetual issue, agreed.
Re: Why I chose Lua for this blog
#34Earlier quoted context omitted.
You may want to benchmark lua versus luajit if you are writing scripts or other short-lived programs. JIT-compiled languages aren't generally faster in starting up, they generally are used to speed up long-lived programs that have hot sections.
LuaJIT bucks the trend of slow-warmup JITs. It is extremely quick to compile and load, and its interpreter is very fast -- faster than the JIT-compiled code from LuaJIT v1 IIRC, and certainly faster than the interpreter of Lua. It wasn't until LuaJIT that I realized that JIT didn't inherently have to be these slow lumbering beasts that take hundreds of milliseconds just to wake from their slumber.
Yet I've witnessed Lua 5.1 launching faster than luajit for some of my use cases.
My point still stands though. Don't just use LuaJIT thinking it will magically make things faster in all cases. If you are embedding, LuaJIT is a no-brainer. If you are using a stand-alone interpreter, measure if you care about reality.
Re: Why I chose Lua for this blog
#35I 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.
Still a good project when one learns a new programming language.
Re: Why I chose Lua for this blog
#36I 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.
Re: Why I chose Lua for this blog
#37I 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.
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.
Re: Why I chose Lua for this blog
#38I 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 had that thought too. My own blogging engine is ~100 lines of lua that accomplishes the same as you describe, plus RSS, with one additional library for markdown parsing. The author mentions Mustache templates and WebMentions, but ten dependencies still seems like a lot; I wonder what they are.
Re: Why I chose Lua for this blog
#39I 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.
Re: Why I chose Lua for this blog
#40Earlier 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.
Erlang has multiple higher level barrier of entries than other languages. For starting, its syntax.