22P by xguru 2022-09-21 | favorite | 댓글 55개
  • GC 없는 언어가 꼭 필요한 시나리오라면 Rust를 사용하자
  • 보안과 신뢰성을 위해서임
  • 업계는 C/C++ 을 deprecated 언어로 선언해야 함

그동안 rust 칭송하며 사용하던 사람들도, async 접하면 급 현타가 온다고. 심지어 rust 로는 라이브러리 만들지 말란 건가 (너무 복잡하고 까다롭고 어렵다). 이런 불평도 나오고 있네요

마크 러시노비치가 누군지도 모르면서 깎아 내리는 사람도 있군요... sysinternals tool suite 와 책 windows internals 의 저자입니다... 윈도우즈를 리버스 엔지니어링해서 툴 만들다가 마이크로소프트 펠로우가 된 사람이여요...

rust 광팬 들의 문제점을 단편 영상으로 비꼬는 글

https://twitter.com/cmuratori/status/1367627549816152064?lang=en

rust 는 아직 정식 specification 도 없다는 ....

C++는 정식 spec이 "존재"는 하지만 모든 구현체(gcc, clang, ...)가 incomplete하죠

이게 흔한 논리인데요, 실제로 명세를 많이 읽어 보고 구현도 여러 번 해 본 입장에서는 명세가 있다 없다는 것 자체가 무슨 의미가 있는진 모르겠습니다.

"명세"에는 여러 전략이 있습니다. 겉보기 동작을 중심으로 서술하는 방법과 내부 동작을 서술하는 방법이 있고, 자연어를 사용하냐 기계가 읽을 수 있는 방법(의사 코드라거나 수학적 정의)을 사용하냐가 갈립니다. 파이썬이나 러스트 언어 참조 문서 같은 것은 겉보기 동작을 자연어로 서술한 명세입니다. ISO 표준 등에서 흔히 볼 수 있는 접근은 내부 동작을 자연어로 서술한 명세인데, 이 내부 동작이 실제 구현들의 접근과 일치한다는 보장은 없으며, 대신 이 내부 동작으로 구현된 가상의 구현과 실제 구현이 서로 겉보기에 동일하게 동작observationally equivalent한다면 표준에 합치된다는 식으로 정의합니다. ECMAScript는 자연어로 서술되어 있긴 하지만 실제 구조는 사실상 의사 코드를 자연어로 쓴 수준이며, WebAssembly 같이 내부 동작을 자연어 명세와 수학 정의로 모두 제공하는 경우도 있습니다.

구현 입장에서는 자연어 명세는 거기서 다 거기입니다. 자연어 명세는 실제 구현과 별도로 만들어져야 하기 때문에 자연히 둘이 서로 동떨어지는 경우도 있을 수 있고요, 실수하는 경우도 흔히 생길 수 있습니다. 겉보기 동작이 더 구현하기 편한가 내부 동작이 더 구현하기 편한가는 상황에 따라서 다른데 프로그래밍 언어의 관점에서는 어느 한 쪽을 택해야 할 당위성이 딱히 있진 않습니다. 그런 면에서 러스트는 이미 명세가 존재하며, 다른 대체 구현이 나올 수 있을 정도로 해당 명세가 충분한 정보를 제공하는 게 맞습니다.

단순히 ISO 표준이 되었냐 안 되냐로 표준의 성숙도를 판단하고 싶으시다면, 제가 ISO/IEC 18181-1 JPEG XL 표준에서 버그를 100개 정도 발견했(고 그것 때문에 2nd amendment가 지연되고 있)다는 소식을 알려 드립니다...

해커뉴스에도 800개가 넘는 댓글이 달렸는데.. 여기도 뜨겁군요...
https://news.ycombinator.com/item?id=32905885

수고 많으십니다.
한편.. 어떤사람이 좋아하는 무언가가 공격 받을때
그사람의 반응을 해석하려할때 그사람의 성격탓으로 돌리는 것을 경계해야 한다는 글을 보고 좋은 말이라고 생각했는데, 그이유는 실제상황에서 그러한 마음을 갖기란 어려운 일이기 때문일 것입니다.

트윗 댓글중에 인상깊은 게 있네요 .

People end up writing Rust code the "unsafe way". - 생략 - Rust was never meant to replace those.

이쯤에서, Mark Russinovich가 누군지 알아볼수 있는 링크를 달아봅니다.
https://en.m.wikipedia.org/wiki/Mark_Russinovich

