스크립트 언어의 실행 환경은 약점임. 개인적으로 Neovim을 사용하지 않지만, Lua의 발전을 촉진할 것이라는 느낌이 있었음. Bryan Cantrill은 Javascript를 "C의 옷을 입은 LISP"이라고 불렀음. Lua는 그 반대라고 느끼며, 그런 이유로 Lua를 좋아함 (참고: 업무에서 사용한 적은 없음)
Koreader 같은 프로젝트는 Lua를 주요 애플리케이션 언어로 사용함. 그들이 전환하도록 설득할 수 있다면, 아이디어의 성숙도와 인기에 대한 확신을 줄 수 있을 것임
흥미로운 프로젝트임. Pixi에서 Lua 지원을 개선하기 위해 함께 일하고 싶음 (conda-forge 생태계를 통해). 이미 Lua와 몇 가지 C 확장을 패키징하고 있음. C 확장은 Pixi의 핵심이므로 잘 맞을 것 같음
놀라운 소리임. Lua를 많이 사용하지만, luarocks는 너무 의견이 강해서 거의 쓸모가 없음. "로컬 시스템에서 직접 실행하기 위한 라이브러리 설치" 이상의 것이나 그 주변의 것은 시작도 못함. Lua 패키지와 함께 작동하는 내장 스크립팅 환경이 있고, 거기서 사용할 스크립트를 의존성과 함께 패키징하고 싶음? 포기해야 함
이 사용 사례에 더 나은지는 모르겠지만, 그렇지 않더라도 luarocks는 사용하기에 불편하고 짜증남
개인적으로 모든 언어별 패키지 관리자에 지침. 올바른 방향이 아니라고 느낌. nix 같은 것이 훨씬 나은 접근법이라고 생각함
Rust에 의존하는 Lua의 패키지 관리자
좋음! Lua는 패키지를 더 쉽게 만들기 위해 이런 것이 필요했음
좋음. 여러 기기에서 Lua 패키지를 설치할 수 있는 재현 가능한 방법을 원하고 있었음
TOML 대신 Lua를 설정에 사용하지 않는 이유는? 기억에 따르면 Lua는 원래 데이터 스키마 언어였으므로 적합할 것임
Neovim 생태계를 일급으로 대우해줘서 고마움. 플러그인 개발 중에 Rust와 Typescript 같은 제3자 라이브러리의 사용 용이성을 놓쳤음
Hacker News 의견