Lua version census - the results!

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Lua version census - the results!

Hisham
Hi everyone!

It took a bit longer than I expected, but here are the results for our unscientific Lua version census!


(Google's UI cuts off some longer names, so some entries in graphs appear to have no label — just hover over the bars and it will show you the label.)

Thank you all for participating!

-- Hisham

Reply | Threaded
Open this post in threaded view
|

Re: Lua version census - the results!

Hisham
Ah, I forgot to include it: here's the raw csv of the entries, in case anyone wants to do some deeper inspection of the data!

-- Hisham

On Tue, 28 Jan 2020 at 16:46, Hisham <[hidden email]> wrote:
Hi everyone!

It took a bit longer than I expected, but here are the results for our unscientific Lua version census!


(Google's UI cuts off some longer names, so some entries in graphs appear to have no label — just hover over the bars and it will show you the label.)

Thank you all for participating!

-- Hisham


Lua version census.csv.zip (10K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Lua version census - the results!

Luiz Henrique de Figueiredo
In reply to this post by Hisham
> here are the results for our unscientific Lua version census!

Could you please comment on what the results mean. Any surprises? Any
points on which to focus attention?

Reply | Threaded
Open this post in threaded view
|

Re: Lua version census - the results!

Javier Guerra Giraldez
On Tue, 28 Jan 2020 at 16:43, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
> Could you please comment on what the results mean. Any surprises? Any
> points on which to focus attention?


the thing that surprised me is the popularity of Lua 5.1   The usual
answer is because of LuaJIT stagnation, but Lua5.1 bars are
significantly higher than LuaJIT's so i'm not sure it's the main
reason.

maybe it's commonly considered a "good enough" version and so there's
little pressure to update?  or is there any big application that uses
it and tips the scale?

what doesn't surprise is the low score of Lua5.2  I think 5.3 is much
more attractive.


--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: Lua version census - the results!

Coda Highland


On Tue, Jan 28, 2020 at 6:46 PM Javier Guerra Giraldez <[hidden email]> wrote:
On Tue, 28 Jan 2020 at 16:43, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
> Could you please comment on what the results mean. Any surprises? Any
> points on which to focus attention?


the thing that surprised me is the popularity of Lua 5.1   The usual
answer is because of LuaJIT stagnation, but Lua5.1 bars are
significantly higher than LuaJIT's so i'm not sure it's the main
reason.

maybe it's commonly considered a "good enough" version and so there's
little pressure to update?  or is there any big application that uses
it and tips the scale?

what doesn't surprise is the low score of Lua5.2  I think 5.3 is much
more attractive.


--
Javier


Noteworthy games using Lua 5.1: World of Warcraft, Roblox, CryEngine, FCEUX

Noteworthy non-games using Lua 5.1: Adobe Lightroom, Autodesk 3ds Max, Wireshark

Another point of consideration is that 5.1 was the main Lua release for almost six years. 5.2 lasted less than three and never generated any noteworthy hype while bringing a controversial compatibility break along with it, effectively giving 5.1 additional time in the spotlight. The fact that LuaJIT was drop-in compatible with 5.1 meant that targeting 5.1 was an even better idea.

The fact that the common language subset shared among the whole 5.x series (including LuaJIT) is so big also means that many developers are still going to target 5.1 and eschew the newer features for the sake of compatibility, which further bumps 5.1's penetration -- if you count projects that can support multiple Lua versions, you would expect the oldest common version to have the largest base. 

And for big commercial projects, there's little incentive to bother upgrading -- if it ain't broke, and all that.

/s/ Adam
Reply | Threaded
Open this post in threaded view
|

Re: Lua version census - the results!

Hisham
In reply to this post by Javier Guerra Giraldez
On Tue, 28 Jan 2020 at 21:46, Javier Guerra Giraldez <[hidden email]> wrote:

>
> On Tue, 28 Jan 2020 at 16:43, Luiz Henrique de Figueiredo
> <[hidden email]> wrote:
> > Could you please comment on what the results mean. Any surprises? Any
> > points on which to focus attention?
>
>
> the thing that surprised me is the popularity of Lua 5.1   The usual
> answer is because of LuaJIT stagnation, but Lua5.1 bars are
> significantly higher than LuaJIT's so i'm not sure it's the main
> reason.

Note that LuaJIT's results are split over LuaJIT 2.0 and 2.1.

Given the complexities of people running different Lua versions for
different applications and making different choices when supporting
multiple versions, it's not entirely straightforward to draw
conclusions. That's one of the reasons why I shared the raw response
data, so that people wishing to make more detailed analyses are able
to do so.

> what doesn't surprise is the low score of Lua5.2  I think 5.3 is much
> more attractive.

Yeah, I sort of expected that as well.

-- Hisham

Reply | Threaded
Open this post in threaded view
|

Re: Lua version census - the results!

Lorenzo Donati-3
In reply to this post by Coda Highland
On 29/01/2020 02:35, Coda Highland wrote:

> On Tue, Jan 28, 2020 at 6:46 PM Javier Guerra Giraldez <[hidden email]>
> wrote:
>
>> On Tue, 28 Jan 2020 at 16:43, Luiz Henrique de Figueiredo
>> <[hidden email]> wrote:
>>> Could you please comment on what the results mean. Any surprises? Any
>>> points on which to focus attention?
>>
>>
>> the thing that surprised me is the popularity of Lua 5.1   The usual
>> answer is because of LuaJIT stagnation, but Lua5.1 bars are
>> significantly higher than LuaJIT's so i'm not sure it's the main
>> reason.
>>
>> maybe it's commonly considered a "good enough" version and so there's
>> little pressure to update?  or is there any big application that uses
>> it and tips the scale?
>>
>> what doesn't surprise is the low score of Lua5.2  I think 5.3 is much
>> more attractive.
>>
>>
>> --
>> Javier
>>
>>
> Noteworthy games using Lua 5.1: World of Warcraft, Roblox, CryEngine, FCEUX
>
> Noteworthy non-games using Lua 5.1: Adobe Lightroom, Autodesk 3ds Max,
> Wireshark
>
> Another point of consideration is that 5.1 was the main Lua release for
> almost six years. 5.2 lasted less than three and never generated any
> noteworthy hype while bringing a controversial compatibility break along
> with it, effectively giving 5.1 additional time in the spotlight. The fact
> that LuaJIT was drop-in compatible with 5.1 meant that targeting 5.1 was an
> even better idea.
>
> The fact that the common language subset shared among the whole 5.x series
> (including LuaJIT) is so big also means that many developers are still
> going to target 5.1 and eschew the newer features for the sake of
> compatibility, which further bumps 5.1's penetration -- if you count
> projects that can support multiple Lua versions, you would expect the
> oldest common version to have the largest base.
>
> And for big commercial projects, there's little incentive to bother
> upgrading -- if it ain't broke, and all that.
>
> /s/ Adam
>

Another data point: last time I checked wxLua was based on 5.1 only (and
besides, it seems also abandonware, now). It was a nice environment to
do OS and GUI stuff.

Latest editions of SciTE editor still embed Lua 5.1 IIRC (I'm stuck with
an older version, so I can't confirm).

Reply | Threaded
Open this post in threaded view
|

Re: Lua version census - the results!

Paul K-2
> Another data point: last time I checked wxLua was based on 5.1 only (and
> besides, it seems also abandonware, now). It was a nice environment to
> do OS and GUI stuff.

wxlua has been under active development for the last 6 months
(https://github.com/pkulchenko/wxlua/graphs/contributors) and I've
made 8 releases during that period with the last one less than a month
ago (https://github.com/pkulchenko/wxlua/blob/master/wxLua/docs/changelog.txt).
It has added several new classes to the API and is up-to-date with the
current wxwidgets master branch. I guess I should do a separate
announcement to the maillist about this.

In terms of the Lua versions, it does support Lua 5.2 and 5.3 (there
were several recent changes for improved integer support) and I expect
it to work with 5.4 as well.

I unfortunately have no access to the wxlua home page
(http://wxlua.sourceforge.net/) and John Labenski hasn't responded to
my questions about making changes to it. I'm not sure who else may
have access.

Paul.

Reply | Threaded
Open this post in threaded view
|

Re: Lua version census - the results!

Egor Skriptunoff-2
In reply to this post by Lorenzo Donati-3
On Wed, Jan 29, 2020 at 6:50 PM Lorenzo Donati wrote:

Latest editions of SciTE editor still embed Lua 5.1 IIRC (I'm stuck with
an older version, so I can't confirm).


SciTE version 4.0.0 (august 2017) changed Lua from 5.1 to 5.3
https://www.scintilla.org/ScintillaHistory.html
 
Reply | Threaded
Open this post in threaded view
|

Re: Lua version census - the results!

Marc Balmer
In reply to this post by Luiz Henrique de Figueiredo


> Am 28.01.2020 um 22:43 schrieb Luiz Henrique de Figueiredo <[hidden email]>:
>
>> here are the results for our unscientific Lua version census!
>
> Could you please comment on what the results mean. Any surprises? Any
> points on which to focus attention?
>

I am positively surprised that a majority seems to use Lua in its original form and the current version 5.3.

- mb


Reply | Threaded
Open this post in threaded view
|

Re: Lua version census - the results!

nobody
In reply to this post by Coda Highland
On 29/01/2020 02.35, Coda Highland wrote:
> Another point of consideration is that 5.1 was the main Lua release
> for almost six years. 5.2 lasted less than three and never generated
> any noteworthy hype while bringing a controversial compatibility
> break along with it, effectively giving 5.1 additional time in the
> spotlight. The fact that LuaJIT was drop-in compatible with 5.1
> meant that targeting 5.1 was an even better idea.

Another part of that problem is that for a far too long, the only Lua
you could get on Debian/Ubuntu was Lua 5.1… Back then they didn't have
them slotted[1] and so everything was built against 5.1 and all you
could get was 5.1… which means that's what you defaulted to when
starting a new project, or else it "wouldn't run" on Debian/Ubuntu.

-- nobody

[1] (I don't know what the Debian term for that is… being able to have
different versions of a package installed at the same time.)

v
Reply | Threaded
Open this post in threaded view
|

Re: Lua version census - the results!

v
On Thu, 2020-01-30 at 20:26 +0100, nobody wrote:
> Another part of that problem is that for a far too long, the only Lua
> you could get on Debian/Ubuntu was Lua 5.1…

It's still a problem. If you want luarocks for Lua 5.3, it should be
built from source. I think there are like only few 5.3 libraries in
Ubuntu repository, like json parser and probably lpeg.
As a result, I have to pack pretty much all required stuff using local
luarocks tree with my application instead of, like, just listing
required packages to be installed (because end users do not want to
have fun with installing and configuring luarocks and libraries
installed using it, which would not be the case with apt).
--
v <[hidden email]>


Reply | Threaded
Open this post in threaded view
|

Re: Lua version census - the results!

Russell Haley


On Fri, Jan 31, 2020 at 10:57 AM v <[hidden email]> wrote:
On Thu, 2020-01-30 at 20:26 +0100, nobody wrote:
> Another part of that problem is that for a far too long, the only Lua
> you could get on Debian/Ubuntu was Lua 5.1…

It's still a problem. If you want luarocks for Lua 5.3, it should be
built from source. I think there are like only few 5.3 libraries in
Ubuntu repository, like json parser and probably lpeg.
As a result, I have to pack pretty much all required stuff using local
luarocks tree with my application instead of, like, just listing
required packages to be installed (because end users do not want to
have fun with installing and configuring luarocks and libraries
installed using it, which would not be the case with apt).
That's the same problem on all platforms that I work with: Windows, FreeBSD and Debian/Ubuntu (I didn't even try pacman when I was playing with an Arch distro and just went straight to sources). Windows doesn't have a built in package manager (besides Windows Store) so Lua either needs a "batteries" install like LuaForWindows or a complete package with LuaRocks and a compiler. I am working on solving the latter problem.

On FreeBSD we have finally got an up-to-date Lua 5.3.5 port, but there a number of other impediments, namely that the default Lua version is stuck at 5.2. That means if any application has a Lua requirement it defaults to 5.2. Andrew Gierth is working on fixing the "FLAVORS" build option (allows for version/flavor selection) but that is a point solution in my opinion. There are quite a few Lua packages in the ports tree, most of them are badly out of date and stuck at 5.2. Without building all Lua dependent packages with 5.3 and triaging the fallout, I don't know how we are going to fix these shortcomings on a FreeBSD wide scale. The pending 5.4 release will exasperate the problem. There are methods to build all the packages but I don't have time to implement them and the FreeBSD team that is responsible has been less than willing to oblige me. Luarocks is currently stuck at 3.0.3 in FreeBSD, but that's on me at the moment (will need to update the code review to 3.3.0). 

V's observation - in my opinion - is hand-in-glove with the "Lua needs a standard library" discussion. Do we *really* need  a standard library if Lua was as easy to extend as Node.js when used in conjunction with NPM?

Russ
--
v <[hidden email]>


Reply | Threaded
Open this post in threaded view
|

Re: Lua version census - the results!

Lorenzo Donati-3
In reply to this post by Paul K-2
On 29/01/2020 17:15, Paul K wrote:

>> Another data point: last time I checked wxLua was based on 5.1 only (and
>> besides, it seems also abandonware, now). It was a nice environment to
>> do OS and GUI stuff.
>
> wxlua has been under active development for the last 6 months
> (https://github.com/pkulchenko/wxlua/graphs/contributors) and I've
> made 8 releases during that period with the last one less than a month
> ago (https://github.com/pkulchenko/wxlua/blob/master/wxLua/docs/changelog.txt).
> It has added several new classes to the API and is up-to-date with the
> current wxwidgets master branch. I guess I should do a separate
> announcement to the maillist about this.
>
> In terms of the Lua versions, it does support Lua 5.2 and 5.3 (there
> were several recent changes for improved integer support) and I expect
> it to work with 5.4 as well.
>
> I unfortunately have no access to the wxlua home page
> (http://wxlua.sourceforge.net/) and John Labenski hasn't responded to
> my questions about making changes to it. I'm not sure who else may
> have access.
>
> Paul.
>
>
Thanks, good to know!

Reply | Threaded
Open this post in threaded view
|

Re: Lua version census - the results!

Lorenzo Donati-3
In reply to this post by Egor Skriptunoff-2
On 29/01/2020 19:22, Egor Skriptunoff wrote:

> On Wed, Jan 29, 2020 at 6:50 PM Lorenzo Donati wrote:
>
>>
>> Latest editions of SciTE editor still embed Lua 5.1 IIRC (I'm stuck with
>> an older version, so I can't confirm).
>>
>>
> SciTE version 4.0.0 (august 2017) changed Lua from 5.1 to 5.3
> https://www.scintilla.org/ScintillaHistory.html
>
Good to know, thanks!

Reply | Threaded
Open this post in threaded view
|

Re: Lua version census - the results!

Steve Litt
In reply to this post by Javier Guerra Giraldez
On Tue, 28 Jan 2020 19:45:30 -0500
Javier Guerra Giraldez <[hidden email]> wrote:


> the thing that surprised me is the popularity of Lua 5.1   The usual
> answer is because of LuaJIT stagnation, but Lua5.1 bars are
> significantly higher than LuaJIT's so i'm not sure it's the main
> reason.

What is LuaJIT stagnation? Is LuaJIT not effective for versions after
5.1? I just did a test using 5,000,000 iterations of count-down-and
print on Tcl, Ruby, Python, Lua (interpreted), Perl, C (compiled), and
LuaJIT. The prints were to stdout, and when the executable ran stdout
was redirected to /dev/null so I was testing the program and not the
system's print. The results were:

* Tcl took about 9.5 seconds
* Python, Ruby, and Lua (interpreted) about 4.5 seconds
* Perl about 1.6 seconds
* LuaJIT about 0.65 seconds
* Compiled C about 0.52 seconds

I'd say for an application needing speed (not bottlenecked by the
user), this makes LuaJIT very relevant.

SteveT

Steve Litt
February 2020 featured book: Thriving in Tough Times
http://www.troubleshooters.com/thrive

Reply | Threaded
Open this post in threaded view
|

Re: Lua version census - the results!

Coda Highland


On Sun, Feb 2, 2020, 11:13 AM Steve Litt <[hidden email]> wrote:
On Tue, 28 Jan 2020 19:45:30 -0500
Javier Guerra Giraldez <[hidden email]> wrote:


> the thing that surprised me is the popularity of Lua 5.1   The usual
> answer is because of LuaJIT stagnation, but Lua5.1 bars are
> significantly higher than LuaJIT's so i'm not sure it's the main
> reason.

What is LuaJIT stagnation? Is LuaJIT not effective for versions after
5.1?

It's very nearly unmaintained and hasn't seen any feature development in years. The community is trying to pick it back up but there's disagreements. It's still a good project but its future isn't necessarily stable, which can be a turn-off for some projects.

/s/ Adam
Reply | Threaded
Open this post in threaded view
|

Re: Lua version census - the results!

nobody
In reply to this post by Steve Litt
On 02/02/2020 18.12, Steve Litt wrote:
> What is LuaJIT stagnation? Is LuaJIT not effective for versions
> after 5.1?
>
> *snip*
>
> I'd say for an application needing speed (not bottlenecked by the
> user), this makes LuaJIT very relevant.

Unless you need coroutines that can yield across C calls.

And only if your data set is small enough… if you need to deal with
large amounts of data, you'll have to use 5.3 – LuaJIT still has the 2GB
limit.  (I'm not even sure if it has the emergency GC yet… some of my
"small large" programs barely fit in 2GB and they randomly die unless I
insert manual collectgarbage() calls before large allocations… Fun!)

And if you don't need 64-bit integers, or you're willing to deal with
the weird version in LuaJIT (and you write numbers as strings plus a
parsing function, or else it's ok if your code is LuaJIT-only because
Lua doesn't do 'ULL' suffixes on numbers but LuaJIT needs them or else
it's rounded into a double.)  (Oh and you don't need 64-bit bitops or
you're willing to make your own…)

And it also won't work if you want to use debug hooks on a separate
coroutine (e.g. abort after N instructions or on any attempted
call, for safely un-dumping some values).

And… (etc.)

  * * *

I personally don't really use LuaJIT anymore… when I need speed, it's
either for dealing with large amounts of data (which automatically
disqualifies LuaJIT…[1]) or I'm doing brute (generally mathy)
computations.  And then it either involves bit operations (where I'd
rather write Lua 5.3 or C with real operators than use the bit library),
or it's vector math… and getting that really fast means reusing vectors
instead of constantly throwing them away, which means you're not using
operators but functions ADD( a, b[, target] ) etc., which means you're
effectively writing weird assembly, only it's still slower than actual
assembly… so just let the C compiler do the work?

Sometimes the ffi is nice for exploration, but apart from that…  It's
been one time too many that input data is "a few MB at most" and then
actually there's one file that's a few hundred MB and LuaJIT just OOMs
out and you'd have to completely rewrite the program…  So I generally
end up writing 5.3, and very occasionally pushing hot loops to C (mostly
speed is just fine as-is).

-- nobody


[1]  Technically you could allocate stuff outside the preciousss 2GB
region and indirectly access stuff… but… ugh!

Reply | Threaded
Open this post in threaded view
|

Re: Lua version census - the results!

Javier Guerra Giraldez
On Tue, 4 Feb 2020 at 12:02, nobody <[hidden email]> wrote:
> deal with
> large amounts of data, you'll have to use 5.3 – LuaJIT still has the 2GB
> limit.

nop.  it has been 128TB for a while.   I've found it much more stable,
surprisingly.

--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: Lua version census - the results!

Egor Skriptunoff-2
In reply to this post by nobody
On Tue, Feb 4, 2020 at 8:02 PM nobody wrote:
(Oh and you don't need 64-bit bitops or
you're willing to make your own…)


LuaJIT 2.1 does support 64-bit bitops.
LuaJIT 2.0 doesn't.
12