Joe 괜찮아 보임. Janet은 직접 써보진 않았지만, Clojure를 따라가려 하기보다는 자기만의 방향을 가는 언어라고 생각했음
이 Wasm 브라우저 REPL도 써보면 좋음: https://gloathub.org/repl/
Gloat는 Glojure AOT 자동화 도구임
지난여름 James Hamlin과 함께 Glojure AOT를 가능하게 만들었고, 이후 계속 발전시키고 있음. marcingas(nooga)와도 Gloat/Glojure/let-go가 서로 잘 협력하도록 작업 중임
9social 데모가 마음에 듦. 직접 Plan 9 사용자는 아니지만 Plan 9식 방식에서는 늘 영감을 받음
GitHub 릴리스에 Plan 9용 amd64와 arm 32비트 바이너리를 배포하기 시작했음
amd64는 9front에서 테스트했고 전부 잘 동작하는 것 같음. CLI가 그다지 Plan 9답지는 않지만, 언젠가 포트를 더 네이티브하게 만들 의향은 있음
지금은 Clojure의 Go 방언이 몇 개 있으니, 가장 알고 싶은 건 어느 쪽이 Go 위에 완전히 호스트되고, JVM Clojure가 Java와 갖는 수준의 상호운용성을 제공하느냐임
Go에서 내가 만든 것을 쓸 수 있고, Clojure에서도 Go를 쓸 수 있으며, 혼합 프로젝트까지 만들 수 있으면 좋겠음. 또 상호운용성 말고도 무엇이 같지 않고 어떻게 다른지 세부적으로 정리돼 있으면 좋겠음
Gloat/Glojure는 Go 소스 AOT 파이프라인 덕분에 호스트된 런타임 측면에서 가장 좋은 이야기인 듯함. 컴파일 시점에 Go의 무엇이든 가져올 수 있음
반면 let-go는 구조체, 함수, 채널을 포함해 어떤 Go 값이든 왕복시킬 수 있지만, 임의의 Go 라이브러리를 래핑 없이 바로 끌어오지는 못함. 그런 라이브러리는 런타임에 빌드되어 있어야 함
사소한 지적이지만 README에 콜드 스타트 7ms라고 했다가 몇 줄 아래에는 6ms라고 되어 있음. README를 읽을수록 빨라지는 걸지도 모르겠음
고쳤음. 내 머신에서는 6~7ms이고, 중앙값은 대략 6.5ms 정도로 보임
늘 찾고 있던 종류의 Clojure 포트임
Go의 코어 라이브러리와 채널 추상화가 더 단순하고 좋은 기반 API라고 생각했고, core.async 계열 API와도 잘 맞을 것 같았기 때문임. 큰 단일 바이너리에 대한 욕구도 채워줌
작업 고맙고, C++26에 대한 새 애정이 좀 가라앉으면 꼭 다시 살펴볼 예정임
추가로 Glojure가 왜 내 레이더망에 없었는지 모르겠고, 이것도 보기엔 훌륭한 프로젝트 같음
Go 런타임과 패키지를 내부에서 활용하는 옛날 PHP 스타일 DSL을 만들어보는 아이디어를 생각해본 적이 있음
옛날 PHP라고 한 건 PHP가 원래 웹 중심 DSL에 가까웠기 때문이고, 지금은 그렇지 않음. Go의 힘을 뒤에 둔 PHP 비슷한 쓰기 쉬운 백엔드 언어가 흥미로울 것 같고, Clojure는 훌륭한 선택임
Hacker News 의견들
좋네요! 최근에 Go 의미론에 Lisp 문법을 얹어 보는 실험을 해봤음: https://codeberg.org/veqq/Joe
JVM 없는 Clojure 계열로는 Janet도 정말 좋고, 한동안 프로덕션에서 쓰고 있음: https://janet-lang.org/
Lua VM과 라이브러리를 원하면 Fennel도 있음
이 Wasm 브라우저 REPL도 써보면 좋음: https://gloathub.org/repl/
Gloat는 Glojure AOT 자동화 도구임
지난여름 James Hamlin과 함께 Glojure AOT를 가능하게 만들었고, 이후 계속 발전시키고 있음. marcingas(nooga)와도 Gloat/Glojure/let-go가 서로 잘 협력하도록 작업 중임
Plan 9에서 돌아간다는 게 놀라움
Go가 9front에서 1급 언어, 즉 기본 포함 언어가 되면 멋질 듯함
Plan 9용 소셜 네트워크를 만지고 있음: https://youtube.com/watch?v=q6qVnlCjcAI&si=MBCeM0QdA0WsKAe7
전부 rc와 awk로 되어 있는데, 중간중간 Go나 Clojure가 있었으면 좋았을 부분이 있음
amd64는 9front에서 테스트했고 전부 잘 동작하는 것 같음. CLI가 그다지 Plan 9답지는 않지만, 언젠가 포트를 더 네이티브하게 만들 의향은 있음
지금은 Clojure의 Go 방언이 몇 개 있으니, 가장 알고 싶은 건 어느 쪽이 Go 위에 완전히 호스트되고, JVM Clojure가 Java와 갖는 수준의 상호운용성을 제공하느냐임
Go에서 내가 만든 것을 쓸 수 있고, Clojure에서도 Go를 쓸 수 있으며, 혼합 프로젝트까지 만들 수 있으면 좋겠음. 또 상호운용성 말고도 무엇이 같지 않고 어떻게 다른지 세부적으로 정리돼 있으면 좋겠음
반면 let-go는 구조체, 함수, 채널을 포함해 어떤 Go 값이든 왕복시킬 수 있지만, 임의의 Go 라이브러리를 래핑 없이 바로 끌어오지는 못함. 그런 라이브러리는 런타임에 빌드되어 있어야 함
사소한 지적이지만 README에 콜드 스타트 7ms라고 했다가 몇 줄 아래에는 6ms라고 되어 있음. README를 읽을수록 빨라지는 걸지도 모르겠음
늘 찾고 있던 종류의 Clojure 포트임
Go의 코어 라이브러리와 채널 추상화가 더 단순하고 좋은 기반 API라고 생각했고, core.async 계열 API와도 잘 맞을 것 같았기 때문임. 큰 단일 바이너리에 대한 욕구도 채워줌
작업 고맙고, C++26에 대한 새 애정이 좀 가라앉으면 꼭 다시 살펴볼 예정임
추가로 Glojure가 왜 내 레이더망에 없었는지 모르겠고, 이것도 보기엔 훌륭한 프로젝트 같음
옛날 PHP라고 한 건 PHP가 원래 웹 중심 DSL에 가까웠기 때문이고, 지금은 그렇지 않음. Go의 힘을 뒤에 둔 PHP 비슷한 쓰기 쉬운 백엔드 언어가 흥미로울 것 같고, Clojure는 훌륭한 선택임
대안으로 Joker도 있음: https://joker-lang.org
정말 훌륭한데 완전히 과소평가되어 있다고 봄
다만 let-go에는 너무 많은 걸 추가하지 않으려 함. 10MB 안에 들어간다는 점이 마음에 듦
언어 이름이 그냥 “lets-go”보다 더 나았으면 좋겠음. “clogo”는 어떨까?
(let [...] (go ...))Go에서 let을 하게 해줌!
Clogo는 나에게는 no-go임. 다른 아이디어가 있으면 좋은 건 검토해보겠음
https://github.com/chr15m/awesome-clojure-likes에 PR을 보내주면 아주 환영함