Gerenciador de pacotes.

[Yago Crispim]

Fala pessoal. Tudo certo?

Sou programador há alguns anos e tenho feito vários projetos em Lua nos últimos meses. 

Uma coisa que sinto falta no ecossistema da linguagem é a tal da conveniência.

Venho criando algumas aplicações web utilizando a linguagem e as ferramentas que encontrei são ou complicadas de configurar ou incompletas ou abandonadas.

O que acham de Lua na web?

Qual opinião de vocês sobre o por que Lua não é tão usada para esse fim?

[Eric Chiesse]

Sobre gerenciador de pacotes, já viu o luarocks? https://luarocks.org/

Sobre Lua na web. Existem algumas iniciativas como o Lapis (https://leafo.net/lapis/)

Sobre o porquê de Lua não ser tão usada na Web acredito ser por alguns motivos:

1 - Lua tem menos popularidade que Nodejs ou Python (ou até mesmo Ruby).

2 - Outras linguagens têm frameworks bem maduros (Django, Flask, Express, Rails, Spring, etc). Posso estar sendo injusto com o Lapis (além disso Lapis é o único que conheço)

3 - Usar pacotes de terceiros em outras linguagens é bem mais simples que em Lua (pip e npm fazem um trabalho bem melhor que luarocks na minha opinião - se tiver algum mantenedor do luarocks aqui entenda como uma crítica construtiva, eu gostaria muito de ver o luarocks como um ótimo gerenciador de pacotes)

4 - Acho que lua devia ter uma stdlib mais extensa incluindo módulos de filesystem e comunicação http (client e server) oficiais, por exemplo.

Entendo que a equipe core do Lua decidiu manter o pacote da linguagem bem minimalista com uma stdlib que possibilite apenas lidar com as estruturas core da linguagem e delegando tudo o mais para a comunidade.

Então as libs primitivas para lidarem com tables, strings e io por exemplo são mantidas junto com a linguagem (sem isso a linguagem não seria usável), mas funcionalidades para requisições http, banco de dados, sistema de arquivos, etc. vão depender de ou vc mesmo implementar ou ter um pacote fornecido pela comunidade. 

Esses módulos escritos por terceiros existem, mas a manutenção deles nem sempre está em dia. Ex: a anos atrás eu não conseguia instalar/usar luafilesystem no windows com luarocks.

Isso acaba fazendo com que quem tem um problema concreto para resolver acabe migrando para um ecossistema mais maduro como o de Python em que ou vc tem tudo que precisa na stdlib ou um simples "pip install" resolve teu problema.

Lembrando que não estou criticando a decisão de como o pessoal do Lua decidiu manter a linguagem, só estou relatando um fato. Temos que lembrar que manter qualquer projeto de software exige tempo das pessoas, conhecimento e dinheiro. E o pessoal do LabLua tem que balancear essas coisas, gerenciando os recursos disponíveis.

Com isso acaba que Lua fica mais orientada ao que a própria documentação menciona como sendo o motivador de sua criação: uma linguagem de configuração e de extensão de outras aplicações, o que cola muito bem com engines de jogos, por exemplo, pois é relativamente simples embarcar Lua em um sistema para trabalhar com outra linguagem que chama hooks em Lua.

---
Eric Chiesse

--
Lua BR - https://groups.google.com/g/lua-br
---
Você recebeu essa mensagem porque está inscrito no grupo "Lua BR" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para lua-br+un...@googlegroups.com.
Para acessar essa discussão na Web, acesse https://groups.google.com/d/msgid/lua-br/CAPoEMujqieWxzKOZ%3Dv%3DDyXx_V%2BXeT39xXpaSRJbEavcxkOK1_A%40mail.gmail.com.

[Tomás Guisasola]

Oi gente

> Sobre gerenciador de pacotes, já viu o luarocks? https://luarocks.org/
>
> Sobre Lua na web. Existem algumas iniciativas como o Lapis (https://leafo.net/lapis/)

Eu uso CGILua desde que foi criado, na época em que as pessoas faziam
sites em Perl, então sou suspeito para falar dele, além de ter uma
grande quantidade de código legado. Tem o Sailor também, embora
esteja precisando de mantenedores:

https://github.com/sailorproject/sailor

>> O que acham de Lua na web?
>> Qual opinião de vocês sobre o por que Lua não é tão usada para esse fim?

Eu desenvolvo com Lua para Web há muitos anos e acho que é uma
ferramenta excepcionalmente eficiente, mas se você estiver disposto a
entender todos os níveis de software envolvidos. Eu investi um bocado
de tempo para tentar padronizar a instalação do CGILua, só que os
servidores Web são muito diferentes e suas configurações também, então
era inviável para mim, que trabalho com apenas uma combinação
(Linux+Apache+PostgreSQL), entender de todas as possíveis para fazer
algo prático. Eu estava sozinho naquela época...

Mas acho que a comunidade poderia contribuir nesse sentido, só que não
ocorreu. Acho que a gente tinha necessidades muito à frente do nosso
tempo e faltava dinheiro para financiar ou gente o bastante para
colaborar coletivamente.

E tem outro componente que é cultural: o brasileiro valoriza mais o
que vem de fora do que o que é produzido aqui.

Bom, se alguém que estiver lendo essa conversa estiver interessado em
contribuir com essas ferramentas, pode contar comigo para ajudar.

Abraços,
Tomás

[Jorge Rezende]

Qualquer um que ja tentou usar o luarocks e o lapis ja deve ter passado raiva, lapis funciona, mas não é bom kkk e o luarocks a mesma coisa.

Infelizmenta a comunidade de lua é muito maior em criação de mods pra jogos e essas ferramentas embeded. 

[Tomás Guisasola]

Oi Jorge

> Qualquer um que ja tentou usar o luarocks e o lapis ja deve ter passado raiva, lapis funciona, mas não é bom kkk e o luarocks a mesma coisa.

Qual é o problema com LuaRocks? Eu tenho uma ótima experiência com a
ferramenta!

Abraços,
Tomás

[Yago Crispim]

Interessante os seus pontos, Eric Chiesse e Tomas Guisasola.

Senti isso mesmo quando estava desenvolvendo algumas aplicações com a linguagem.

As necessidades vão surgindo e tem momentos onde se quer construir uma ferramenta, tem que estar disposto a fazer quase tudo do zero.

Tenho trabalhado em pequenos projetos pra suprir algumas necessidades da forma mais minimalista possível, mas de fato, cobrir todas as etapas necessárias para criar uma lib é muito pra uma pessoa só.

Cansa mesmo.

E agora pensando, levando em consideração o que o Eric falou sobre a finalidade da lang, parece que querer que Lua seja uma lang "competidora" do JS/Python é algo que nem os criadores da linguagem querem e algo que se desencontra dos propósitos da ferramenta.

[hrcerq]

> Sobre gerenciador de pacotes, já viu o luarocks? https://luarocks.org/
>
> Sobre Lua na web. Existem algumas iniciativas como o Lapis (
> https://leafo.net/lapis/)

Olá. Essa é uma boa discussão. A propósito, tenho uma opinião
relativamente impopular sobre o tema, mas acredito que do contraditório
é que surgem discussões saudáveis, então aqui vão meus dois centavos.

Gerenciadores de pacotes para ambientes de programação podem realmente
ser convenientes. Mas essa conveniência não raro possui um preço a
pagar, e precisamos ter bastante clareza de que preço é esse.

A seguir, aponto dois artigos [1][2] (em inglês) que considero
interessantes para compreender essa questão.

[1] https://drewdevault.com/2022/05/12/Supply-chain-when-will-we-learn.html
[2] https://unixdigest.com/articles/no-you-cannot-trust-third-party-code-without-reading-it-first.html

Os dois artigos são bastante incisivos sobre o problema dos ataques de
_supply chain_ comuns nesse tipo de ambiente. E também sobre
estratégias para se prevenir contra isso. O primeiro artigo inclusive
aponta para uma lista (bem grande) [3] de casos já conhecidos de
ataques desse tipo, para não deixar dúvida de que isso é uma realidade.

[3] https://github.com/advisories?query=type%3Areviewed+malicious+package+severity%3Acritical

E que estratégias seriam essas? Uma delas, é ler o código que você vai
incluir no seu projeto. Se não é factível fazer isso, então pode ser um
indício de que o projeto possui dependências demais. Outra é possuir um
mecanismo de validação e auditoria por terceiros, de modo que haja uma
clara separação entre o programador e o empacotador.

O primeiro artigo [1] inclusive menciona o fato de isso já ser feito
com êxito em diversos sistemas operacionais. Nesse caso, o empacotador
assina digitalmente o pacote, atestando que ele foi devidamente
validado e passou por um processo de inspeção.

Sem isso, o que pode ocorrer? Digamos que eu criasse um pacote Lua para
implementar um novo protocolo (a título de exemplo, o ActivityPub).
Digamos que o pacote de fato fizesse aquilo que se propõe. Mas dentro
dele eu adicionasse uma função que silenciosamente realiza uma
mineração involuntária de alguma criptomoeda qualquer.

Faria o upload para um repositório luarocks e involuntariamente várias
pessoas estariam desperdiçando ciclos de processamento, "em benefício"
(se de fato é benefício, é discutível), de um desconhecido.

Inúmeros outros tipos de ataque poderiam ser explorados usando desse
mesmo expediente. E por quê? Por que não há uma validação independente
para identificar os ataques, e porque muitos programadores confiam
cegamente no código que importam em seus projetos. Essa é, a meu ver,
uma grande falha no código aberto de modo geral: achar que por estar
aberto, alguém já viu e que portanto não deve haver nada de errado.

Ledo engano. Por mais que eu acredite na importância da transparência
do código, só isso não basta para impedir que ataques do tipo ocorram.
O processo de auditoria por terceiros qualificados é fundamental.

De fato, a realidade do nosso trabalho muitas vezes impõe que a gente
não siga a cartilha das boas práticas a rigor. Mas é uma tolice fingir
que não há um preço a pagar por isso. E tolice maior ainda é nem buscar
saber que preço será esse. Até porque não raro seremos nós mesmos que
vamos pagar.

> 4 - Acho que lua devia ter uma stdlib mais extensa incluindo módulos de
> filesystem e comunicação http (client e server) oficiais, por exemplo.

Sobre esse ponto, respeitosamente discordo. Não me parece que isso
deveria ser atribuído ao projeto Lua, se considerarmos os objetivos
desse ambiente de desenvolvimento. Lua possui uma filosofia parecida
com a de C nesse aspecto, que é manter uma biblioteca padrão pequena, e
problemas adicionais são resolvidos em outras bibliotecas, ou
implementando do zero, quando necessário/conveniente. E de fato,
bibliotecas voltadas para essas funções existem.

Por exemplo, para manipulação de sockets, temos a bem conhecida
LuaSocket [4], e também a não tão conhecida mas igualmente uma opção
válida e documentada, o cqueues [5].

[4] https://lunarmodules.github.io/luasocket/
[5] https://25thandclement.com/~william/projects/cqueues.html

A propósito, a menção ao Lapis me lembrou de uma fala de Edsger
Dijkstra [6][7] sobre linguagens, a qual possui alguma dose de crítica
e sarcasmo, e talvez por isso mesmo seja boa para refletir sobre esse
tema:

"É impossível apontar um lápis com um machado cego. Igualmente em vão é
tentar o mesmo com dez machados cegos." [8] (tradução livre)

[6] https://wiki.inf.ufpr.br/computacao/doku.php?id=e:edsger_dijkstra
[7] https://www.cs.utexas.edu/users/EWD/
[8] https://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD498.html

Em outras palavras, se você não compreender verdadeiramente os
problemas que quer resolver, não importa quantas ferramentas você
utilizar, o problema ainda estará lá.

--
Att,
@hrcerq

0/ ´ ° ` o ´ ° ` \0

[hrcerq]

Olá, Yago.

> Venho criando algumas aplicações web utilizando a linguagem e as
> ferramentas que encontrei são ou complicadas de configurar ou incompletas
> ou abandonadas.

Entendo que isso possa ser frustrante, mas acredito que então seria
mais produtivo discorrer sobre que ferramentas são essas e por que
motivo elas são complicadas. Aí talvez seria possível "descomplicar".

> O que acham de Lua na web?
> Qual opinião de vocês sobre o por que Lua não é tão usada para esse fim?

Eu não teria tanta certeza de que Lua não seja muito usada para esse
fim. Como chegou a essa conclusão? Porque eu na realidade tendo a
pensar o contrário. Vejamos por exemplo o OpenResty [1][2], ele integra
o servidor NGINX com o LuaJIT, para expor a funcionalidade do servidor
Web em uma API Lua.

[1] https://openresty.org/
[2] https://github.com/openresty/lua-nginx-module

Sendo Lua um ambiente pequeno, eu penso que mais interessante até do
que funcionar como um módulo adicional, ele ser embutido no próprio
servidor Web. E de fato é o que acontece no Lighttpd [3], por exemplo.
A biblioteca Lua roda embutida no Lighttpd e provê uma interface de
acesso às funções do servidor, permitindo que você crie seus scripts
tanto de configuração quanto de resposta às requisições HTTP.

[3] https://doc.lighttpd.net/lighttpd2/core_lua.html

Há algum tempo esbarrei também no projeto Luvit [4]. Não explorei muito
sobre ele, mas acredito que possa fazer sentido para quem já está
familiarizado com o Node.

[4] https://luvit.io/

Web não é exatamente meu campo de atuação, então imagino que se
procurar, ainda deve achar outras iniciativas igualmente interessantes.

[Jorge Rezende]

A experiencia de uso é pessima, funcina bem, desde que: 

- Você não queia isolar suas dependencias por projeto
- Você nçao precise usar ou configurar algo como open resty

- Você não tenha usado qualquer um gerenciador de pacotes moderno.

Em sábado, 6 de abril de 2024 às 17:49:30 UTC-3, Tomás Guisasola escreveu:

[Yago Crispim]

Olá, hrcerq

Obrigado pela resposta.

> Eu não teria tanta certeza de que Lua não seja muito usada para esse

> fim. Como chegou a essa conclusão? Porque eu na realidade tendo a
> pensar o contrário. Vejamos por exemplo o OpenResty [1][2], ele integra
> o servidor NGINX com o LuaJIT, para expor a funcionalidade do servidor
> Web em uma API Lua.

O que me faz achar que Lua não é usada na web é justamente tentar criar uma API e não encontrar algo que seja: "Baixe o pacote X, crie uma rota, crie o handler, execute o script e pronto".

E acredito que o reflexo disso são os resultados go Google/YouTube e etc quando eu busco "web api in lua". 

De fato, tem a opção do OpenResty, mas e se eu não quiser Nginx? É isso que sinto falta na linguagem.

Comparando com Node ou Python, por exemplo.

Necessidade do dev:

- Quero uma api com X endpoint que retorne X resposta.

Resolução em Python/Node:

- Baixe o pacote X, crie o endpoint e a função handler.

Resolução em Lua:

- Baixe o pacote X (torça para o LuaRocks funcionar e tudo rodar liso)

- Roda sudo apt <<qualquer lib faltando>>

- Configure o nginx

- Corrija todos os paths e env necessários

- Não esqueça de carregar o path do LuaRocks para encontrar os pacotes dentro do projeto

- Agora pode começar a ver como irá cirar o endpoint.

Não sei se só eu passei por isso ou se estou errando em algo, mas tudo isso me faz crer que Lua não é usada para esse fim por uma questão de falta de opção.

E acredito que mais pessoas pensam isso porquê eu lí isso do criador do Milua em uma postagem no dev.io uns tempos atrás:

"Using an existing framework in Lua, like Lapis.

The problem here was that Lapis relies on third-party software, like Nginx, so the dependencies list would keep growing. 

This wouldn't be a problem in a more heavy project, but the API I need here is really small, so I would consider  overkill anything more than a single technology for it."

-- 

Yago Crispim

[hrcerq]

> O que me faz achar que Lua não é usada na web é justamente tentar criar uma
> API e não encontrar algo que seja: "Baixe o pacote X, crie uma rota, crie o
> handler, execute o script e pronto".

Entendo seu ponto. Precisa de algo que envolva menos etapas de
construção, algo mais direto ao ponto, certo?

> E acredito que o reflexo disso são os resultados go Google/YouTube e etc
> quando eu busco "web api in lua".

Algumas pesquisas são mesmo uma tarefa ingrata. Ou temos que lidar com
a falta de informação sobre o que buscamos, ou com o excesso de ruídos.
Mas me parece que sua pesquisa não foi totalmente em vão.

Por exemplo, você mencionou o Milua [1]. Ele não te atendeu? Mais
alguns que pode conferir são o Pegasus [2] e o GIN [3] (ainda recente,
mas pode te interessar).

[1] https://github.com/MiguelMJ/Milua
[2] https://github.com/EvandroLG/pegasus.lua
[3] http://gin.io/

> De fato, tem a opção do OpenResty, mas e se eu não quiser Nginx? É isso que
> sinto falta na linguagem.

Colocando nessa perspectiva, realmente a Web não é o cenário mais
proeminente em Lua, então existem algumas limitações. Não há
muito como fugir disso, a não ser realmente se quiser investir seu
tempo em construir algo mais a seu gosto para facilitar trabalhos
futuros em Lua.

> Comparando com Node ou Python, por exemplo.

Eu destacaria aqui um cuidado que é o de não tentar comparar maçãs e
laranjas, porque tende a não fazer sentido mesmo. As culturas
prevalentes em torno desses ambientes de desenvolvimento é bem
diferente. Como você mesmo disse em outra ocasião, Lua não é Python e
nem Node.

Em Lua prevalece a cultura da metaprogramação, da integração e do "faça
você mesmo", bem diferente do que se espera em Node e Python, onde
existe uma ideia de programação expressa (quick-and-dirty) para sair o
mais rápido possível com alguma coisa funcionando.

Não quer dizer que você não possa adaptar sua solução a uma cultura
diferente, porém adaptar toda uma cultura à sua solução será bem mais
difícil, como nadar contra a correnteza e (no meu modo de ver) algo
despropositado, já que já existem outros ecossistemas mais alinhados ao
que busca.

E não seria razoável desejar que Lua deixasse de ser o que é, e
aderisse ao modo de ser de outros ambientes (até porque isso
provavelmente seria prejudicial aos cenários onde já se destaca, como
jogos, embarcados e mecanismos de extensão).

> - Baixe o pacote X (torça para o LuaRocks funcionar e tudo rodar liso)

Tenho a impressão de que o LuaRocks não é tão bem quisto por aqui. Pra
dizer a verdade, eu também não sou um grande fã dessa ferramenta, mas
por motivos diferentes, como expus em outro ponto dessa conversa.

No meu modo de ver, módulos Lua fornecidos como pacotes é algo que faria
mais sentido sendo distribuído pelo próprio sistema operacional (o que
até acontece em alguns casos). Do contrário, é preferível uma
inspeção e instalação manual, quando possível.

> Não sei se só eu passei por isso ou se estou errando em algo, mas tudo isso
> me faz crer que Lua não é usada para esse fim por uma questão de falta de
> opção.

Falta de opção eu não diria, mas de fato as opções são mais restritas.
Diante disso, o que você pode fazer é:

1. Tentar adaptar as soluções existentes ao que precisa;
2. Criar algo do zero;
3. Mudar de ambiente de desenvolvimento, quando se tratar de construção
de uma API para a Web.

Lamento não ter uma resposta melhor, mas diante da necessidade que
colocou é desse modo que vejo. Espero ter ajudado em algo.

[Luiz Henrique de Figueiredo]

Esse artigo me parece relevante para esta discussão:

Lua, a misunderstood language
por Andre Alves Garzia
https://andregarzia.com/2021/01/lua-a-misunderstood-language.html

[Yago Crispim]

Obrigado novamente pela resposta, hrcerq.

Acho que acabei misturando as coisas haha

Estava me referindo mais as ferramentas em volta da linguagem do que a própria linguagem.

Mas de qualquer forma, bons pontos.

Sobre sua mensagem, Luiz

> Esse artigo me parece relevante para esta discussão

Concordo. Acho que a linguagem tem tudo que precisa mesmo.

[Eric Chiesse]

A linguagem é muito boa. Além de ser super simples.

A questão mesmo é o ecossistema.

Eu entendi o artigo do André, mas quando ele fala que "They are not looking towards Lua in the context that Lua wants to exist" eu discordo.

Lua é uma linguagem, tem uma lib padrão com funcionalidades básicas e ferramentas para extensão. Não falta nada nela e nem dá pra dizer que ela não é boa pra fazer X ou Y a priori (sem uma análise).

O grande ponto é: As pessoas acabam conhecendo Lua por alguma aplicação que viram em algum lugar (um mod de jogo, um kit de automação residencial, etc), aprendem e básico, gostam e pensam: 

"Cara eu quero usar mais essa linguagem. Ela é tão simples e tão poderosa! Seria legal poder usar pra resolver meus outros problemas"

E aí o pessoal esbarra no ecossistema.

Se houvesse alguma entidade disposta a investir uma grana pra criar um framework web pra bater de frente com o Django (por exemplo), pra aprimorar o gerenciador de pacotes pra ser comparável ao cargo, npm, pip, etc  (por exemplo) dentre outros pontos a gente não estaria aqui debatendo esses pontos hoje. Só estamos porque a gente curte a linguagem e quer fazer essas coisas. Mas nem todo mundo quer ou tem tempo, ou conhecimento para criar um programa em C, manipular a pilha de Lua e criar uma nova funcionalidade pro pessoal usar.
Por exemplo, pra criar uma lib que faça requisições HTTP lidando de forma transparente com a camada de segurança (SSL) é preciso saber C, saber sockets, saber como integrar com Lua e saber como o handshake SSL/TLS e afins funciona. 

Eu entendo a frustração de quem só quer fazer: resp= request('get', 'https://meusite.com.br')

Quando falo de ecossistema, não entendam como reclamação. Como falei, é só um fato. 

As coisas são como são, e que bom que há pessoas que fazem alguma coisa pra nos ajudar. Eu sei o quanto alguns autores e mantenedores se dedicam a seus projetos (o luarocks por exemplo sempre teve alguém respondendo rapidamente os bug reports)

Enfim acho que esse desejo de usar Lua em mais lugares é entusiasmo pela linguagem. Acho positivo que essa pressão exista. Quer dizer que tem gente por aí que gosta e que ver as coisas o melhor possível.

---
Eric Chiesse

--

Lua BR - https://groups.google.com/g/lua-br
---
Você recebeu essa mensagem porque está inscrito no grupo "Lua BR" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para lua-br+un...@googlegroups.com.

Para acessar essa discussão na Web, acesse https://groups.google.com/d/msgid/lua-br/e708a152-4ac9-4c6b-9c3e-542d24cfcb23n%40googlegroups.com.

[Tomás Guisasola]

Oi Eric

> E aí o pessoal esbarra no ecossistema.

Eu entendo isso.

> Se houvesse alguma entidade disposta a investir uma grana pra criar um framework web pra bater de frente com o Django (por exemplo), pra aprimorar o gerenciador de pacotes pra ser comparável ao cargo, npm, pip, etc (por exemplo) dentre outros pontos a gente não estaria aqui debatendo esses pontos hoje. Só estamos porque a gente curte a linguagem e quer fazer essas coisas. Mas nem todo mundo quer ou tem tempo, ou conhecimento para criar um programa em C, manipular a pilha de Lua e criar uma nova funcionalidade pro pessoal usar.

Há muitos anos atrás houve uma iniciativa nesse sentido, o Projeto
Kepler, mas acabou não tendo manutenção e ficou para trás...

> Por exemplo, pra criar uma lib que faça requisições HTTP lidando de forma transparente com a camada de segurança (SSL) é preciso saber C, saber sockets, saber como integrar com Lua e saber como o handshake SSL/TLS e afins funciona.
> Eu entendo a frustração de quem só quer fazer: resp= request('get', 'https://meusite.com.br')

Mas isso daí já existe: basta pegar a LuaSocket e a LuaSec! Se
precisar de alguma ajudar, basta falar, mas é bem tranquilo de
instalar com LuaRocks e usar.

Abraços,
Tomás

[hrcerq]

Olá, Eric.

> O grande ponto é: As pessoas acabam conhecendo Lua por alguma aplicação que
> viram em algum lugar (um mod de jogo, um kit de automação residencial,
> etc), aprendem e básico, gostam e pensam:
> "Cara eu quero usar mais essa linguagem. Ela é tão simples e tão poderosa!
> Seria legal poder usar pra resolver meus outros problemas"

No geral, eu concordo com a sua visão de que é positivo que haja
pessoas interessadas em Lua e querendo adaptar esse ambiente para
cenários do seu dia a dia. Porém, em alguns pontos bem específicos acho
que existem modos mais produtivos de encarar a questão. A seguir
detalho mais.

> E aí o pessoal esbarra no ecossistema.

Este é o primeiro ponto. O que costumeiramente chamamos de ecossistema
é o que por acaso as pessoas que usam Lua criam e compartilham para
outras pessoas poderem também tirar proveito. Não existem por si só,
dependeu de alguém que queria usar aquilo criar em primeiro lugar.
Nesse sentido o ecossistema de Lua é bastante voltado para jogos,
embarcados, e eu diria que segurança também porque nessas comunidades
houve uma grande quantidade de pessoas dispostas a criar um ponto de
partida para facilitar seus trabalhos futuros (e de outras pessoas
também, por que não?).

Além disso, como detalha o artigo do André Garzia, grande parte do
potencial de Lua está justamente na capacidade de uma forte integração
com outras aplicações, então também existem muitas aplicações que usam
Lua internamente como motor de script, interface de depuração,
linguagem de configuração ou de criação de plugins. E isso também pode
ser considerado parte desse ecossistema.

Em relação a frameworks Web, houve menos desse fenômeno, e por isso
menos opções nesse quesito. Não quer dizer que isso seja algo imutável
ou impossível de acontecer, mas depende das pessoas interessadas nesse
segmento trabalharem juntas para fazer com que Lua também seja capaz de
florescer nesse campo.

Aliás, se pararmos pra pensar, frameworks são a antítese da máxima de
Lua em relação a mecanismos no lugar de regras (mechanisms over
policies), já que frameworks são justamente regras no lugar de
mecanismos. Ainda assim, não é incompatível com Lua, no fim das contas,
mas precisa ter alguém interessado em elaborar.

>
> Se houvesse alguma entidade disposta a investir uma grana pra criar um
> framework web pra bater de frente com o Django (por exemplo), pra aprimorar
> o gerenciador de pacotes pra ser comparável ao cargo, npm, pip, etc (por
> exemplo) dentre outros pontos a gente não estaria aqui debatendo esses
> pontos hoje. Só estamos porque a gente curte a linguagem e quer fazer essas

> coisas. [...]

Pra mim é aí que está o cerne do problema... esperar que haja um
terceiro para construir aquilo que você quer hoje. É algo que não se
tem controle. É como tropeçar e reclamar da ação da gravidade...
infelizmente isso não muda o fato de que se tropeçar, você cai.

Penso que não são poucos os que se queixam de Lua não dispor de algo
mais aos moldes desses outros ambientes. Talvez individualmente essas
pessoas não disponham de tempo e conhecimento para construir, mas se
toda essa comunidade que está inconformada com o estado de coisas atual
decidisse se mobilizar para construir um tal framework a esses moldes,
e um gerenciador que atendesse a essa demanda, também não estaríamos
discutindo essa questão.

Não é razoável esperar que isso caia do céu.

Meu ponto é, a crítica que mobiliza em torno de um objetivo é válida,
porque útil. Mas quando não mobiliza, então é um ruído sem resultado.
Se pensarmos no conceito de eficiência, uma máquina que esquenta e faz
barulho é menos eficiente porque gasta energia em algo que não faz
parte da função. Do mesmo modo, uma comunidade que se queixa de algo,
mas não usa dessa insatisfação para construir o que precisa, está
desperdiçando energia. Para mobilizar é preciso que a pessoa que faz a
crítica apresente algo, um projeto, um começo, um exemplo.

Quanto ao "bater de frente", pode ser apenas força de expressão, mas eu
sustentaria que não é preciso bater de frente com frameworks
existentes, apenas criar algo que seja útil e funcione.

> [...] Mas nem todo mundo quer ou tem tempo, ou conhecimento para criar um

> programa em C, manipular a pilha de Lua e criar uma nova funcionalidade pro
> pessoal usar.

Talvez para pessoas que nunca tiveram contato com C e com a biblioteca
Lua, essa fala poderia levar a crer que se trata do trabalho de uma
vida inteira. Mas sabemos que não é bem assim. É claro que quando você
já dispõe de algo pronto é mais confortável. Mas quando não,
infelizmente não resta opção senão aprender a fazer, em primeiro lugar,
para que então outras pessoas (incluindo seu eu futuro) possam ter esse
conforto.

Aprender C e a biblioteca Lua é uma tarefa bastante gratificante,
especialmente para alguém interessado em Lua. E não é preciso ser um
expert em C para fazer integrações básicas como bindings para
bibliotecas existentes. Mas para além disso, já existem hoje muitas
bibliotecas Lua implementadas para funções básicas como manipulação de
sockets e protocolos HTTP e TLS. Ou seja, nem mesmo isso seria
necessário fazer.

>
> Enfim acho que esse desejo de usar Lua em mais lugares é entusiasmo pela
> linguagem. Acho positivo que essa pressão exista. Quer dizer que tem gente
> por aí que gosta e que ver as coisas o melhor possível.
>

Aqui ficou uma dúvida. Quando diz, "pressão", quer dizer pressão sobre
o quê? Ou sobre quem? Porque se estamos de acordo que o escopo de Lua é
minimalista, então sobre quem recairia essa pressão? Se me perguntasse,
eu diria que não há hoje onde fazer essa pressão, e não é possível
pressionar o que não existe. Então eu trocaria pressão por algo como
"manifesto" ou "chamado" em torno do objetivo de tornar Lua um ambiente
mais facilitado para a Web.

Estou certo de que entre as pessoas interessadas por algo do tipo,
muitas estarão aptas a meter a mão no código (possivelmente você sendo
um, por que não?), mas mesmo as que não estiverem podem contribuir
testando, divulgando, ajudando a organizar o projeto, montar uma página
web, uma lista de e-mail ou outros canais pra comunicação,
repositórios, etc, pra fazer a coisa acontecer.

Finalizando, peço apenas que não entenda minha fala como uma tentativa
de censura, acho que o questionamento é bastante válido. O que faço é
apenas uma sugestão de uma forma mais produtiva de levar esse
questionamento a algo concreto.

[Denis Dos Santos Silva]

a beleza do opensource eh essa;

a capacidade de resolver problemas por conta propria;

lua atende ao proposito de ser leve, embarcavel e FORTEMENTE desacoplado de "frameworks" e coisas do tipo; o que eu acabo achando extremamente positivo.

eu nem tenho ideia do custo (pessoas, servidores, ...) de se manter milhares de repositorios, seguranca (linux/ubuntu/npm por exemplo surge uns criticos);

luarocks ja faz um belo trampo.

[Lourival Vieira Neto]

Precisamente. Entendo que muitos não tenham disponibilidade para
contribuírem diretamente no desenvolvimento, mas poderiam contribuir
de muitas outras formas se estiverem realmente interessados em
desenvolver o ecossistema. Por exemplo, foram feitas algumas críticas
ao LuaRocks nesta thread. Estas críticas se traduziram em reportes de
bugs ou sugestões de funcionalidades? Ou ao menos em dúvidas objetivas
sobre como resolver um problema específico?

Acho que muito da frustração relatada nesta thread advém da
expectativa de que Lua (incluindo o seu ecossistema) seja algo que não
é. Neste caso, penso que tenhamos duas opções: 1) resignar e seguir em
frente ou 2) trabalhar para transformar o ecossistema.

Meus dois satoshis ;-).

