Erlang과 BEAM의 놀라운 점은 그 기능의 깊이임. OP에게는 Erlang의 Behavior/Interface가 가장 큰 수확이었음. 개인적으로는 복잡한 시스템을 구축하는 데 필요한 개발 자원이 다른 언어보다 훨씬 적다는 점이 중요하다고 생각함. 많은 사람들에게는 경량 프로세스와 프로그래밍 모델이 매력적임
OTP는 매우 많은 기능을 포함하고 있음. 우리는 Elixir를 iOS 장치에서 실행할 수 있도록 컴파일하는 작업을 진행 중임. Erlang의 ei 라이브러리를 사용하여 C에서 노드를 컴파일하고, 다른 Erlang 노드와 인터페이스할 수 있음. Erlang의 rpc 라이브러리를 통해 C에서 함수 호출과 Elixir 애플리케이션과의 인터페이스가 가능함
Erlang은 현대 기술 스택이 고군분투하는 많은 문제를 해결해왔으며, 확장성과 구현 비용 문제를 수십 년 전에 해결했음. 그러나 HN에서는 Erlang/Elixir에 대한 관심이 실제 채택으로 이어지지 않았고, 많은 회사들이 Erlang 스택에서 무료로 제공되는 것을 구현하려고 돈을 낭비하고 있음
몇몇 관리자와 함께 경험을 바탕으로 책을 쓰려는 사람들과 일했음. 우리는 성공의 요인에 대해 항상 의견이 달랐음. 어떤 사람들은 경량 프로세스와 메시지 전달이 비밀 소스가 아니라고 주장하지만, Erlang의 Communicating Sequential Processes는 이러한 특성과 분리할 수 없음을 놓치고 있음
예시: 애플리케이션 프로그래머는 순차 코드를 작성하고, 모든 동시성은 행동에 숨겨져 있음
새로운 팀원이 시작하기 쉬움: 비즈니스 로직은 순차적이며, 이전에 본 적이 있을 수 있는 유사한 구조임
감독자와 "충돌 시 방치" 철학은 신뢰할 수 있는 시스템을 만드는 데 기여함
경량 프로세스와 메시지 전달 때문에 Erlang에 다시 관심을 갖게 되었음. 현재까지는 행동이 부차적이었음
프로젝트는 시각적 Flow Based Programming(FBP)을 Erlang에 도입하는 것임. FBP는 Erlang에 적합해 보이며, 이미 존재하는 것이 놀라웠음
Node-RED를 FBP의 도구로 사용하고 있으며, 기본 아이디어는 Node-RED 프론트엔드를 Erlang 백엔드에 연결하고 모든 노드를 프로세스로 만드는 것임
Ericsson이 왜 Erlang 사용을 중단했는지, Joe의 해고에 대한 정보를 찾고 있었음
간단한 답변은 새로운 프로젝트에 Java로 전환하면서 Erlang이 소외되었기 때문임. Joe와 동료들은 1998년에 Bluetail을 설립했고, Nortel에 인수되었음. Nortel은 통신 거대 기업으로, 2000년 주가가 $125에 도달했지만, 2002년에는 $1 이하로 떨어졌음. 이는 닷컴 버블 붕괴와 통신 지출 감소와 관련이 있음
Erlang/Elixir의 힘은 Actor 모델 구현, Prolog의 매칭, 불변성, 행동 등이 아니라, Joe가 적은 자원으로 더 많은 것을 할 수 있음을 보여주려는 열망임
잘 설계된 일관성 있는 시스템이며, 다른 언어에서는 드물게 목격되는 일관성을 가짐. 완벽하지는 않지만 인상적임
소프트웨어 세계에서 단순함이 주는 힘에 대한 인식과 수용이 부족하다고 생각함
Erlang, OTP, BEAM은 행동 이상의 것을 제공함. VM은 가상 커널과 유사하며, 감독자, 격리된 프로세스, 분산 모드를 제공함. OTP는 Mnesia(데이터베이스), 원자적 카운터/ETS 테이블(캐싱) 등 유용한 모드를 제공함
1년 전, 개인 컨설팅 회사에서 Erlang을 백엔드 언어로 채택했음. BEAM의 내부를 탐색하여 TCP 기반 스택을 QUIC으로 교체하고 Rust 패치를 통합함
Erlang/BEAM에서 가장 흥미로운 개념은 부분 복구가 기본적으로 내장되어 있다는 것임. 예기치 않은 상태가 발생하면 전체 프로세스를 종료하거나 손상을 초래할 위험을 감수하는 대신, 가능한 가장 세분화된 수준에서 알려진 좋은 상태로 롤백함
Erlang의 행동 구조를 다른 언어와 라이브러리 설계자가 도용하지 않는 이유는 Erlang의 행동 함수 서명이 Erlang의 다른 기능, 특히 불변성의 독특한 사용과 밀접하게 연결되어 있기 때문임
다른 언어에서 동일한 목표를 달성하려면 Erlang의 방식을 직접 복사해서는 안 됨. Erlang의 신뢰할 수 있는 소프트웨어에 대해 배우는 것은 추천하지만, 다른 언어에 Erlang의 방식을 그대로 포팅하는 것은 강력히 반대함
이 글의 내용에 동의하지 않음. 행동은 시스템의 기본 아키텍처 덕분에 가능함. 행동은 인터페이스가 아니라 Java와 같은 언어의 추상 객체와 유사함
Joe의 논문은 주어진 레고 블록 세트를 사용하여 신뢰할 수 있는 시스템을 구축하는 방법을 보여줌
행동은 그다지 흥미롭지 않음. 다른 프로그래밍 언어에도 존재함. BEAM의 흥미로운 점은 오류를 던지는 것이 매우 우아하다는 것임. 오류를 던지는 것과 행동의 힘은 오류를 포착하고 컨텍스트 정보 보고를 쉽게 하고 일반적으로 구성 가능하게 만듦
Hacker News 의견
Erlang과 BEAM의 놀라운 점은 그 기능의 깊이임. OP에게는 Erlang의 Behavior/Interface가 가장 큰 수확이었음. 개인적으로는 복잡한 시스템을 구축하는 데 필요한 개발 자원이 다른 언어보다 훨씬 적다는 점이 중요하다고 생각함. 많은 사람들에게는 경량 프로세스와 프로그래밍 모델이 매력적임
몇몇 관리자와 함께 경험을 바탕으로 책을 쓰려는 사람들과 일했음. 우리는 성공의 요인에 대해 항상 의견이 달랐음. 어떤 사람들은 경량 프로세스와 메시지 전달이 비밀 소스가 아니라고 주장하지만, Erlang의 Communicating Sequential Processes는 이러한 특성과 분리할 수 없음을 놓치고 있음
경량 프로세스와 메시지 전달 때문에 Erlang에 다시 관심을 갖게 되었음. 현재까지는 행동이 부차적이었음
Ericsson이 왜 Erlang 사용을 중단했는지, Joe의 해고에 대한 정보를 찾고 있었음
Erlang/Elixir의 힘은 Actor 모델 구현, Prolog의 매칭, 불변성, 행동 등이 아니라, Joe가 적은 자원으로 더 많은 것을 할 수 있음을 보여주려는 열망임
Erlang, OTP, BEAM은 행동 이상의 것을 제공함. VM은 가상 커널과 유사하며, 감독자, 격리된 프로세스, 분산 모드를 제공함. OTP는 Mnesia(데이터베이스), 원자적 카운터/ETS 테이블(캐싱) 등 유용한 모드를 제공함
Erlang/BEAM에서 가장 흥미로운 개념은 부분 복구가 기본적으로 내장되어 있다는 것임. 예기치 않은 상태가 발생하면 전체 프로세스를 종료하거나 손상을 초래할 위험을 감수하는 대신, 가능한 가장 세분화된 수준에서 알려진 좋은 상태로 롤백함
Erlang의 행동 구조를 다른 언어와 라이브러리 설계자가 도용하지 않는 이유는 Erlang의 행동 함수 서명이 Erlang의 다른 기능, 특히 불변성의 독특한 사용과 밀접하게 연결되어 있기 때문임
이 글의 내용에 동의하지 않음. 행동은 시스템의 기본 아키텍처 덕분에 가능함. 행동은 인터페이스가 아니라 Java와 같은 언어의 추상 객체와 유사함
행동은 그다지 흥미롭지 않음. 다른 프로그래밍 언어에도 존재함. BEAM의 흥미로운 점은 오류를 던지는 것이 매우 우아하다는 것임. 오류를 던지는 것과 행동의 힘은 오류를 포착하고 컨텍스트 정보 보고를 쉽게 하고 일반적으로 구성 가능하게 만듦