Hacker News 의견

• Livebook의 기능이 매우 멋있음. Elixir에서 C++ NIFs를 통해 CPython을 직접 호출하고 Elixir-native 데이터 구조를 반환하는 점이 깔끔함

  • 프로덕션 서버에서는 Pythonx 사용이 다소 위험할 수 있음. Elixir 앱과 동일한 OS 프로세스에서 실행되기 때문에 Elixir/BEAM 앱의 강력한 실패 복구 기능을 우회하게 됨
  • 일반적으로 Elixir 앱은 자체 BEAM 프로세스의 실패를 우아하게 처리할 수 있는 감독 트리를 가지고 있으며, 이는 Elixir, Erlang, Gleam 같은 언어의 큰 장점임
  • NIFs를 사용할 경우, Pythonx에서 처리되지 않은 예외가 발생하면 전체 OS 프로세스와 모든 BEAM 프로세스를 중단시킬 수 있음
  • Rustler는 Elixir에서 Rust를 위한 인기 있는 NIF 래퍼로, NIFs가 매우 유용한 경우도 있지만, 전체 앱을 중단시킬 수 있는 위험을 고려해야 함
  • Ports를 사용하여 Python이나 Rust 같은 다른 네이티브 코드를 실행하는 것이 이 점에서 덜 위험함

• Elixir 커뮤니티의 "잘 알려진" 사람들이 이러한 접근 방식을 지지하고 적극적으로 개발하는 것을 보는 것이 좋음

  • VM과 런타임이 다른 언어와 기술을 조율하는 데 매우 적합하여 표준 트랙과 오프로드 트랙이 있는 것처럼 느껴짐
  • 오프로드 "위험해 보이는" 아이디어와 안전한 실행의 차이는 종종 작업량에 불과하지만, 런타임은 이를 장려함
  • NIF이기 때문에 약간의 위험이 있지만, 별도의 BEAM 인스턴스를 생성하고 이를 통해 분산할 수 있음

• NIFs 사용의 안전성 문제를 지적한 다른 댓글들이 있음

  • Erlang VM 스케줄러는 NIF를 선점할 수 없으므로, 장시간 실행되는 Python 호출이 VM을 중단시킬 위험이 있음
  • GIL이 동시 Python 실행을 방지하지만, Erlang 호출자가 여러 Python 인터프리터를 실행할 수 있어 Ports에서는 문제가 되지 않음

• 매우 유익한 기사임. Pythonx가 단순한 서브프로세스 호출이 아니라 동일한 프로세스에서 실행된다는 점을 명확히 언급한 것이 좋음

  • Elixir에서 Python에 정의된 함수를 호출하는 예제가 추가되었으면 좋겠음

• Elixir가 AI 전쟁에서 JavaScript와 Python보다 더 적합함에도 불구하고 뒤처져 있는 것을 보게 되어 기쁨

  • Elixir의 ML 기반을 처음부터 확장하려는 초기 결정을 좋아하지만, 빠르게 발전하는 Python 라이브러리를 활용할 수 있는 방법이 생긴 것도 좋음

• Python에서 Elixir/Erlang 생태계로 진입하는 것이 너무 어렵게 느껴졌지만, Pythonx로 점진적인 학습이 훨씬 더 가능해 보임

  • Python의 GIL 문제에 대해 자유 스레딩을 실험했는지 궁금함

• Elixir에는 Python에 있었으면 하는 몇 가지 기능이 있음

  • 아톰, 대부분의 것이 매크로임, 파이프 |>, 진정한 불변성, 감독 트리 덕분에 진정한 병렬성과 동시성, 핫 코드 리로딩, 내결함성

• Elixir에 깊이 관여하고 Python을 많이 사용했던 사람으로서 매우 실용적이라고 생각함

  • C++ NIFs를 쉽게 만드는 Fine 라이브러리에 더 관심이 있음

• 이 프로젝트와 블로그 게시물이 나를 위해 만들어진 것처럼 느껴짐. 사용해보고 싶음, 고마움