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

Lua 5.5

lua.org

Post reply on HN
Print view View original

61–70 of 138 posts

Re: Lua 5.5

#61

Post by kstrauser »

shmerl wrote: post #53
upofadown wrote: post #52

Earlier quoted context omitted.

My understanding is that there was a language fork after 5.1. One thing was a complete reworking of how math works. It used to be just floating point for everything but the new idea was to make it like Python 3. So most operations are float/integer with some weird exceptions. As with any language fork there will be some who stay and others who switch to the new thing. Often a fork will drive people away from a partic…

Language fork is unfortunate. Python situation isn't much of a fork really. Python 2 is basically EOL.

There’s no “basically”. Stick a fork in it; it’s done: https://www.python.org/doc/sunset-python-2/

Re: Lua 5.5

#62

Post by electroglyph »

shmerl wrote: post #60
ksymph wrote: post #56

Earlier quoted context omitted.

Lua's nature as a primarily embedded language means backwards compatibility is not guaranteed between any version. If 5.2 was a language fork then so was 5.3, 5.4, 5.5, etc. (5.2 did have some more significant changes though) For that reason luajit staying at ~5.1 actually works in its favor. Rather than trying to follow the moving target of the newest version, it gives a robust focal point for the lua ecosystem, whi…

I don't see a reason not to update LuaJIT still. Changes in Lua aren't just version numbers, it should be improving something, meaning that would be missing in LuaJIT.

the beauty of open source is there's nothing stopping you! this might be your calling. best of luck

Re: Lua 5.5

#63

Post by shmerl »

kstrauser wrote: post #61
shmerl wrote: post #53

Earlier quoted context omitted.

Language fork is unfortunate. Python situation isn't much of a fork really. Python 2 is basically EOL.

There’s no “basically”. Stick a fork in it; it’s done: https://www.python.org/doc/sunset-python-2/

Which is better than this mess with Lua situation.

Re: Lua 5.5

#64

Post by ksymph »

shmerl wrote: post #60
ksymph wrote: post #56

Earlier quoted context omitted.

Lua's nature as a primarily embedded language means backwards compatibility is not guaranteed between any version. If 5.2 was a language fork then so was 5.3, 5.4, 5.5, etc. (5.2 did have some more significant changes though) For that reason luajit staying at ~5.1 actually works in its favor. Rather than trying to follow the moving target of the newest version, it gives a robust focal point for the lua ecosystem, whi…

I don't see a reason not to update LuaJIT still. Changes in Lua aren't just version numbers, it should be improving something, meaning that would be missing in LuaJIT.

LuaJIT does have some backported features from newer versions. But Mike Pall -- the mad genius behind LuaJIT -- has made it clear he doesn't agree with many of the changes made in newer versions, hence why it's staying where it's at.

Re: Lua 5.5

#65

Post by ori_b »

shmerl wrote: post #49
dividuum wrote: post #44

Earlier quoted context omitted.

Not true. It's getting a constant stream of bugfixes. It's also not "stuck" on Lua 5.1, but is deliberately not following Lua's path, except for some backports. There's also a recent post about how a LuaJIT 3 might work.

OK, then I got some wrong info. If it's stuck at it deliberately, then it's worse. May be someone should fork it and bring it up to date with recent Lua versions. Why is this split needed?

> May be someone should fork it and bring it up to date with recent Lua versions. Why is this split needed?

Good news, you're someone. If you care, you're welcome to go for it.

Re: Lua 5.5

#66

Post by kevin_thibedeau »

rhelz wrote: post #48
cturtle wrote: post #4

One of the new features I found interesting, declarations for global variables, is buried in the reference manual. Here's a link to the section that discusses it: https://www.lua.org/manual/5.5/manual.html#2.2

Why did you find this interesting?

It indicates paving the path for local scoping in a future release where Lua 5 code is upgraded with global declarations to keep it working.

Re: Lua 5.5

#67

Post by GaggiX »

bsimpson wrote: post #59

I recently happened into Balatro through a Game Pass trial. I fell deep down the rabbit hole of trying to get it to run on SteamOS. It's fascinating to see a commercial game whose source is easily read inside the application bundle, and all the modding opportunities it opens up. (It's written in Lua with LÖVE.) Balatro was one of the biggest games of last year, and I'm sure the tinkerability was a big catalyst to tha…

I managed to run Balatro on a Trimui Brick on a very minimalist Linux distro, steamos should be easy.

Re: Lua 5.5

#68

Post by bsimpson »

GaggiX wrote: post #67
bsimpson wrote: post #59

I recently happened into Balatro through a Game Pass trial. I fell deep down the rabbit hole of trying to get it to run on SteamOS. It's fascinating to see a commercial game whose source is easily read inside the application bundle, and all the modding opportunities it opens up. (It's written in Lua with LÖVE.) Balatro was one of the biggest games of last year, and I'm sure the tinkerability was a big catalyst to tha…

I managed to run Balatro on a Trimui Brick on a very minimalist Linux distro, steamos should be easy.

That's rad!

Getting it to run in KDE was straightforward. I've gotta figure out why it instacrashes in SteamOS game mode.

Re: Lua 5.5

#69

Post by shakna »

kstrauser wrote: post #61
shmerl wrote: post #53

Earlier quoted context omitted.

Language fork is unfortunate. Python situation isn't much of a fork really. Python 2 is basically EOL.

There’s no “basically”. Stick a fork in it; it’s done: https://www.python.org/doc/sunset-python-2/

It might not be supported by the consortium, but python2 still lives, slowly, in one place or another:

> The RHEL 8 AppStream Lifecycle Page puts the end date of RHEL 8's Python 2.7 package at June 2024.

https://access.redhat.com/solutions/4455511

At this point in RHEL it is only "deprecated", not "obsolete".

Post reply on HN