좃소긴 하지만 러스트 현업에서 쓰고 있고 사내 코드베이스 절반 이상이 러스트니까 꽤 진지하게 쓴다고 생각한다
러슬람이고 뭐고 병신들이 떡밥 굴리는 건 알 바 아닌데 그냥 내가 러스트 좋아하는 이유를 좀 써보고 싶어서 쓴다
참고로 본인은 알고 있는 언어 중에 러스트를 제일 잘 하기 때문에 (비교적 잘 한다는 거니까 오해 ㄴㄴ) 다른 언어에 대해서 좀 몰상식한 발언을 할 수도 있음. 지적바람
나름 힙한/안힙한 언어들 몇개 찍먹은 해봤는데 제일 깊게 안다고 생각하는 건 러스트라는 뜻
아직 학부따리라 비전문적인/안 엄밀한 용어가 좀 있을 수 있음
1. 함수형에서 쓰는 기능들을 명령형이랑 잘 버무려놨음
혹자는 함수형이랑 명령형을 대립되는 개념으로 썼다고 지적할 수 있느니까 좀 더 뭉뚱그려서 말하면 적당히 현실적인 선에서 모던하다 이거임.
내가 그렇게 느낀 기능들을 나열해보겠음
1-1. ADT(대수적 타입)
그냥 enum=신 그자체
그냥 상상하는 경우의 수를 and/or 써서 논리식으로 만들면 그게 하나의 타입이 된다는 게 정말 간편하다.
고랭이나 파이썬이었으면 덕타이핑 한다고 인터페이스나 추상클래스로 조건만 줘서 막 껴넣는다던가 더 엄밀하게 하고 싶으면 tagged union을 손으로 짜고 있던가 해야 할텐데
이런 점에서 타입 자체에 각각의 경우의 수를 고려하게 해주는 enum의 존재가 정말 좋은 것 같다.
1-2. 모나드
모나드를 공부한 레퍼런스가 여기 념글이라 좀 확신이 덜 서지만 대충 내가 아는 선에서 설명하면
Option<T>, Result<T>, ?(try), async/await 등등이 다 모나드에서 나온 개념이고 편리함 그 자체다.
Option, Result는 위의 enum으로 이루어진 놈이니 스킵하고 try, async/await도 쓸 때마다 컴파일러 개발자들 있는 곳을 향해 마음속으로 3번씩 절한다
1-3. 반복자/클로저 등등
암튼 편함. 근데 이건 웬만한 다른 언어에도 있고 러스트에서 쓰기 더 불편한 점도 있으니까 뭐 패스
2. 툴링
2016년쯤에 rust 소스코드 git clone한 다음에 racer+vi로 개발해본 적 있는데 그땐 좀 토나오긴 했음
근데 요즘은 rust-analyzer + cargo + VSC + (cargo-expand 등등 서드파티...) 쓰면 너무 좋음
물론 인텔리제이급 리팩토링 기능 이런 건 아직 없지만 나름 러스트 정도면 좋은 개발도구를 갖췄다고 생각함
특히 rustfmt(포매터), clippy(린터)가 언어 공식으로 못박혀서 나오는 게 좋음. 시발 파이똥은 포매터만 몇개냐?
3. 의존성 (거의) 없음
파이썬 코드를 번들링해서 비개발자에게 재배포하는 것보다는 러스트 코드 재배포가 경험적으로 훨씬 쉬웠음.
4. 강력한 타입시스템
위에서 했던 ADT의 연장선인데 lifetime이나 trait, generics 같은 부분에 있어서 개발자 입장에서 안심하고 개발할 수 있는 강력한 무기가 있다는 느낌을 자주 받음. 타입 추론도 잘됨.
심각한 로직버그를 맞는 게 아닌 한(이런 로직버그도 API를 잘 고민하면 만들기 어렵도록 설계할 수 있다 생각함. 예를 들어서 Mutex가 스마트 포인터처럼 데이터를 '감싸서' 락 없이 사용하는 걸 막는 것처럼.) 이상한 세그폴트 맞을 걱정이 없다. unsafe로 칼춤 추는 임베디드나 나이틀리 사용자 등등은 제외
러스트 쓰면서 coredump에 디버거 붙여본적 딱 두번밖에 없고 둘다 unsafe 때문이었음.
이게 제일 핵심같은데 왜 4번이냐면 가끔씩은 너무 딱딱해서 불편할 때도 있기 때문
5. 활용폭이 상당히 넓음
언어 자체가 기본적으로 저비용을 지향하다 보니까 wasm이라던가 eBPF 라던가 다양한 플랫폼에 붙이기에 유리한 듯
특히 async/wasm/스마트컨트랙트 등등 좋은 언어로 좋은기술 구현하면 좋은거제 같은 스탠스가 좀 보임
어쩔때는 오히려 이렇게 너무 신기술 뽕에 차서 폭도들을 양성하는 부작용을 만드는 게 아닌가 생각하기도 함
물론 Rust가 완벽한 건 아니고 맘에 안드는 부분도 많음
1. 신기능 안정화가 너무 느림
타입 시스템이 강력한만큼 복잡하니까 여기에 신기능 붙이려면 이 모든 걸 이해하는 개발자가 필요하고 열심히 구현해서 nightly/beta에서 테스트 하고 stabilize 하려니까 막판에 unsoundness 버그 떠서 리버트하는 그림만 두세번 본듯. Rust 정도면 기여자들 커뮤니티가 엄청 활성화된 편일텐데 그럼에도 불구하고 specialization 같은 핵심 기능들은 정확히 구현할 수 있는 사람이 너무 적어서 그런가 진척이 너무너무 더딤.
물론 기여 없이 쓰는 입장에서 불평할 자격은 전혀 없음. 근데 나이틀리에서만 되는 좋은 기능들이 너무 많다보니까 그림의 떡처럼 느껴질 때가 많음
2. 장황함지나치게 엄밀함
자바랑은 느낌이 좀 다른데 걔는 그냥 말이 많은거고 얘는 요소 하나하나마다 엄밀하게 따지고 들어가는 문법이 너무 많음.
일단 변수에 mut 붙이는 것부터(레퍼런스 말고) Rc<RefCell<T>>라던가 타입 바운드의 바운드가 암시적으로 전달이 안되어서 매번 반복해서 써줘야 한다던가 암튼 무조건 명시적으로 쓰고 보라는 문법이 많아서 쓰다보면 피곤하긴 함
쓰고보니 생각나서 좀 첨언하면 지나치게 엄밀하다는 표현이 더 맞는 것 같고 코드 쓰기에 귀찮은 것도 문제지만 결과적으로 빠른 프로토타이핑-피드백-현실적인 프로덕트 개발 사이클(이걸 XP라 해도 되나?) 에 방해가 되는 부분이 좀 있음. 언어 자체가 장기적인 유지보수성, 강건성을 아주아주 중요한 요소로 잡아버리니까.
그냥 내가 Rust 쪼끔 써보면서 느낀점을 좀 써봤는데 의견 받고 사상검증 하면 러슬람 러들러들 러슬람 러들러들 러슬람 러들러들 러슬람 러들러들 러슬람 러들러들 러슬람 러들러들 러슬람 러들러들 러슬람 러들러들 러슬람 러들러들 러슬람 러들러들
암튼 똥글 읽어줘서 ㄱㅅ
러슬람 러들러들~
들슬람 들들들들
이런글은 추천이죠 현업에서 사용하신다고해서 질문있는데 혹시 라이센스 문제로 dylib사용하게 되는 경우 있었나요? 사용하는 라이브러리중에 lgpl 라이센스 있는게 있어서 동적링킹 해야될 것 같긴한데 더 나은 방법 있나 해서 여쭤봅니다
사실 현업에서 재배포를 하고 있지는 않아서 라이센스 문제를 겪어본적은 없는데 LGPL 걸린 라이브러리면 아마 C/C++ 코드베이스일 거고 그러면 C ABI로 노출을 해놨을 테니 cdylib이 제일 자연스러운 선택이 아닐까 합니다 Rust인데 LGPL이면 C ABI를 안쓸수는 있겠는데 여기부턴 몰라레후
넵 답변 감사합니다!
해당 댓글은 삭제되었습니다.
선생님, 당연히 C로도 Rust가 하는 일들을 다 구현할 수 있습니다 좀 유식하게 표현해서 둘다 튜링완전한 언어니까요. 러스트가 마음에 드는 점은 타입 시스템이 그 구현에서 발생하는 실수를 방지해줄 수 있다는 겁니다. C에서 tag + union으로 Rust의 enum을 똑같이 모사할 수 있지만 까먹고 tag와 union variant를 똑같이 유지하지 않으면 바로 UB가 발생하지 않겠습니까? 물론 sanitizer나 valgrind를 쓰면 잡아낼 수 있지만 정적분석과 런타임에 잡는 건 커버할 수 있는 영역이 다르다고 생각합니다.
그리구 함수형이나 모나드는.. 걍.. 탁상공론에 불과하고 실제 어플 제작이나 라이브러리 제작에 무쓸모임. 이거는 동의하기가 어렵네요. 본문에서도 써놨지만 Option, Result 정도면 훌륭한 적용사례라고 보는데...
물론 숙련된 C 프로그래머면 실수할 일이 없고 덜 숙련되어도 리뷰어가 잡아줄 수는 있지만 사람에게 의존하는 것과 컴퓨터에 의존한다는 것의 차이가 있다 생각합니다. 물론 본문 막바지에 써놨듯이 코드 쓰는 사람이 더 귀찮아지는 단점은 안고 가야지만요. ㅎㅎ
rust enum이랑 struct 써보면 c보다 훨씬 좋은거 아실텐데. 특히 패턴매칭이랑 같이쓰면..
아 패턴매칭도 1번에 넣었어야 했는데 깜빡했네
러스트 언어 컨셉은 확실히 틈새시장 잘 노렸는데 얘도 한 5년정도 지나면 스칼라같이 누더기골렘 프랑켄슈타인 되지 말란 법 없음. 아니 사실 이렇게 될 가능성이 높음
나이틀리 기능들 stabilize가 지지부진한 것중 하나가 이런걸 경계해서 절대 실수하지 않으려고 계속 고민해서인거 같기도 함 ㅋㅋ 한번 stabilize되면 뒤집기가 너무 힘드니까
해당 댓글은 삭제되었습니다.
지적하신 부분이 많습니다. 실험해보니 둘다 hello world 찍었을 때 Rust만 pthread, dl, gcc_s 등등이 로드되네요. 변명을 좀 하자면 no-std로 짜거나 crt-static으로 모두 정적 링킹 해버리면 디펜던시를 줄일 수는 있겠습니다. 물론 바이너리 크기가 커지지만요. ^^
졸려서 오타를 내버렸는데 맞습니다 ^^
본문에서는 딱히 다른 언어보다 낫다 같은 얘기가 없는데 혼자 뜬구름잡는얘기하노 ㅋㅋ
이런게 정상이지
러슬람 러들러들~
보통 명령형-함수형이 대립되는 개념이 아니라 명령형-선언형이 대립되는 개념이라고 하지요
함슬람 함들함들~
전 Go를 많이 쓰니까 고들고들로 해주셈 ㅋㅅㅋ
개추개추
단점 2번 항목은 정적분석이 빡빡하게 필요한 쪽에서는 장점일 수도 있겠네요.
맞습니다. 제가 잘 모르는 분야지만 C+증명보조기 같은 식으로 검증하는 CompCert나 seL4 같은 프로젝트가 있어서 구경해보니까 증명보조기 코드의 규모가 C의 코드 규모를 크게 넘는 것 같더라고요. 그런 점에서 Rust 컴파일러는 비교적 '훨씬 쉽고 간편한' 정적분석 도구라고 생각할 수 있을 것 같은데 일반적으로 빠른 개발 사이클을 돌리는 파이썬/Go 등등의 진영에서 넘어올 때는 공감이 되더라도 '이렇게까지 해야 하나' 하는 인상을 주기에는 Rust도 충분히 복잡한 것 같습니다.
오... 자세히 답글 달아주셨었네요. 정보공유 고맙슴다 ㅎㅎ - dc App
단점 1번 너무 공감됨.. 마이너한 기능들도 아니고 충분히 stable해보이는데도 쓰질 못하는게 슬픔..
러스트 프로덕션에 쓰는회사가 얼마되지않아서 어디인지 감은 오는데 실례되지 않는다면 회사이름이나 채용페이지 공개해줄수 있을까?
러슬람 러들러들~