John Carmack, Goose 언어에 "거의 모든 게 가능해졌다"

Goose에 더 익숙한 분께 궁금한 게 있습니다: 임의 개수의 동적 크기 값들을 어떻게 표현하나요? 스택 수가 고정되어 있다면, 주어진 시점에 크기가 변할 수 있는 값의 수는 고정된 것처럼 보입니다.

예를 들어, 값이 문자열인 해시 테이블에서 프로그램이 무작위로 문자열을 삽입하거나 삭제한다면 어떻게 표현할까요?

쉽게 표현할 수 있는 것 같지 않습니다. 제가 생각할 수 있는 유일한 방법은 모든 문자열을 담는 스택을 유지하고 주기적으로 압축하는 것입니다.

편집: 여러 크기의 문자열을 위한 별도 스택을 둘 수도 있겠네요. 8바이트 미만, 16바이트 미만, ... 각각 하나씩요. 하지만 그 시점에서는 사실상 직접 malloc을 구현하는 셈이죠.

편집: 참고로 저는 Goose가 정말 멋지다고 생각합니다! 예전에 Rust에서 메모리 관리를 빠르게 하려고 비슷한 것들을 직접 많이 만들어야 했거든요

"아무것도 공유하지 않는 스레드. 워커는 자체 메모리를 가진 별도 프로그램으로 컴파일되며, 플랫 값은 memcpy로 타입이 지정된 큐를 건너갑니다. 데이터 레이스, 락, 원자성, 메모리 순서는 이 언어에 존재하지 않습니다."

이건 Dart Isolates가 생각나네요 - https://dart.dev/language/isolates

ML 쪽 사람들이 이 길을 갔던 걸로 기억합니다. 그걸 regions라고 불렀던 것 같아요.

제가 읽은 문헌이 얼마 안 되지만, 메모리 사용량이 꽤 더 많은 프로그램들이 충분히 많아서 그들은 이 접근이 막다른 길이라고 결정했다고 기억합니다.

더 자세한 걸 아시는 분 있나요?

"정말 깔끔해 보이네요! 자동 분석과 여러 데이터 스택 및 크기 조정 가능한 필드의 사용은 '이런 식으로 많은 작업을 할 수 있다'에서 '거의 모든 게 가능하다'로 끌어올립니다.

상대 참조와 내장된 바이너리 구조 검증은 데이터 구조의 직접 메모리 매핑과 네트워크 데이터의 즉각적인 사용도 가능하게 합니다. 파일과 네트워크 데이터의 '파싱'은 종종 필요한 것보다 100배 느립니다." - John Carmack

정말 흥미롭네요! 저는 주로 가비지 컬렉션 언어로 작성하기 때문에(수작업으로 뭔가를 여전히 쓴다면 말이죠...) 메모리 관리 논쟁에서는 그저 구경꾼일 뿐이지만, 힙 관리는 과학이라기보다 예술에 가깝다는 생각이 자주 들었습니다. 메모리를 스택처럼 다루는 아이디어는 즉시 직관적으로 와닿았습니다. 스레드 구현에도 매료되었지만, 다른 동시성 접근법과 비교해 잠재적 이점/비용을 따져볼 만큼 지식이 충분하지는 않습니다.

언어 이름이 기러기들이 대형을 지어 날아가는 방식, 즉 뒤따르는 새들이 선두의 공기역학적 그림자 안에서 날아 에너지를 절약하고 필요에 따라 자리를 바꾸는 방식에서 영감을 받은 건지 궁금합니다. 그렇다면 메모리 관리 모델에 아주 좋은 은유네요.

문서화에도 감명받았습니다. AI가 생성한 문서는 다소 평범한 경향이 있다는 걸 우리는 알지만, 저자는 읽기 쉽게 만드는 데 분명히 시간을 투자했고, 설계 결정의 관련성과 근거가 호기심 많은 프로그래머가 왜 특정 방식으로 구현되었는지 이해하는 데 필요한 맥락을 제공합니다.

간단한 알고리즘 정리부터 작은 게임까지 다양한 상세 샘플도 정말 좋았습니다. 다시 말하지만 다른 언어와 비교해 평가할 경험은 없지만, 코드가 얼마나 읽기 쉽고 작업 흐름을 따라가기 쉬운지에 놀랐습니다. 클래스에 대해 생각할 필요가 없다는 건 항상 플러스죠!

어쨌든 저는 보통 새로운 언어의 제안을 냉담하게 [...]

Goose는 꽤 멋집니다. 핵심 아이디어는 모든 프로그램을 표현 가능하게 만들 필요는 없다는 것이죠. 제한된 목적을 위한 언어도 괜찮습니다. 성장 가능한 메모리 영역의 수를 정적으로 지정할 수만 있다면 Goose를 사용할 수 있습니다. 하지만 가비지 컬렉션이 없기 때문에 프로그램이 실행되는 동안 메모리 사용에 주의해야 할 것입니다. 즉, 오래된 데이터가 더 이상 사용되지 않더라도 스택을 계속 키우면 너무 커질 수 있습니다.

그래도 데이터 지향 애플리케이션 같은 많은 프로그램에는 아마 잘 맞을 것입니다. 엔티티-컴포넌트 게임 시스템에서도 오래된 메모리를 재사용한다면 괜찮게 작동할 수 있습니다…

이게 wasm 세상에서는 어떻게 작동할까요? 좀 잘못 던진 질문이네요. wasm이 어디서, 어떻게, 어떤 구현으로 쓰이는지 등 많은 맥락이 빠져 있으니까요. 하지만 제 단순한 이해로는 대부분의 wasm이 브라우저에서 실행되는 32비트입니다. 이게 작동하려면 진정한 가상 64비트(또는 48비트) 주소 공간이 필요합니다. 호스트인 브라우저나 다른 무언가가 제공할 수는 있겠지만....

호스트가 goose로 컴파일된 여러 .wasm을 로드해야 한다면, 그것들도 별도의 (브라우저) 인스턴스에서 실행해야 할 것입니다(아니면 wasm이 기본적으로 그렇게 작동하는지도 모르겠네요 - 확실하지 않습니다).

그냥 생각이 든 건데, 이 언어는 자바스크립트 워커로 변환할 준비가 되어 있습니다. 본질적으로 스레드 간 통신(또는 dart 언어 용어로 'isolates')을 갖춘 진정한 단일 스레드이기 때문에 브라우저에 완벽하죠. 이제 유일한 문제는 메모리 레이아웃입니다.