GPUI의 상태 모델은 복잡한 데스크톱 앱에 한계다
A Critique of GPUI
Rust 데스크톱 GUI 프레임워크 GPUI와 egui의 상태 모델이 복잡한 앱에 확장되지 않는다고 비판한다. GPUI는 `notify`로 엔티티 단위 변경만 알리므로, 3,000개 행에서 라벨 하나 바꾸는 데 8.4ms가 걸리고 행마다 1,000개당 약 3ms씩 증가한다. 정밀도를 높이려 뷰를 잘게 쪼개면 GPUI의 간결한 API가 무너진다. 신호 기반 모델이 더 나은 대안이라고 주장한다.
GPUI는 '빠르다'는 평판이 있다. 상수는 상대적으로 낮을지 몰라도, 점근적으로 보면 많은 것을 놓치고 있다.
HN 토론
92- virtualritz
글 전체에서 수없이 반복되는 핵심 논지는 "확장되지 않는다"이다.
이에 대한 내 답은 이렇다: "그게 무슨 상관인가, 대다수 앱은 복잡한 UI를 갖지 않는다".
그리고 만약 복잡한 UI를 갖는다면, 예컨대 rerun이 egui를 위해 했던 것처럼(글에 설명된) 우회 방법을 만들어낼 수 있다.
대표적인 예로, 내가 여가 시간에 "프롬프트로" 시작한 가장 큰 프로젝트는 이제 500k LOC 규모의 하이브리드 3D 모델링 앱이다. 이 앱은 egui를 사용한다.
모델링 기능 면에서는 Grasshopper/Houdini 사이 어딘가쯤 된다고 말하겠다. 기본 제공 노드가 거의 200개에 커스텀 노드는 얼마든지 추가할 수 있다.
이것만 봐도 UI가 어떤지 감이 올 것이다: 노드 그래프, 파라미터 편집, 위젯 오버레이, 기즈모. 많은 노드가 커스텀 위젯, 램프나 커브 에디터 등을 갖는다.
결코 단순한 UI가 아니다.
하지만 나는 egui 방식의 성능을 걱정하는 데 단 1초도 쓰지 않았다. 그리고 UI가 내 프레임별 통계에 나타나긴 하지만 그 영향은 무시할 수준이다.
- x-complexity
이건 비판 글인 척 위장한 zgui 광고다.
글 자체에서:
> 공개: 나는 GPUI의 현재 Linux 렌더러를 wgpu2로 포팅했고, 아래에 사용된 벤치마크 하네스를 만들었으며, 차트에 등장하는 시그널 기반 Rust 프레임워크인 zgui 작업을 하고 있다.
https://github.com/zortax/zgui
zgui는 지난달에 막 버전 0.1.0을 출시했고, 개발 기간은 3개월이다. 그리고 그것이 유일한 버전이다.
https://github.com/zed-industries/zed/tree/main/crates/gpui
https://crates.io/crates/gpui/versions
GPUI의 마지막 릴리스는 1년 전의 0.2.2였다.
애플리케이션을 어디로 포팅할지 선택할 때 프레임워크의 성숙도는 피할 수 없는 기여 요인이다.
그렇다고 해서 10년 된 프레임워크만 고를 수 있다는 뜻인가? 아니다. 하지만 1개월 된 프로젝트를 쫓아서도 안 된다.
최소값과 최대값이 있고, 최소값은 "확실히 공개 릴리스가 하나뿐인 1개월 된 프로젝트는 아님"에 있다.
- jharsman
주제는 흥미롭지만 AI가 생성한 텍스트는 읽기가 매우 힘들고, 저자가 이 문제에 대해 실제로 고민했는지 의문이 든다.
이걸 고민했다면 직접 쓰라.
- faangguyindia
그래서, 지금까지 존재한 가장 발전된 GUI 프레임워크는 무엇이며, 왜 그것들이 GPUI나 egui보다 우월한가?
과거에 Microsoft보다 GUI가 더 필요했던 회사가 있었나? 어쩌면 그들이 답을 갖고 있을지도? 아니면 Apple이?
소셜 미디어 앱은 이 분야에서 뭔가 발전된 것을 개발할 만큼 GUI가 무겁지 않다고 생각한다.
GUI 복잡성과 애플리케이션 복잡성은 별개의 것이다
글의 논거는 합리적으로 들리지만 결론은 빗나갔다.
- bluegatty
재미있어 보이지만, Rust는 다른 언어들보다 UX에 덜 적합하다 - 트리 기반 자료구조, 못생긴 상태가 많고, 이벤트 기반이며, async 비중이 크고, 당연히 그 계층에서 들어오는 json이나 다른 것들에 '아주 좋은' 라이브러리가 없다.
Rust의 장점을 전혀 잘 활용하지 못하므로, 추가적인 오버헤드를 정당화하기 어렵다.
Rust와 잘 맞을 핵심 라이브러리들이 분명 있다고 생각한다(wgpu는 좋다!). 하지만 핵심 언어 자체는 이상적으로 Rust가 아닐 것이다.
물론 - 할 수는 있다 - 그리고 일부 개발자에게는 아주 재미있을 것이라고 확신한다 - 하지만 이건 동그라미를 네모 구멍에 끼워 넣는 격이라고 생각한다. (수정 - '동그라미를 네모 구멍에 끼워 넣기'라고 말하는 게 사실 개에게 '산책할까?'라고 말하는 것, 즉 '일어나 - 풀어야 할 문제다!'라고 말하는 것과 똑같아서 웃기지만, 내가 말하려는 건 그런 것이다. 꼬리를 흔드는 게 반드시 최선의 선택은 아니라는 것처럼)