Rune, Go로 만든 네이티브 IDE를 GPLv3로 공개하고 기여자 수익 배분 제도 예고
- Rune의 전체 소스를 GPLv3로 GitHub에 공개했으며, Unstable Build는 참여 기여자에게 회사 수익 일부를 나누는 계약형 프로그램을 만들겠다고 밝힘
- Rune의 Go 기반 터미널은 초기에는 Alacritty, Ghostty, Kitty보다 PTY 처리량이 거의 두 자릿수 느렸으나 알고리즘, goroutine 스케줄링, 이벤트 기반 렌더링으로 격차를 줄였다고 설명함
- 성능 비교는 Apple M4 Max 128GB macOS와 2016년 Intel Core m3-6Y30 Linux에서 vtebench로 실행했으며, 회사는 이를 Go와 Rust 또는 Zig의 언어 성능 비교로 해석하면 안 된다고 명시함
- Rune은 캐릭터 그리드 기반의 네이티브 그래픽 앱이며, Vim·Emacs·Standard 모드가 파일 편집뿐 아니라 UI 전반의 키 바인딩을 정함
- 토론에서 작성자는 Rune Network가 tsnet과 headscale을 쓰며 SSH와 Tailscale도 사용할 수 있고, 로그인하지 않으면 네트워크에 연결되지 않는다고 답함
Hacker News opinions
작성자임. Rune을 Go로 만든 IDE로 선택한 이유와 성능 개선 과정을 썼고, 기여자에게 권리를 넘기라는 CLA 대신 Unstable Build 수익 일부를 나누는 프로그램도 만들고 있음.
지난번에 봤을 때 비공개였던 점이 가장 아쉬웠는데 해결돼서 좋음. MIT 같은 라이선스가 아니라 GPLv3인 점도 마음에 듦.
Zed가 싫어서라기보다 IDE를 계속 써보고 싶어서 Rune도 해볼 생각임. UI를 오래 보니 새 차를 타보는 느낌이라는 말은 이해됨.
Fedora 패키지가 나오면 바로 써볼 생각임. 개인적으로 새 에디터를 고르는 기준이 그거임.
여러 머신을 쉽게 오가는 발상은 좋은데, Rune의 조정 서버와 암호화 방식을 신뢰해야 하는 건 꺼림칙함. Tailscale 위에서 선택적으로 돌릴 수 있으면 좋겠음.
SSH도 가능하고 Tailscale에서도 동작함. Rune에는 tsnet을 넣었고 headscale을 조정 서버로 쓰므로 Rune 네트워크에 특별한 부분은 없음.
기여자 수익 배분과 공개 원장이 IDE 자체보다 더 흥미로울 수도 있다고 봄. 기존 IDE는 계속 쓰겠지만 Rune도 써볼 만함.
법적 세부 사항은 아직 작업 중이고, 몇 주 안에 확정안을 내려고 함.
홈페이지에 실제 사용 영상을 넣고 라이트 테마 모습도 보여주면 좋겠음. 키보드 중심이라는 게 모달 편집기인지 일반 편집기처럼 쓸 수 있는지도 궁금함.
영상은 아직 못 찍었고 라이트 테마는 다크 테마만큼 손보지 못했음. Vim, Emacs, Standard 세 모드가 있고 파일 편집뿐 아니라 전체 UI의 키 바인딩을 정함.
vtebench 자체가 흥미롭고 Rune도 괜찮아 보임. 나도 에디터와 GUI 툴킷을 만들었는데, 터미널 성능은 언어보다 메모리 접근과 저장 방식 튜닝이 더 큰 문제였음.
기여자에게 수익을 직접 나누는 건 나쁜 생각 같음. Hacktoberfest나 GitHub의 AI PR 스팸처럼 금전 보상이 필요한 기능보다 보상만 노린 기여를 부를 수 있음.
요즘은 터미널의 Claude가 내 IDE가 되어가고 있음. Emacs는 조금 고치거나 파일 볼 때만 쓰고, IDE의 미래가 밝다고 보진 않음.
나는 코드 작성보다 HTML 시안과 문서를 보고 문맥 안에서 피드백하는 일, 프로젝트와 에이전트 할 일을 보는 일이 더 필요함. 그래서 통합 터미널 중심 앱을 직접 만들었고 VS Code와 Vim은 점점 맞지 않는 도구처럼 느껴짐.
그래서 Rune을 자동 프로그래밍과 수동 작업 사이의 다리로 만들고 있음. 채팅 UI에서 심볼과 파일을 찾아 참조하고, 에이전트는 grep 대신 Rune의 심볼 인덱스와 도구를 쓰며 패치 직후 컴파일 오류도 받음.
Rune Network를 꼭 써야 하는지, 오프라인 실행도 되는지 궁금함.
Rune 계정으로 로그인하지 않으면 연결되지 않고 네트워크는 끌 수 있음. 로그인한 상태에서도 설정으로 자동 참여를 끌 수 있음.
Go 기반 에디터라 반갑지만 나는 Cloudflare Workers용 TypeScript를 주로 씀. TypeScript 지원을 우선순위에 둬야 한다고 봄.
TypeScript와 JavaScript 경험을 설계할 사람을 찾고 있음. TypeScript 언어 서버는 참고 구현체라 LSP는 쉬울 듯하지만, 일상 작업에 무엇이 더 필요한지는 아직 확신이 없음.
예전 Rune에서 Vim 모드로 시작했다가 모든 동작에 Vim 모션을 써야 해서 바로 지웠음. 온보딩 교육을 마치지 않으면 아무것도 못 하는 느낌이었으니, 지금도 그렇다면 Vim 사용자에게 더 낮은 진입 장벽이나 경고가 필요함.