Re: [mildly OT] Some info about Python

[Stefan <ste@...>]

Hello,

Am 15.01.2020 um 16:59 schrieb Lorenzo Donati:
> Moreover the recent StackOverflow Developer Survey Results show
> Python as one of the most known language among programmers (even among 
> professionals), while Lua doesn't even make it on the list.
>
> https://insights.stackoverflow.com/survey/2019#technology
>
> https://insights.stackoverflow.com/survey/2019#technology-_-most-loved-dreaded-and-wanted-languages 
>
>
> https://insights.stackoverflow.com/survey/2019#technology-_-what-languages-are-associated-with-the-highest-salaries-worldwide 
>
>
> I thought it could be useful info to share.

Of course everybody loves Python because of powerful libraries
and easy scripting. It does not make any sense to start another
full-fledged Better Version Of Python That Is Actually Lua.

I like Python alot myself and have written many programs in it;
professionally too.

Python perfectly fills the general-purpose scripting niche, where
programs are usually text files only, written and maintained by a
single person and performance just needs to be good enough for
interactivity, i.e. when you can call "python my_script.py" and
don't have to wait multiple seconds for JVM/.Net startup.
Or to build a simple GUI without jitters (has anybody seen a Ruby
GUI in the wild? I haven't). A Python example would be the Linux
Mint update manger:
https://github.com/linuxmint/mintupdate

But anything beyond that and it becomes tedious. I once worked with
a >1MLOC wxPython project and it was an unbelievable heap of garbage.
A depressing experience - apparently 40 man-years were poured into it.

And Python also has glaring issues with the upcoming multicore
architectures that will soon be the new standard.
And Jython/IronPython are not the solution - they negate the main
benefits of CPython.

> I'm just sad because while still loving Lua, it just seems that there is 
> no point in investing further time in developing in Lua, unless one has 
> a very specific need.

Here is an example:
My current project is an HTTP and Websocket server for interactive web
sites and online games. It connects each request to one user script.
I really want to use Lua for this since it fits perfectly IMO:
 * Friendly for non-programmers - "like JavaScript without brackets"
 * Web sites are usually a big collection of small scripts and media
   files, not one monolithic program that does everything.
   "And I also want a chat and an image gallery in my webshop"
 * Extremely fast interpreter startup (>100K/second/core)
 * Low memory overhead even for many thousand interpreter states
 * Bytecode caching is very easy

Because Websockets are long-lived full-duplex communication channels,
they are very problematic with "big" scripting languages like PHP/Ruby/
Python/Perl since they use up a huge amount of memory per connection.
And browsers allow up to 200 connections, so even one malicious user
can almost DOS your server in that case.

The NodeJS solution is to only run one script that handles all
connections. This has good performance (memory leaks aside) for small
programs, but it doesn't scale without ugly hacks and makes user and
application seperation very hard - the "LAMP stack" is successful for
a reason.

But with Lua many states aren't a problem and the simpler, more secure
and scalable Apache model can be used! And it is beginner-friendly!

So, the only show stopper is the lack of a standard library.

I'm currently experimenting with a new C module system and my goal is:
 * Fast state creation and destruction even with many C functions
 * Only allow thread-safe C functions because the Lua states are run
   by multiple threads
 * Everything statically linked since using Lua's require/dlopen for
    every request doesn't make any sense (dlopen has a cache, too)

Currently I think the best solution is something like the luaL_requiref
that luaL_openlibs uses, but with a metatable to only load what is
actually used.

An open repository of robust and portable C functions that can be
chosen to taste and staticially linked with a given Lua version
would also be a better fit with Lua, IMO.
Dynamic linking assumes that there is "the" Lua with a stable ABI and
that is just not how Lua is actually used.

> I won't comment further, since I'm bored to death to beat dead horses.
>
> Cheers!
>
> -- Lorenzo

Sorry to hear that!

The Lua ecosystem is certainly in a sorry state right now, but let's
just hope that this can and will change in the future :)

Greetings