Lua is a viable alternative for JSON | Hacker News Reader

Lua is a viable alternative for JSON

8 pointscaligian13 comments

So json parsing comes in all sizes - from being implemented in the host lang or being in C - from being blazingly fast™ to simply being slow. What is indeed comical is that json is just half arsed js with none of the benefits of the host language. Every time a new lang is invented, someone reinvents the wheel in both c and the host lang.

I think lua's portability is great over here. I think that using lua C api for parsing data and then plugging into the host lang by remapping lua tables into serializable objects. You can also spawn several lua_threads and parallelize the conversion with all the benefits of lua and none of the restrictions. Is it possible that web servers run one or several long-running lua threads and perform table conversions on the fly and get better performance?

View on HN

Helm is a package manager for Kubernetes, and I am one of its maintainers.

Kubernetes objects can be defined in JSON or in YAML. Helm added a template language on top of YAML (based on Go's template system). It has always been an ugly thing, though it functions.

One thing we really wanted to do in the Version 3 release a few years ago was make it possible to write Kubernetes definitions in Lua instead of YAML. Then we wouldn't need a template language. Additionally, we got all the benefits of a procedural language and a way to do inheritance (which would have been profoundly powerful as an alternative to literally hundreds of lines of boilerplate YAML). And it made extending other people's work nearly trivial. All in all, it looked like a far superior path to YAML with text templating.

We produced a POC, defined a specification, and went a good way down the implementation path before a few people in the Helm community voiced such noisy objections that we walked it back.

Their primary objection was simply that they didn't want the procedural logic and the definition to be "the same thing." It was better, in their minds, to have a static file format with a template language layered on top, because that was an appropriate separation of concerns.

I've had a few years now to reflect. And I do think Helm would have been better with Lua.

Thanks for the great work on Helm! Ugly but functional is a great description of the Go templating syntax, and it is definitely my least-favorite thing in Helm.

Do you have links or anything else you can share on the Lua specification work? I'd be interested to see what a Lua-based chart would look like.

What’s the point? Nobody wants non-static aspects in their data transfer.

But if you like it: nothing is stopping you. Let your frontend send Lua and let your backend parse it.

As I mentioned in a previous reply¹ to a post of yours, 15 years ago I hit one of Lua's many footguns when I mistakenly used Lua as an alternative to JSON. To my knowledge no version or variant of Lua has made any progress on addressing this issue.

Lua is nice in many ways but unless you have a pressing need for it I'd recommend sticking with JSON. If you really want executable configurations please consider a newer language like https://dascript.org or https://cuelang.org which provide better type safety.

1- https://news.ycombinator.com/item?id=38030778

I misread this and expected that link to be a 15 year old HN comment from you to OP. I was impressed how quickly you recalled such an old conversation.

As far as security is concerned, consider this example. I want to use erlang with lua. Those two are miles apart but not really when you boil everything down to a lua table. All containers are tagged tables such as having a metatable key saying 'tuple' or 'struct'. Then you serialize them back and forth via BIFs. Any value having a function will reject entire query. Furthermore a simple hash code can be forwarded after sending the data. The attacker would have to sync the client and server and make hash changes on both ends but since he cannot fuck with the server none of his tampering would work because it will be outright rejected. As far as transformer modules (aka configs) are concerned, they will be carried out AFTER the hash.

Lua is a programming language, JSON a data serialization format. Aren't those apples and oranges? What am I not getting?

Lua started out as a configuration language (see the 2007 HOPL III paper) and still includes all required features to represent configuration information (or a data serialization format, as you put it), partly even more elegantly than JSON. And it is also is a programming language, which might raise security concerns when using it in a configuration-only application (where JSON is not critical because it is not a full programming language).

lua is a great tool for embedding functionality; rather than create a DSL from first principles, then regret it two years later because you're not a language designer, use something battle-tested.

Lack of code execution is a strong feature in data transfer formats/encodings. (Did I misunderstand you?)

If lua is used only as an adapter, that is an intermediary between the client and host converting objects to table and vice versa. You cannot dump function definitions (hence only serializable) except in bytecode. Who'd pass that around? You can store code as pure function strings and eval them as a module to provide a transformer module. Certainly a hash can be embedded in the code or sent over the server to prevent tampering with no security headaches

I'd wager that if the person you're responding to posted because they were unsure if they understood you correctly, then after this comment they're probably sure that they don't. (But I could be wrong.)

My bad. What i meant is that code execution is alright rather than dealing with macro magic in yaml or excessively verbose nesting like in toml

Reply on news.ycombinator.com