서버 백엔드, 네이티브 앱, wasm은 rust
프론트엔드 웹은 sveltekit(ts)
쓴다
원래는 백엔드, 앱을 kotlin, python, node.js 이런걸로 만들다가 최근에는 go로 만들었거든
go 진짜 좋음. 사랑스러운 언어지
근데 뭔가 2%가 부족해. GC언어라는 점
특히 요즘같은 wasm 시대에 go로 만들면 wasm의 성능이 GC로 인해 더 제한을 받는거야
wasm은 어차피 웹브라우저로 네이티브 앱 수준의(불가능함 v8엔진 때문에) 성능을 위한건데 go는 GC 땜에 약간 불충분함
그래서 rust로 전향했지
rust wasm은 최강이거든
그리고 rust가 go보다 서버 백엔드 web application server 구동할때 장시간 성능과 안정성이 뛰어다나고 함
나는 잘 모르지
과연 was 구동할때 go와 rust가 실제로 차이가 나는건지
잘 모르니까 rust로 하는거야
rust로 하면 잘 몰라서 고민할 필요없잖아
나는 자꾸 고민하고 비교질 하기 싫어서 그냥 rust로 함
이 새끼들은 사용자 1도 없는 장난감 만들면서 언어 성능이 어쩌구 gc가 어쩌구 하고 있노
흐흐
사용자 1은 있잖아. 나
메모리 안정성 및 런타임 안정성: 말씀하신 대로 Rust의 가장 큰 장점입니다. Rust의 소유권(Ownership) 시스템과 빌림 검사기(Borrow Checker)는 컴파일 시점에 메모리 관련 버그(예: Dangling Pointers, Use-After-Free)를 원천적으로 차단합니다. Go의 가비지 컬렉터(GC)도 메모리 관리를 자동화해주지만, GC 자체가 예측 불가능한 'stop-the-world' 일시 정지를 유발할 수 있고, 데이터 경쟁(Data Race)과 같은 동시성 관련 메모리 문제를 막아주지는 못합니다. 24시간 실행되는 시스템에서 미세한 메모리 누수나 오류가 쌓여 시스템 전체를 멈추게 할 수 있다는 점에서 Rust의 접근 방식이 훨씬 더 견고합니다.
패닉(Panic)으로 인한 프로그램 중단 확률: Rust는 Result와 Option 열거형을 통해 오류 처리를 프로그래머가 명시적으로 하도록 강제합니다. 이는 잠재적인 모든 실패 경로를 개발자가 인지하고 처리하게 만들어, 예기치 않은 panic으로 프로그램이 비정상 종료될 확률을 크게 낮춥니다. 반면 Go의 panic/recover 메커니즘은 상대적으로 덜 구조적이어서, 놓치는 오류가 발생했을 때 프로그램이 중단될 위험이 더 높습니다.
멀티스레드 환경에서의 데이터 경쟁(Data Race) 방지: 이 또한 Rust의 핵심적인 강점입니다. Rust는 Send와 Sync 트레이트를 통해 여러 스레드 간에 데이터를 안전하게 공유할 수 있는지 여부를 컴파일 시점에 검증합니다. 이로 인해 '데이터 경쟁'이라는 매우 찾기 어렵고 위험한 버그가 원천적으로 방지됩니다. Go의 고루틴(goroutine)과 채널은 동시성 프로그래밍을 쉽게 만들어주지만, 뮤텍스(Mutex)를 잘못 사용하거나 메모리를 부주의하게 공유하면 여전히 데이터 경쟁이 발생할 수 있습니다.