요약
마이크로컨트롤러용 언어 Toit v2.0.0이 4년 넘는 알파 개발 끝에 나왔습니다.
개발자 플로리안 로이치가 10월 31일 블로그에서 알린 소식입니다. Toit 언어는 컴퓨터용 스크립트와 ESP32용 앱을 쓰는 언어입니다. 처음에는 토이트웨어가 비공개로 만들었고, 오픈소스로 바뀐 뒤 2024년 회사가 문을 닫자 자원봉사자들이 이어 왔습니다.
왜 중요한가
- 회사가 사라진 뒤에도 자원봉사자들이 프로젝트를 이어 가 첫 정식 버전까지 냈습니다.
- 계획해 둔 큰 호환성 변경을 마쳐서, 이제 버전 번호가 실제 안정성과 맞아떨어지게 됐습니다.
핵심 내용
- 오픈소스 전환 뒤 커밋 2,000건, 변경 50만 줄, 알파 릴리스 200번이 넘게 쌓였습니다.
- 마지막 큰 변경으로 주변장치 API가
gpio.Pin객체 대신 핀 번호를 바로 받게 됐습니다. - Arm 기반 EC618과 거의 모든 ESP32 변종을 지원하고, 통합
toit명령으로 데스크톱 스크립트도 편해졌습니다. - 패키지 관리자를 새로 짰고, 믹스인(여러 클래스가 구현을 함께 쓰는 기능)과 펌웨어 엔벌로프도 들어갔습니다.
- 필요한 기능이 다 갖춰질 때를 기다리면 끝이 없다고 보고, 포매터 같은 작업은 다음 릴리스로 미뤘습니다.
HN 반응
- 홈페이지만 봐서는 무엇인지 모르겠다는 지적이 많았고, 만든 사람들이 V8과 Dart 출신이라는 점을 앞세우라는 주문도 나왔습니다.
- MicroPython·Lua·자바스크립트면 충분하지 않냐는 질문에, 개발자는 이들이 자원이 작은 기기를 염두에 두지 않아 메서드 호출이 비싸다고 답했습니다.
위키백과 문서 https://en.wikipedia.org/wiki/Toit 는 짧지만 맥락을 꽤 많이 알려 줍니다.
가벼운 농담인데요, URL에서 n을 t로 바꾸면 에스토니아어로 음식을 뜻하는 문서가 나와요. https://et.wikipedia.org/wiki/Toit
DNS 블랙홀로 그 도메인을 막고 쓰면 됩니다.
이 시점에서는 미끼 상품 후 갈아타기 수법일 가능성은 낮아 보입니다.
아이고, 흑백 논리로 생각하다가 또 당했네요.
이 언어의 입문 튜토리얼입니다. https://docs.toit.io/language/toitversus
문법이 멋집니다. C가 아예 없었다면 프로그래밍을 이렇게 설계했겠구나 싶습니다.
1958년의 JOVIAL 이래로 시스템 프로그래밍 언어는 계속 있었습니다. C가 없었다면 고를 수 있는 언어는 충분히 많았을 테고, 그러면 어떤 문법이 선호되었을지가 문제입니다.
흥미로운 사고 실험이긴 한데, 솔직히 C는 결함이 많아도 문법 면에서 큰 장점이 하나 있었어요. 바로 중괄호입니다. C가 발명되지 않았더라도 언젠가는 사람들이 Fortran/Pascal/기타 언어식 BEGIN ... END 블록이 성가시고 토큰만 낭비한다는 걸 알아챘을 거예요.
아니요, 그 장점은 UNIX였습니다. 소스 코드가 C 컴파일러와 함께 상징적인 가격에 풀려 있었으니까요. 10년쯤 뒤 AT&T가 요금을 받을 수 있게 되기 전까지는 그랬습니다.
지금은 평범한 영어로 마크다운 토큰을 산더미처럼 쓰고 있는 바로 그 사람들 말씀입니까?
저걸 읽고 홈페이지를 더 봐도 이게 뭔지 전혀 모르겠어요.
ESP32 기기에 프로그램을 배포하는 런타임 겸 스케줄러라고 생각하시면 됩니다. 여러 프로그램을 격리된 상태로 동시에 돌릴 수 있고, 원격 업데이트도 됩니다. 언어는 바이트코드로 컴파일됩니다. 개발자들은 제약이 큰 기기용 VM을 만든 경험이 풍부합니다. V8과 Dart보다 앞선 사례로 https://www.theregister.com/software/2004/07/27/forgotten-language-enables-nonstop-gadgets/1431708 를 보세요.
고맙습니다! 지금 홈페이지에 있는 AI 쓰레기(사람이 쓴 쓰레기인가요? 잘 모르겠네요) 대신 이 설명이 올라가 있어야 한다고 생각해요.
사실 꽤 쓸모 있어 보입니다. 저도 예전에 임베디드 시스템 일을 했는데, 선택지가 마이크로컨트롤러를 써서 기능이 거의 없는 쪽이거나, 아예 풀 리눅스를 써서 (훨씬 비싼 하드웨어를 쓰고) 팀의 절반이 제대로 된 리눅스 앱 개발이며 네트워킹이며 거기 딸려 오는 온갖 일에 정신이 팔리는 쪽이었거든요. 센서 몇 개와 액추에이터 몇 개만 제어하면 되는데 팀이 다중 노드 분산 시스템 설계에 과하게 빠져들지 않도록, 그냥 평범한 C 마이크로컨트롤러를 고르는 경우가 많았어요. 하지만 그건 말씀하신 기능, 즉 여러 작업의 동시 실행과 손쉬운 업데이트가 없었죠. 아, 그리고 printf도요. 이쪽도 당연히 되겠거니 하고 뻔뻔하게 넘겨짚겠습니다.
그러니까 네, 아주 좋아 보이네요!
여담인데, 사용자 이름 참 잘 어울리네요 :)
그 정도는 더 흔한 언어 선택지(MicroPython, NodeMCU/Lua, Espruino/JS)로도 거의 다 됩니다. 이 독자 언어가 더 나은 점이 뭡니까?
시작할 때 그런 것들을 살펴봤습니다. 문제는 제한된 자원을 염두에 두고 설계된 게 아니라는 점이고, 그게 티가 납니다. 예를 들어 객체가 해시 테이블이라 메서드 호출이 비쌉니다. 최상위 실행이 필수라 시작도 느리고요...
더 큰 기계라면 일부는 최적화할 수 있지만(V8), 그런 최적화에는 대개 메모리나 JIT가 필요합니다. (게다가 Python은 성능이 더 좋은 기계에서도 최적화에 애를 먹습니다.)
처음부터 새로 시작하면(V8과 Dart에서 배운 것을 가지고) 쓰는 느낌은 비슷하면서도 훨씬 깔끔하고 빠르게 돌아가는 걸 설계할 수 있습니다.
그 요구 사항들은 서로 충돌하는 면이 있습니다. MCU 하드웨어 성능을 최대한 뽑으려면 보통 C/C++/Rust를 쓰죠. 전체를 그걸로 하거나, MicroPython/NodeMCU/Espruino를 커스텀 빌드해서요. MicroPython에는 배포 전에 PC에서 (선택적으로) 돌려 두는 고성능 코드용 흥미로운 옵션도 있습니다.
그 밖에도 비슷한 특성을 가진 언어들이 있습니다. Wren( https://wren.io/ )은 꽤 괜찮지만 타입 어노테이션이 없고 임베디드를 명시적으로 겨냥하지도 않습니다.
저는 이런 용도에는 WebAssembly가 꽤 마음에 듭니다. 새 언어가 꼭 필요한 게 아니라, AOT 컴파일 모드까지 갖춘 WAMR 1 같은, 임베디드 기기를 겨냥한 Wasm 런타임이 필요한 겁니다.
Toit을 만든 사람들은 크롬의 V8 VM을 처음 만든 사람들입니다. 이 분야를 잘 아는 사람들이에요.
그분들이 만든 사람들이었다는 거죠? 회사가 문을 닫은 뒤에도 계속 관여하고 있나요?
아니라면 홍보가 거의 없는 이유가 설명될 수도 있겠네요.
카스퍼와 저는 지금도 계속 작업하고 있습니다.
정말 반가운 소식이네요! 저는 임베디드 쪽 일은 아니지만 Toit의 언어 설계가 정말 마음에 들거든요. 이 언어가 두 번째 기회를 얻었으면 좋겠습니다. 나왔을 때 사람들 눈에 잘 안 띄고 지나간 느낌이에요.
이 내용을 웹사이트에 눈에 띄게 적어 둬야 합니다. 지금은 신뢰감이나 알맹이, 평판이 전혀 느껴지지 않아요. 그리고 대상이 MCU라면 성능과 자원 요구 사항도 눈에 띄게 보여 줘야 하고요.
Dart 공동 창립에도 참여했죠. 이 분야를 확실히 잘 압니다.
Dart v1.0 얘기입니다. Dart v2.0에는 전혀 관여하지 않았고, 언어 의미 체계가 바뀐 것이 길라드 브라차 같은 사람들이 팀을 떠난 주된 이유였습니다.
언어 의미 체계가 바뀐 것의 어떤 점이 마음에 들지 않았던 건가요?
AOT에 집중하고, 그게 잘 돌아가게 하려고 건전한 정적 타입 시스템을 도입한 점이었을 겁니다.
점진적 타이핑과 JIT를 쓰는 동적 언어에서, 타입 추론을 갖추고 AOT를 쓰는 강타입 언어로 바뀐 겁니다.
계보를 떠올려 보세요. Smalltalk, Self, JavaScript, Dart v 1.0입니다.
Dart도 TypeScript가 누린 인기를 누렸어야 했는데요. 헤일스버그를 상대로 경쟁하기는 어렵죠.
맞아요, 그래도 라르스 박도 컴퓨터 과학 쪽에서 결코 무명이 아니에요. 다만 박은 프로그래밍 언어의 설계보다 구현으로 더 유명한 것 같긴 합니다.
여담이지만 Dart와 TS를 만든 사람이 둘 다 덴마크 사람이라니 재미있네요.
https://en.wikipedia.org/wiki/Anders_Hejlsberg
https://en.wikipedia.org/wiki/Lars_Bak_(computer_programmer)