한마디 더 할께요. c++ 사용하면서 자꾸 에러 내고 버그 만들고 하던 사람들이, 야 이거 못쓰겠다 요즘 뜬다는 rust 로 가보자.. 메모리 에러 신경 안써도 된다며.. 이런 사람들은 똑같아요. rust 가지고도 비슷한 버그 만들어 낼거고 ... 그럼 또 다음 언어 뭐 배워서 해볼까 이럴사람 많습니다. c++ 에서 포인터 역참조 도 제대로 안해본 사람들이 rust 빨아대는 거에요.

그런 부류의 인간들은 rust 가 강점으로 주장하는 소유권 , Reference, Borrowing 이런거 컴파일 할때부터 에러 내고 골치아프니까 다 무시하고 그냥 unsafe 섞어서 c++ 인거처럼 막 쓸거란 겁니다.

어차피 죽을거 왜 사나요?
이거랑 거의 같은 수준의 논리네요

어차피 사고치는 사람은 안전벨트도 안매고 신호등도 무시하니까 안전벨트와 신호등은 별 의미가 없다는 주장을 보는 느낌이네요.
잘하는 사람이야 뭘해도 잘하고 못하는 사람은 뭘해도 못한다고 주장이야 할 수 있지만, 그런 논리로 가면 도구의 유용성에 대한 논의가 성립이 안되죠.

언어가 너무 사용하기 난도가 높다는게 문제지 맞는얘기긴 하죠

visual rust 나오면 인정 ㅡ.ㅡㅋ

C/C++은 이제 정말 라틴어 위치로 가는 것 같네요. 학문을 위해서라면 누구든지 공부해야 하지만, 마스터하기에는 불가능에 가깝고, 옛 체계이기 때문에 현재로 따지자면 비합리적인 부분도 많고...

모든 것이 unsafe인 언어들은 잘 쓰면서 제한적으로 unsafe를 쓸 수 있는 언어는 왜 절대 안된다고 하는지 재밌네요.

스톡홀름 신드롬의 일종이라고 봅니다

The Spirit of C  

1. Trust the programmer.  
2. Don’t prevent the programmer from doing what needs to be done.  
3. Keep the language small and simple.  
4. Provide only one way to do an operation.  
5. Make it fast, even if it is not guaranteed to be portable.  

제 개인적인 의견으로는 1번부터 틀린 것 같군요 ㅋㅋ 사람은 태생적으로 error-prone 하기 때문에..

C++도 스마트포인터와 메모리풀 적극적으로 사용하면 되는거라서..
생각보다 포인터를 직접 다룰 일이 많이 없다고 봐요.

전 thread-safe한 코드는 결국 프로그래머 본인의 능력이라고 생각해요.
어떤 언어를 써도 실력이 좋지 않은 경우,
안전하지만 저열한 성능 또는 위험한 코드의 양상이 보이거든요.

프로그래머의 능력에 자동차 운전이나 비행기 운전을 맡기는 건 너무 무섭잖아요....

thread-safe 한 코드는 결국 프로그래머 본인의 능력이다 <- 저는 이 생각이 위험하다고 보는게, memory / thread safety는 단순히 프로그램이 죽는다, 느려진다의 수준이 아니라 보안상의 취약점으로 발전하기 때문에, 이걸 한 개인의 능력에 맡기면 안된다고 생각합니다.
이걸 사전에 막을 수 있는 다양한 방법이 연구되어 왔고 그것들이 성숙해져서 rust 같은 언어나 다른 도구들로 탄생한 것인데 이걸 이용하지 않고 개인의 탓으로 돌리기에는 소프트웨어가 일상생활에 미치는 영향이 너무 거대해졌다고 봐요

사람은 사람인 이상 실수를 할 수 밖에 없고 아무리 똑똑한 프로그래머라도 실수를 하기 마련이죠. 메모리 버그도 결국 실수에서 나오는 거고...

요즘은 알아서 잘 하기보다는 애초에 실수를 하기 힘든 환경을 제공하는 것이 더 나은 접근 방법이 아닐까 싶기도 합니다.

우리 회사에서 rust 사용 하려면 unsafe 는 사용 금지다. 이런 규칙이라도 있어야 언어 차원에서 지원되는 안정성을 한번 믿어보자 할 수 있는 거죠. 근데 이게 말이 되겠습니까 ?

