HN Distilled

Essential insights from Hacker News discussions

Pluto is a unique dialect of Lua with a focus on general-purpose programming

Original Article

Hacker News Discussion

Certainly! Here's a summary of the themes discussed in the Hacker News thread about Pluto, with direct quotations from the users:

Perception as an Extended/Sugared Lua

A significant portion of the discussion revolves around Pluto's relationship to Lua, with many users viewing it as an evolution or a more feature-rich version of Lua. The design choices often draw comparisons to Lua's existing syntax and philosophy, with some appreciating the additions and others questioning them.

  • "Basically a more convenient/intuitive Lua for JS/C/Java/C++ users, plus optional static typing." - 90s_dev
  • "Yea. It really has some new features changes that I wished lua had." - Imustaskforhelp
  • "ModernMech: 
    \"Pluto aspires to be a version of Lua with a larger feature-set, that is all. Pluto is not a Lua-killer, an attempted successor, or any of any that. Many people (rightly so) love Lua precisely because of the design philosophy. And fundamentally, Pluto is a major deviation from Lua's design philosophy. Some may prefer this, some may not.\"
    "
  • "raincole: That's a Lua dialect so I don't know what you expect ;)"

Influence from Other Languages

Several users identified influences from other programming languages, particularly those with modern syntax features that are not present in standard Lua. This suggests that Pluto is not just an isolated extension of Lua but is also incorporating ideas from the broader programming language landscape.

  • "There's almost nothing in there that's like C or C++. But there's a definite influence of .NET and Cā™Æ with things like null-coalescing, null-conditionals, and interpolated strings." - JdeBP

Debate over the break N Syntax

The introduction of a break N statement for exiting nested loops was a major point of contention and discussion. Some found it a clear and useful addition, while others criticized it as poor design, arguing for alternative approaches.

  • "Well, this is a very poor design, one which makes me think what is the purpose of this project in the first place? ... This will break from Loop 2." - tzury
  • "If the numeric argument to break is what you find interesting, then this is exactly the same construct as the shell's break argument" - tzot
  • "What's poor about it, the numbers in the example? Think of them as inner/outer instead of "1" and "2". Without this kind of break statement, what do you do when you want to exit the outer loop, something like this probably: ... So this new feature fits with the general theme of pluto being a very-sugared lua." - philsow
  • "This is just poor language design. The reason one might find this cumbersome or problematic, is in the case of very large numbers of lines of code - sure, your example is visible and somewhat readable (arguable) in its current form - but tell me you won't have issues when the loop is 80 or 100 lines of code, and you need to add another inner loop as part of the development process. Are you now going to go through and be sure all your breaks are numbered properly? Are you really, though? Better, imho, would have been to introduce labels and "break
  • "Seems logical to me. 1 = break the current level, 2 = break 1 level up, 3 = break 2 levels up, etc. If you would do it the other way around, and then if you would add another for loop around the others, the breaks will break. You wouldn't expect that if you're modifying this code without looking at the current breaks or knowing about the break behavior." - gitaarik
  • "Adding a label to each loop and breaking by label (like in Rust) feels better and more resistant to code changes" - nextaccountic
  • "I don't particularly dislike that design, but Lua already supports a goto target label ::label:: so I think the following syntax would work better: ::outer:: for i = 1, 10 do ... ::inner:: for ii = 1, 5 do ... break inner ... break outer ... end end" - lifthrasiir

Interest in Alternatives and Comparisons

The emergence of Pluto also sparked discussions about other Lua-related projects or potential alternative approaches to extending Lua.

Technical Implementation and VM Considerations

A few comments delved into the technical underpinnings of Pluto, particularly concerning its use of the PUC Lua Virtual Machine (VM) and the implications of modifications to it.

  • "Interesting, apparently the source also includes a (modified) version of the PUC Lua VM. Why don't they just generate bytecode for the existing VM and leave it as is (unless the modified version somehow would significantly increase performance)? What changes were necessary to the original VM to implement the language?" - Rochus
  • "Some features like break N and default function args seem to be incompatible with the vanilla lua vm." - 90s_dev
  • "I think that would be achievable with plain PUC Lua bytecode; it's actually just a jump. The same for default function arguments; the VM doesn't actually care how many arguments the caller pushes on stack, and providing default values is easy to implement for the caller." - Rochus

Potential Usage and Ecosystem Concerns

Users also considered the practical aspects of adopting Pluto, including its integration with existing Lua tooling and libraries, and its overall documentation and stability.

  • "Well written and well documented. I will be trying it out. One drawback that I see is the use of packages from LuaRocks might be an issue and one does not really want to cope with compilation issues. But Lua is a beautiful language in any form." - yannis
  • "Is it possible to use Pluto alongside with a binding library such as Sol2[0]? I don't mind not being able to set type hints in the bindings to use in some IDE, I can create stubs for it manually." - matusnovak