Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The evolution of Lua, continued [pdf]

lua.org

Post reply on HN
Print view View original

111–120 of 175 posts

Re: The evolution of Lua, continued [pdf]

#111

Post by malkia »

nout wrote: post #103
thefaux wrote: post #94

Earlier quoted context omitted.

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. T…

Why is tail call optimization a dealbreaker for you? That's very specific...

IMHO, Tail call optimization makes sense only when it's enforced (like in clojure), otherwise it's wild.

Re: The evolution of Lua, continued [pdf]

#112

Post by 1313ed01 »

jll29 wrote: post #31
SchwKatze wrote: post #2

Lua is the SQLite of program languages, absolutely blast

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.

If you embed Lua you also get Fennel (almost LISP) support for free.

Re: The evolution of Lua, continued [pdf]

#113

Post by 1313ed01 »

ux266478 wrote: post #15
synergy20 wrote: post #4

Wish there is newer LuaJIT to leverage the new Lua features, but then maybe those new features are not really that critical.

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.

But you can use Fennel, that is a bit scheme-like if you squint a bit, and it transpiles to very nice Lua code in my experience.

Re: The evolution of Lua, continued [pdf]

#114

Post by ModernMech »

thadt wrote: post #32
mcdonje wrote: post #28

Earlier quoted context omitted.

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.

You could solve this with a capabilities permissions system. That way the config files can be written in the same language but have configured permissions that are different from the rest of the programming language. So you could restrict the config files from resources like threads, evaling source, making network requests and whatnot. Come to think of it you could even probably section off parts of the language behind capabilties such that the config files could be configured to be a not-Turing complete subset of the language.

Re: The evolution of Lua, continued [pdf]

#115

Post by spacechild1 »

realharo wrote: post #72
hackthemack wrote: post #42

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 brows…

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…

For me, JS has just too much magic, in particular the behavior of 'this', and lots of weird quirks, like "for in" vs. "for of". Lua, on the contrary, is very predictable and therfore easy to understand.

One killer feature of Lua (that surprisingly few scripting languages have) is stackful coroutines, i.e. you can yield across nested stack frames. Unlike JS or Python, there is no artificial split between generators and async/await and no need for function coloring.

If Lua had zero-based indexing, it would be close to perfect :)

Re: The evolution of Lua, continued [pdf]

#116

Post by 112233 »

spacechild1 wrote: post #115
realharo wrote: post #72

Earlier quoted context omitted.

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…

For me, JS has just too much magic, in particular the behavior of 'this', and lots of weird quirks, like "for in" vs. "for of". Lua, on the contrary, is very predictable and therfore easy to understand. One killer feature of Lua (that surprisingly few scripting languages have) is stackful coroutines, i.e. you can yield across nested stack frames. Unlike JS or Python, there is no artificial split between generators an…

Have you read large Lua codebases written by others? It is write-only language. All your "very predictable" features are overloadable, at runtime. No static typing to rest your eye on. It is a swamp.

"But, just write good code" you will say. Just like with Perl, some languages are designed in a way to discourage writing good code...

Re: The evolution of Lua, continued [pdf]

#117

Post by HackerThemAll »

DonHopkins wrote: post #85
dexwiz wrote: post #49

Earlier quoted context omitted.

Why do you write your years with a leading zero?

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 be…

[flagged]

Re: The evolution of Lua, continued [pdf]

#119

Post by plopz »

b_e_n_t_o_n wrote: post #98
hackthemack wrote: post #89

Earlier quoted context omitted.

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 '==…

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.

Funny you mention nobody uses var anymore when I just saw a post on here yesterday that perf critical code still uses var since it's faster

Re: The evolution of Lua, continued [pdf]

#120

Post by spacechild1 »

112233 wrote: post #116
spacechild1 wrote: post #115

Earlier quoted context omitted.

For me, JS has just too much magic, in particular the behavior of 'this', and lots of weird quirks, like "for in" vs. "for of". Lua, on the contrary, is very predictable and therfore easy to understand. One killer feature of Lua (that surprisingly few scripting languages have) is stackful coroutines, i.e. you can yield across nested stack frames. Unlike JS or Python, there is no artificial split between generators an…

Have you read large Lua codebases written by others? It is write-only language. All your "very predictable" features are overloadable, at runtime. No static typing to rest your eye on. It is a swamp. "But, just write good code" you will say. Just like with Perl, some languages are designed in a way to discourage writing good code...

I'm talking about the core language, which I do find very predictable. You can go crazy with any language. Lua is definitely not worse than Python or JS in this regard.

> No static typing to rest your eye on.

That goes for any dynamically typed language. How is that an argument against Lua in particular?

> Have you read large Lua codebases written by others?

No, because I use it as a scripting language, as intended. I totally agree that one shouldn't use dynamically typed languages for building large applications. But again, this is not specific to Lua.

Post reply on HN