물론 Rust를 사용하는 회사에서는 꼭 필요한 경우가 아니면 unsafe를 쓰면 안 된다는 합의가 있겠죠. 그보다 직접 Rust로 짜 보시는 걸 추천드립니다... unsafe를 쓸 일이 과연 얼마나 있을지는 직접 써 보셔야 알 수 있지 않을까요?

tokio 등 알만한 라이브러리에서는 unsafe 도배질 했음

All or nothing으로 All 아니면 아무런 가치가 없다고 보시는 댓글이 꽤 많네요

unsafe / safe를 명시적으로 구분-격리할 수 있고 메모리 버그 100번 낼 사람이 10번 내게 할 수 있는 장점이 있는데 어쨌든 unsafe 가 있다 / 그래도 메모리 버그는 발생한다 => 고로 C++ 보다 나을게 없다라고 보는 접근법이 현실적인 판단인지는 전 잘 모르겠습니다 😅

댓글 개수로는 그러하지만.....
All or nothing 의견인 한분이 쓴 댓글이 많다... 가 맞는 상황같네요.

저도 이 댓글에 동의합니다. 이분법적으로 어떤 대상을 볼 수록 그냥 자기만 손해입니다.

현업에선 장단점을 따져봐서 결과적으로 제일 +인 걸 선택하기 마련이죠. 업계 특성 상 지금 당장은 C/C++을 사용할 수 밖에 없는게 아니라면 rust 사용했을 때 얻는 이점이 크기 때문에 점점 rust가 사용되는 영역이 넓어지고 있다고 생각합니다.

rust로 옮겨가는 사람들이 뭐 바보도 아니고 rust 써보니깐 C++보다 더 결과적으로 나은게 있으니깐 계속 쓰겠죠 뭐ㅎㅎ

Nothing... Everything

Rust가 Next C++ 라는 데 동의하지 않는 사람은 이제 드물 겁니다. 리눅스 커널에도 공식 언어로 채택했을 정도이니까요.
다만 Rust가 정말로 쓰기 편한 언어인지는 좀 의문입니다... 메모리 안전성을 미연에 잡기 위해서 수행하는 정적 분석 덕분에 컴파일 타임이 꽤 뼈아프고, ownership 같은 semantics가 어려워서 파이썬이나 자바같은 범용 언어보다 훨씬 더 많은 공부를 요하거든요.

컴파일 타임은 LLVM 자체가 문제가 클 것입니다. 페이스북이 LLVM의 instruction sel 개선을 위해 힘쓰고 있으니 상황은 나아지겠죠.

찾아보니 정말로 그러네요. 저는 ownership 관련 type check에 시간을 많이 쏟는 줄 알았는데 llvm backend가 크군요..

rust 가 처음 나왔을 때 굉장히 관심을 가지고 공부를 좀 하다가...unsafe 항목 보고 바로 접었어요. 이걸 왜 배워서 써야 할지 도저히 합리적 설득이 안되더군요. 어차피 조금만 복잡한 프로그램은 unsafe 를 사용해야만 하죠. 그런데 그럼 rust 가 그렇게 자랑하는 안정성은 날라가는 거죠. 이걸 왜 써요 ?

rust에서 unsafe는 로우레벨 코딩할때나 필요하지 일반적인 응용 작성할 때는 거의 쓸 일 없다고 봐도 무방합니다.

그리고 unsafe 블록 안에서 메모리 문제가 발생한다 하더라도 문제가 발생하는 부분은 unsafe 블록 안에 있다는 것이 언어적으로 보장되어 있으니 디버깅을 쉽게 할 수 있다는 장점도 있구요.

unsafe가 있다고 "이걸 왜써요?"라고 물으실 거면 애초에 c/c++은 쓰면 안되지 않나요?

C++ 도 계속 진화 하고 있고, unsafe 쓸 바엔 그냥 c++ 쓰고 말지, 굳이 RUST 배워서 사용할 필요성을 못 느끼는 거죠.

모든 rust 프로그래밍에 unsafe가 필요한 것은 아니라서요.
unsafe가 필요할 정도로 세심한 메모리 조작은 보통 라이브러리 개발로 빠져있기 때문에 (아마 가장 많은 수요가 있을) 어플리케이션 개발 단에서는 unsafe를 쓸 일이 거의 없을 거라고 봅니다.
c++도 계속 진화하고 있는 것은 맞지만 하위호환을 위한 레거시가 너무 뼈아프죠. unsafe 하나 때문에 불만이실 정도라면 c++의 모든 기능이 불만이실 것 같네요 ㅎㅎ

