Hacker News 의견

• 시스템 인터페이스 부족이 더 넓은 채택을 막고 있는 주요 요인임. 파일 접근, 네트워킹 등이 시간이 지나면 통합될 것임
  • 그러나 파일 접근, 네트워킹 등을 추가하면 보안 취약점이 생길 수 있음. 이는 Java의 '한 번 작성, 어디서나 실행' 약속을 무너뜨린 요인임
  • WASM은 컨테이너와 다른 문제를 해결함. WASM은 샌드박스 코드 실행에 효율적임
  • WASM은 Functions-as-a-Service 구현 등에서 표준이 될 가능성이 높음
  • 컨테이너는 그 문제를 해결하지 못함. 보안 경계로서 적합하지 않으며, WASM 바이너리보다 무겁고 시작 비용이 큼
  • 컨테이너는 여러 프로세스, 스레드를 실행하고 OS 기본 기능을 사용하는 데 적합함
• WebAssembly는 진정한 '한 번 작성, 어디서나 실행' 경험을 제공함
  • 그러나 외부와 상호작용하면 이야기가 달라짐. 각 V8 런타임은 미묘하게 다른 인터페이스를 가짐
  • Docker의 성공은 POSIX가 이미 확립된 표준이었기 때문임
• PlatformOps(이전의 DevOps, SRE, Ops)는 복잡한 도구와 프로그램-컨테이너-리눅스의 긴밀한 결합으로 인해 약속이 훼손됨
  • 개발자는 코드 작성과 기능 배포를 원함
  • PlatformOps는 문제를 해결하기 위해 고군분투함
• WASM은 컨테이너를 대체하는 솔루션이 아님. 컨테이너는 PHP의 다른 버전을 충돌 없이 실행하는 문제를 해결함
  • WASM은 그 문제를 해결하지 못함
• WASM의 미래는 언제 올 것인가? 8년이 지났지만 안정적이고 사용하기 쉬운 도구 체인이 없음
  • Rust는 2012년에 출시되어 8년 후 안정적이었음
• WASM은 실제 하드웨어에서 실행되지 않음. 가상 머신으로 간주될 수 있음
  • 컨테이너는 실제 하드웨어에서 직접 실행되는 애플리케이션을 패키징함
  • WASM은 런타임이 필요함. 애플리케이션 내에서 실행됨
  • WASM은 JVM과 .NET이 해결하는 '이식성' 문제를 해결함
  • 컨테이너는 애플리케이션과 종속성을 번들로 묶음
  • 기술은 상호 보완적일 수 있음
• Docker 사용법을 배우는 것은 방해 요소가 아님
  • Dockerfile만 있으면 됨
  • WASM 앱은 여전히 Kubernetes가 필요함
  • WebAssembly는 앞으로 5년간 크게 성장하지 않을 것임
• WASM은 또 다른 추상화 계층임. 모든 것을 대체할지는 다른 솔루션과의 절충에 달려 있음