Abraços,

--
Lourival Vieira Neto

[Lourival Vieira Neto]

On Thu, Apr 11, 2024 at 11:11 AM Tomás Guisasola
<tomasgu...@gmail.com> wrote:
>
> Oi Eric
>
> > E aí o pessoal esbarra no ecossistema.
>
> Eu entendo isso.
>
> > Se houvesse alguma entidade disposta a investir uma grana pra criar um framework web pra bater de frente com o Django (por exemplo), pra aprimorar o gerenciador de pacotes pra ser comparável ao cargo, npm, pip, etc (por exemplo) dentre outros pontos a gente não estaria aqui debatendo esses pontos hoje. Só estamos porque a gente curte a linguagem e quer fazer essas coisas. Mas nem todo mundo quer ou tem tempo, ou conhecimento para criar um programa em C, manipular a pilha de Lua e criar uma nova funcionalidade pro pessoal usar.
>
> Há muitos anos atrás houve uma iniciativa nesse sentido, o Projeto
> Kepler, mas acabou não tendo manutenção e ficou para trás...

Acredito que o Lunar Modules [1] esteja carregando a tocha agora ;-).

[1] https://github.com/lunarmodules

[Tomás Guisasola]

Oi Lourival

> > Há muitos anos atrás houve uma iniciativa nesse sentido, o Projeto
> > Kepler, mas acabou não tendo manutenção e ficou para trás...
>
> Acredito que o Lunar Modules [1] esteja carregando a tocha agora ;-).
>
> [1] https://github.com/lunarmodules

Em parte, sim. O Kepler era um pouco mais ambicioso no início, pois
tinha a intenção de promover esse ambiente de desenvolvimento para Web
como um todo. O Lunar Modules está tentando dar conta de manter o que
já foi feito, o que é louvável. Estamos juntos nessa!

Abraços,
Tomás

[Denis Dos Santos Silva]

arquitetura x sistemas operacionais x compiladores = muitas excessoes.

[16,32,64-bit, 128-bit] x [win,linux,osx,freedos,embarcdos,...] x [gcc, clang, cl, watcom]

lua no modo super saiyajin requer uso da linguagem C/c++