그래서 unsafe가 권장되지는 않죠.
safe를 쓰면 모든게 unsafe나 다름없는 C/C++보다 안전하구요
https://people.mpi-sws.org/~dreyer/papers/rustbelt/paper.pdf

unsafe라는 애매모호한 장치가 없다면 rust 가 c++ 의 진정한 대안이 될 수도 있겠죠

저는 FFI가 조금 만 더 친절했다면 어떨까 하네요.. 복합 구조체를 FFI를 통해서 외부 라이브러리랑 주고 받을려했는데 아주 고통스러웠던 기억이 있네요.

MS가 rust를 적극 지원하고 있는 상황의 연장선으로 보면 아주 자연스러운 발언으로 보입니다.

그 고집센 토발즈도 러스트를 채택했는데, 배우는 사람도 적어지는 언어를 굳이 계속해서 사용할 필요를 못느끼겠어요.

메모리 관련버그 rust 쓴다고 잘대 사라지지 않는다. 버그 만드는 인간들은 뭔 언어를 갖다줘도 버그를 양산하지. C++ 아무런 문제없이 효율적으로 잘 사몽하고 있는데 없애긴 뭘 없애나. 진짜 전쟁 날 폭탄 발언을 함부로 했구만.

c/c++ 아무런 문제없이 효율적으로 잘 사용하고 있다기엔 이미 역사적으로 수많은 메모리 관련 버그가 c/c++에서 터져왔고 지금도 어딘가에서 터지고 있을 겁니다. (덕분에 많은 PL/SE 연구자들이 먹고 살긴 했지만요)
마이크로소프트 발표 내용에 따르면 보안 버그의 70%가 메모리 관련 버그이구요 (https://zdnet.com/article/…)
크로미움 프로젝트에서 조사한 내용도 비슷한데(https://www.chromium.org/Home/chromium-security/memory-safety/), 역시 거의 70%가 메모리 관련 버그였습니다.

윈도우 커널 버그의 대부분이 메모리 관련 에러이고
러스트로 개발하고 있는 부분에 대해서는 해당 에러가 극적으로 줄어들었다는 예전 기사를 어디서 봤는데요..

언어의 태생 자체가 readonly를 적극 권장하는 설계라서 c++보다 더 안전한 언어적 설계라는 것은 부정할 수 없을것 같네요. 다만 이 때문에 듣도보도 못한 소유권이라는 개념이 등장해서 프로그래밍이 힘들어지지만요

아주 잘 설계된 C++ 코드보다 대충 만든 러스트 코드가 통계적으로 더 빠르게 실행된다는 성능상의 이점도 있구요.

뭔가 파이어가 날 수 잇는 말을 했네요. ㅋㅋ
개인적으론 c++은 너무 오래되다보니 하위 호환성에 발목 잡혀서 모던하게 발전이 더디고요.
또 하위 호환성을 철저하게 하면서 모던한 걸 넣다보니 동일한 일을 하는 방법이 너무 여러가지가 되서, 뉴비에게 더 진입 장벽으로 작용한다고 생각해요.
저도 이젠 C++보단 rust가 낫다고 봐요. 메모리 관리 관련 버그 찾느라 눈 벌게 지던 시절은 이제 그만.

네 맞아요.. 제로 베이스에서 출발하는 개발 프로젝트라면 굳이 c++을 선택할 이유가 없죠..

러스트 쓰고 싶어도 보조적으로나 쓰지 업무적으로는 아직 쓸일이 없네요.
그래서 좀처럼 익숙해지지 않기도 하고 잠깐 손 놓으면 까먹어버리기도 하고...
분명 좋아서 쓰고는 싶은데...ㅎ

힙사용성의 효율성을 위한 메모리 풀 한번 작성해본적 없는 것들이 RUST 타령 조낸 하네 ㅎ
Azure CTO 가 뭐 산업계의 표준을 대표할만큼의 오피니언이 아님은 물론 마이크로소프트로 국한해도 마소 입장을 대변하는 오피니언은 절대 아니고 그저 갑자기 뭐가 도져서 지 주관적 생각을 떠벌리는것에 불과할진데... c++ 제대로 못하는것듫이 rust 라고 제대로 할까? 하여간에 이빨까는것듦로 가득하네

말투에서부터 천박함을 여지없이 드러내시는군요. 힘내세요.