글쎄요... Rust가 C/C++ 보다 낫다거나 그 반대의 주장을 아무 배경지식 없이 일방적으로 받아들여서는 안 된다고 생각합니다. C++ 뿐만이 아니라 여러 언어를 두루 실무에 사용해보고 그 장단점을 대체적으로 다 경험해본 개발자 입장에서, 개발자 커뮤니티의 동향까지 두루 알고 있는 입장에서 썰을 좀 풀어보겠습니다. 이런 움직임이 발생하는 이유는 C/C++를 비롯한 지금까지의 언어가 메모리를 적극적으로 제어하지 않아서 메모리 누수라고 불리는 메모리의 과다 사용과, 메모리 관리를 느긋하게 해서 발생하는 메모리 오버플로우나 UAF를 통해 중요 정보의 유출 가능성이 보안성을 해쳤던 전례가 있었던 것을 해결하려는 강력한 업계의 움직임과 관련이 있습니다. 메모리 과다 사용에 관해서는 Mozilla가 메모리를 엄격하게 관리하도록 언어 차원에서 강제하는 Rust라는 언어를 만드는 배경이 되었고, 버려진 메모리 공간에 대한 보안성 확보를 위해 메모리를 타이트하게 관리할 필요가 생긴, 인터넷에서 서비스를 하는 많은 빅테크 기업들의 필요가 Rust를 그들의 주요 프로젝트에 적극적으로 도입하고 서비스를 구현하게 된 계기가 되었습니다. 지금은 상당히 유명한 서비스에 Rust가 도입된 사례를 꽤 많이 찾아볼 수 있죠. 그런데 사실... 개인적으로 메모리의 타이트한 관리가 과연 진짜 보안의 관점에서 메모리 safety를 보장하지는 않을텐데... 기껏해야 필요없는 메모리 레퍼런스를 좀 더 일찍 무효 표시해서 접근하지 못하게 하는 것 말고는 다른 게 없거든요. 또한 최근에 특히 Rust가 주목을 받고 있는 이유는 리눅스의 아버지라고 불리는 리누스 토발즈가 몇 년 전부터 Rust를 커널의 한 부분으로 받아들이게 되어서 입니다. 리누스는 과거에 C++를 커널에 받아들이려 하다가 실패했고 지금도 싫어합니다! 그 이유는 C++가 너무 유연하고 자유로운 나머지 프로그래머들의 나쁜 습관이나 실수까지도 용인하며, 내부적으로 효율적이지 않은 구현의 라이브러리나 STL 요소들을 무 비판적으로 사용하는 프로그래머들이 만들어내는 코드가 프로세스 파워나 메모리를 낭비할 여유가 없는 커널 런타임에 해롭기 때문에 그냥 그런 프로그래머들이 접근하지 못하게 하는 목적과 동시에 그런 나쁜 코드를 받아들이지 않으려는 노력이 같이 작용을 하여 리누스가 C++를 20년도 넘게 최근까지 공개적으로 강하게 비판하는 이유로 작용하였습니다. 최근 (2021년 9월 정도)에도 C++는 쓰레기라는 발언을 하셨지요... 그런 강경한 입장을 가진 리누스가 Rust를 커널에 허용하다니! 큰 뉴스가 아닐수가 없습니다. 도입한 Rust가 앞으로 순수 C로 씌어진 커널 코드를 얼마나 대체할지는 알 수 없어도 25년도 전에 C++를 도입하려다가 실패한 이후로, 여전히 C++에 적대를 보이는 가운데 공식적으로는 처음으로 커널에 진입한 언어이기 때문에 그 주목성이 남다른 것이고, 그 목소리가 앞서 말한 큰 기업의 결정권자들의 목소리에 더해서, Rust가 C/C++를 대체하게 될지도 모른다는 이런 뉴스까지 나오고 있는 것입니다. 아무튼 상황에서 종합적으로 보건데, Rust가 C/C++ 또는 어떠한 다른 언어라도 완전히 대체하지는 못할 것입니다. 아마 커널에 Rust가 받아들여진 이유는 언어 자체가 까다롭고 제한이 강해서 초중급 개발자의 접근성이 떨어지고(?!), 아직은 범용성이 떨어지기 때문에 언어 구조가 비교적 단순하다보니 오히려 특정 영역에서의 성능과 안정성이 어느 정도 보장 되기 때문에 받아들여진 거라고 보이기 때문입니다. 애초에 C/C++가 갑자기 완벽하게 Rust로 대체되는 것은 물리적으로도 불가능합니다. C/C++로 만들어진 라이브러리와 C/C++에 기반한 개발 커뮤니티가 너무 많습니다. 갑자기 모든 개발자들이 아무리 좋아도 Rust로 전부 다시 새로 개발한다는 것은 너무 큰 일입니다. 이건 C가 처음 나왔을 때, FORTRAN이나 COBOL을 대체할 것이라고 했지만, 보수적인 금융권에서는 아직도 COBOL이 사용되고 있는 차원에서 봐도 불가능하다는 점은 너무 확실합니다. 그리고 2011년부터 나오기 시작한 Modern C++를 사용하고 코드에 적극적으로 도입해본 개발자 입장에서는 Rust의 장점이 그리 크게 다가오지도 않습니다. Rust에서 사용하는 메모리 Ownership 개념이나 참조자의 개념은 컴퓨터 과학에서 새로운 개념이 아니며, Rust가 C++가 그런 개념을 언어 차원의 표준으로 받아들이기 전에 먼저 구현을 한 것일 뿐입니다. 모던 C++에서는 unique_ptr, move, weak_ptr, RAII 개념 등을 포함하는 스마트 포인터로 메모리의 라이프사이클을 제어 할 수 있습니다. C++의 자유로움 때문에 초보자가 쓰면 정말 비효율적인 코드를 만들수도 있고, 고급 프로그래머가 쓰면 효율성이 높은 코드가 나올수도 있습니다. 추상화를 높은 수준으로 하면 효율성이 떨어지고, 추상화를 별로 안쓰면 C 코드를 써서 추상화를 시키는 것과 별 다를 바가 없는 코드를 쓸수도 있습니다... (이런 어중간함을 리누스가 싫어하는 겁니다. 그럴거면 차라리 C로 씌여진 추상화된 코드를 잘 이해하는 고수이길 바라는 거죠. 자기 커뮤니티에 코드를 기여하는 사람이 고수이기를 바라는 겁니다.) 이렇게 C++는 자유로운 만큼 메모리 보안 문제도 해결할 수 있는 방법을 제공했고, C++ 표준으로 채택까지 되었습니다. 그러나 초보 프로그래머들이 이런 기능을 이용하지 않는 것도 자유로이 허용한다는 점이 문제일 뿐입니다. 그러나 앞으로 메모리 관리 문제와 다른 차원의 문제가 발생하더라도 C++를 대응 할 수 있을 것이라는 의미도 됩니다. 이런 입장은 C++의 창시자인 Bjarne Stroustrup의 여러 언급에서도 확인이 됩니다. 그는 리누스의 이야기에 대해 20년 전의 옛날 C++라면 나도 싫다는 언급을 한적이 있습니다. 또한 그런 문제를 피할 수 있도록 하는 The ISO standard C++ 가이드 라인을 지켰는지 분석해주는 정적 분석기를 써보라는 입장을 피력합니다. 그럴 필요를 못느끼는 사람들에게는 할 수 없지만... C++ 원래부터가 C++같이 오래되고 유명한 언어가 기존 개념을 지키면서 그런 이슈를 따라 잡는데는 많은 노력이 필요한데, 새로운 것을 추종하는 사람들은 쉽게 무시하고 일방적이 된다고 하면서 말입니다. 그리고 Rust를 포함해서 보안성을 강조하는 모든 언어는 반드시 '취약한' 부분이 있음을 또한 상기하라고 합니다. 그러면 혹자는 (임베디드) 시스템 프로그래밍의 주된 언어인 C가 Rust의 주된 교체 대상이라고 할지도 모릅니다. 사실 잘 보면, 메모리 보안성이 있는 언어는 Rust를 제외한 나머지가 대부분 Garbage Collector가 있는 언어들 입니다. 주기적으로 독립적인 프로세스가 메모리를 관찰하면서 참조가 없어진 메모리를 해제하는 언어들인데 C/C++은 이러한 기능이 없는게 사실이죠. 하지만 최근 누구보다도 큰 C/C++ 코드베이스 (Chromium, 등)를 가진 구글이 하드웨어적으로 메모리를 주기적으로 스캔해서 접근 할 수 없게 메모리 태깅을 하는 방법을 제안하기도 했습니다! 다른 언어가 순수하게 소프트웨어적으로 접근하고 있는 GC 기법을 하드웨어적으로 보완을 하자는 움직임이 일어나고 있는 것입니다. 실제로 ARM 프로세서에서는 단 2%정도의 오버해드로 이를 수행 할 수 있다고 연구 결과를 내놨습니다. 아무튼 C/C++보다 엄격한 정적인 체크를 해서 때로는 프로그래밍이 더 어려운 C/C++를 쓰는 개발자들이 Rust를 점차 대세로 사용하게 되면서, (초중고급 프로그래머들이 문법 안에서 어떻게 쓰든 모두 자유롭게 놔두는) C/C++를 완전히 밀어낼 것이다? 그건 그걸 바라는 몇몇 사람의 희망 사항으로만 남을 것 같습니다. 고급 프로그래머의 입장에서 봤을 때는 Rust를 할 정도면 C/C++도 잘 할거고 그 반대도 마찬가지이며, 코드 베이스가 수십년간 쌓여왔을 뿐만이 아니라, 이런 메모리 세이프티 이슈 외의 다른 이슈에 있어서도 여전히 대응할 여지가 있는 C/C++가 앞으로도 계속 여러 분야에서 널리 쓰이리라 예상합니다. C++는 자유롭기 때문에!
@테스트 제 글의 주된 목표는 다른 관점을 제공하려고 했던 것입니다. Rust를 아주 비판적으로 바라보면 메모리 보안성과 트렌디 하다는 장점을 제외하고, 다른 언어에 비해 특별히 더 뛰어난 장점이 없습니다. 그런데도 Rust을 찬양하는 사람들이 넘쳐납니다. 이런 경우 둘 중 하나죠. 아주 경험이 많거나 아주 경험이 적거나. C/C++ 둘을 이 영상에서는 뭉뚱그려 놓았지만, 세월이 흐르면서 더구나 모던C++까지 나와있는 현 상황에서는 C와 C++ 사이 간격은 Rust가 들어설 정도로 큰 차이가 나 있습니다. Rust는 C와 C++의 틈새시장을 노리는 언어라고 봅니다. C가 오랜 세월동안 어샘블리를 대체하면서 지금에 이르기까지 고급 프로그래밍 개념을 탑제하지 못했는데, C++보다 Rust 접근 방식이 낫다면야 마다할 이유가 없습니다. 그럼에도 불구하고, Rust가 Linux 커널에 받아들여지긴 했지만, 여전히 전면적인 것은 아닙니다. 여전히 EXPERIMENTAL 태그를 달고 있을 것입니다. 다른 여타 언어와 마찬가지로 프로덕션에서는 받아들여지지 않을 확률이 여전히 있습니다. 리누스의 신랄한 반응을 인용하긴 했지만, 사실 커널환경은 그냥 새로운 언어를 받아들이기로 결정하면 그대로 수용 될만한 그런 여유가 있는 곳이 실제로 아닙니다. 말씀하신대로 현재 Rust가 공략하는 쪽은 Linux의 드라이버 쪽인데, 이 부분은 승산이 있긴 있습니다. MacOS에서는 C++로 이 부분을 작성하는데, 왜냐하면 다양한 환경에서 작동해야 하는 특성상 객체지향언어로 잘 설계될 수 있는 특징이 있기 때문입니다. 그래도 Rust in Linux는 넘어야 할 산이 여전히 높고 많습니다: drewdevault.com/2022/10/03/Does-Rust-belong-in-Linux.html
@테스트 unsafe{} 안에서 raw pointer 주소 강제 지정같은 게 가능하고, 이걸로 래핑해서 쓰면 되는데, 이 노가다를 획기적으로 줄여주는 svd2rust 가 있긴 합니다. 그 위에 올라가는 HAL들은 미리 만들어진 HAL 들 있으면 그거 쓰는 게 나으신데, 아직 다른 사람이 HAL을 만들어두는 노가다를 안 했다면... svd2rust 결과 위에서 직접 노가다를 좀 뛰어야...
마크 러시노비치 옛날에 윈도우 해커로 이름을 날리던 분이었는데 게다가 전공도 카네기 멜론에서 컴퓨터공학으로 박사까지 그가 만든 Winternal이란 회사를 마소가 두려워서 사버렸다는 이야기도 있죠 그러면서 MS랑 일하기 시작한거 같은데 지금은 CTO군요. 마크 러시노비치가 20여년전에 도스에서 NTFS파일 시스템을 접근할수 있는 유틸리티를 만든거 보고 정말 놀랬는데
@@cc-uk2ry C/C++에서 러스트로 넘어가는게 가능은 하지만, 지금 러스트 대 C/C++의 관계와 코볼, 파스칼 대 C/C++의 관계와 같다고 생각하면 안되죠? 코볼, 파스칼에 비해서 C언어는 장점이 아주 명확한 대체재였기 때문에 많은 사람들이 넘어갈 수 있었던거고, 러스트는 C++에 비해서 장점이 막강하지만 단점도 동시에 많은 언어입니다. 제가 러스트 개발자이기때문에 (또 다른사람들이 공감하는) 러스트의 단점은 개발 환경이 너무 미성숙 하다는겁니다. 하드웨어나 소프트웨어 개발자(사)의 공식적인 지원이 필요한 인터페이스들이 전혀 러스트를 위해 개발되고 있지 않습니다. 이런 마당에 멀쩡히 잘 있는 C/C++로부터 미성숙한 러스트로 넘어오기에는 메리트가 너무 적죠...
C/C++이 Rust로 대체될 수 있다는 분들은 거의 개발자가 잘만들면 된다라는 걸 기반으로 말씀을 하시는 것 같네요. 다들 혼자 일하시는게 아니라서 아시겠지만, 내가 아무리 잘 짜놔도 같이 일하는 사람이 그 자유도 때문에 프로그램에 논리적인 실수나 버그를 만들어냅니다. 당장에 프로젝트 내에서 함께하는 사람들의 버그를 어찌저찌 발견해내서 막을 수 있다 하더라도, 유지보수 관점으로 가면 또 얘기가 달라지죠. 자바 같은 것도 그나마 인터페이스 같은 DI로 강제하거나 사람이 관리하는 코딩가이드가 룰에 맞춰서 잘 따르기만 한다면 되겠지만… 그게 되던가요? 컴파일 타임에서 모든 메모리 관련 오류를 100%로 검증하는 것만큼 강력한 방법은 없을 것 같습니다. 그것도 언어 문법 자체로요. Rust의 장점은 사람이 할 슈있는 실수를 막는 안정성입니다. 보안성은 그 뒤에 따라오는 부가적인 일부고요
러스트의 ownership은 흥미로운 개념인 듯. 생각을 해보면 개발자들은 c언어를 사용할 때 복잡성을 줄이려고 malloc과 free를 하나의 함수에 넣도록 스스로에게 족쇄를 걸텐데. 그렇게 정형화해서 사용할거면 malloc과 free를 자동화하는게 좋지 않냐는 아이디어인거 같음. 그런데 가끔 malloc과 free를 떼어놓고 싶을 때도 있을텐데
유연성이 필요한 경우 unsafe 블록을 사용하면 됩니다. unsafe 블록을 가능하면 안 사용하는게 좋지만 절대 쓰지 말라는 법은 없다고 생각합니다. 불가피한 경우 사용해도 된다는 게 제 생각합니다. unsafe 블록만 특별히 신경 써서 테스트/디버깅 하면 되기 때문에 C/C++ 보다 편하다는 생각이 드네요.
포토샵, 3D맥스, 파이썬컴파일러, 오토캐드, 우리가 아는 거의 모든 프로그램 c++로 이루어져있습니다. 당장 밥묵고 살려면 C++,자바, 파이선, C#에 억메이지 말고 한개라도 깊이있게 알고, 그리고 이거 저거 다 알면 좋죠. 사실 랭귀지가 거기서 거기라 거의 비슷합니다.
어떤 아저씨가 했던 말이 떠올라요 정말 애저 CTO가 Cpp를 러스트로 대체할려고 했다면 MS 모든 라이브러리가(적어도 애저의 라이브러리) 러스트를 지원하고 비쥬얼스튜디오가 훌륭하게 러스트를 지원해준다면 안갈이유가 없다고, 그런데 그거에 대한 이야기가 없으니 그냥 하는 소리일거다 라고 하던말이 기억납니다
그 어떤 아저씨가 김포프죠. 김포프 말이 맞죠. 김포프는 수 년전부터 실제로 러스트 정말 좋아 하더라구요. 근데 vs같은 훌륭한 툴이 없어서 아쉬워 하더군요. 개발자라면 다 알 겁니다. IDE 가 얼마나 중요한지 말이죠. 사람이 못 하는 일을 IDE가 알아서 해 주는 게 너무 많죠. 솔직히 IDE없이 쌩으로 메모장 등에서 할 수 있는 사람이 얼마나 될까요?
정직하게 말해서 c와 cpp의 생산성이 떨어지는 것은 사실이죠. 영상에서 조금 오류가 있게 설명하기도 했지만, 다른 언어에 비해서 c나 cpp에서 다른 언어가 c, cpp를 대체한다고 말이 나올 때마다 이정도로 반발을 하는 것은 사실 c, cpp 를 주력으로 쓰는 개발자들이 다른 언어를 배우는 데에 인색한 것일 수도 있는듯... 언어는 그냥 도구입니다.. 상황에 맞게쓰면 돼요..
@@그루브-i3i 제가 말한 겸용의 의미를 이해 못하셨나보네요. 해외가 아닌 국내에 공장이 몇개고 그 공장들에 들어가있는 장비들이 얼마나 노후화 되어 있는지 모르시죠? 국내 대기업 이라는곳도 90년대에 들어온 기계들이 비베6.0 으로 개발되어 있고 그 공장 장비들 하루 멈추면 억대 손해 납니다. C/C++로 이미 다 만들어져 있는거 손댈수가 없습니다. 그러니까 러스트 언어로 새로운 기능 추가나 부가적인 장비를 더 달아서 겸용 하는건 가능해도 30년전에 들어온 수십억대 장비들을 대체 해서 쓰는건 불가능하다는 얘기에요
@@jihyuntube6473 ㅋㅋㅋㅋ 경력이 아직 미흡하구만 ㅋㅋㅋ 열정이 ㅋㅋㅋㅋㅋ 현실적인 애기를 한건데 ㅋㅋ 하고싶은 애기만 자기가 하고 ㅋㅋㅋㅋ 왜 ㅋㅋㅋ 새로운 언어들 사장된 언어들이 어마어마해 ㅋㅋㅋㅋㅋㅋㅋㅋ 무조건 바뀌면 몇해 나올때마다 ㅋㅋㅋㅋㅋㅋ 바꿔 ㅋㅋㅋㅋㅋㅋㅋ
현업에서 자동차 관련 개발을 하지만 RUST는 구경 해 본적도 없습니다. 무슨 근거로 자동차쪽에 RUST가 쓰일거라고 주장하시는지 궁금합니다. 하드웨어 연동되는 곳은 여전히 C/C++이 90%이상입니다. 어셈블리가 크로스플랫폼 이슈 때문에 사라져가고 있지만 하드웨어는 여전히 C/C++ 대체제 찾기 어렵습니다. 러스트는 언어적 관심도에 비해 실제 적용 사례는 많지 않습니다. 백엔드쪽에서 주목을 받고 있기는 하지만 실상 사용빈도는 GO쪽이 훨씬 높습니다. RUST가 특정 부분에서 인지도가 상승하고 쓰일거라고는 보지만 C/C++의 대체제 주장은 수긍하기 어려운 부분입니다. 국내 사업은 특성상 RUST가 필요할 정도의 개발이 그렇게 흔하지 않습니다. 기업 대부분이 여전히 백엔드는 JAVA를 더 선호합니다. JAVA로도 충분할 정도의 백엔드가 훨씬 많습니다. 이걸 굳이 RUST로 개발해야할 이유도 없구요. JAVA 라이센스 이슈 때문에 대체제를 찾는 곳도 대부분은 GO쪽으로 더 관심을 가집니다. 그리고, 언어와 보안이 무슨 상관인지 이해하기 힘든 이야기를 하시는데, JAVA가 보안성이 우수하다고 주장했지만 정작 보안이슈 때문에 JAVA사용을 비권장하는 곳도 있습니다. 메모리 이슈 발생한다고 보안 문제가 발생한다는 주장은 억지논리입니다. C/C++/PASCAL 같은 언어가 메모리를 직접 개발자가 관리해야 하기 때문에 휴먼에러가 많이 발생하지만 이게 언어의 문제는 아닙니다. 사람이 따라가지를 못하니 그걸 언어적 차원에서 걸러내자는 시도이기는 하지만 그게 언어 자체의 문제를 이야기하는건 아닙니다. 그리고, SWIFT, KOTLIN같은 이런 트렌드의 언어 사용해보면 장점만 있지는 않습니다. 언어적 차원에서 휴먼에러를 걸러내다보니 불필요할 정도의 강제가 수반됩니다. 이게 생산성을 떨어뜨리기도 하구요. 메모리 이슈는 애플은 명시적 관리에서 오토 가비지 컬렉터로 갔다가 다시 오토 릴리스를 이용하는 방식으로 전환을 했고, MS는 C++CX에서 예전에 DELPHI가 했던 것처럼 컴파일러가 메모리 해제 코드를 자동으로 삽입하는 방식을 쓰기도 했습니다. C++에서는 수년전부터 Transactional Memory개념에 대해 논의가 이루어지고 있습니다. RUST같은 경우는 컴파일러 단계에서 메모리 이슈를 검증하는 방식을 사용합니다. 이건 컴파일러의 정적 분석 기술과 JIT기술이 발전하면서 나온 방식이구요. 또, 새로운 기술이 나온다면 다른 방식의 시도가 이루어 질 겁니다.
애플 SWIFT의 ARC(Automatic Reference Counting)가 휴먼 에러를 모두 해결해주지는 않습니다. ARC의 특성을 제대로 이해하지 않고 코딩할 경우 참조 문제로 메모리 누수가 발생할 수 있어요. 물론 C/C++ 보다는 대단히 다루기 쉽습니다. Rust는 휴먼 에러를 잘 잡아주는 대신에, 코딩이 까다롭습니다. 그래서 빠르게 대중화 되는 건 어려울 거라는 사실을 인정할 수 밖에 없지요. 하지만 Rust는 점점 영역을 넓혀가고 있습니다. 리눅스 디바이스 드라이버를 Rust로 작성할 수 있게 하려는 움직임이 있고 안드로이드 AOSP 개발에도 Rust를 지원하려 하고 있습니다. (둘다 절대로 전면적인 도입은 아님)
Rust는 이미 C대체에 실패했다고 보고 있습니다. 나온지가 7년이나 지났고 이미 수많은 논쟁을 통해 대체 해봐야 의미 없다는 의견이 중론이고 확산에도 실팼죠. 그래서 C/C++을 대체할 다른 프로젝트들이 진행되고 있는데 이것 마져 사실 부정적입니다. C++을 무조건 싫어하는 토발즈가 리눅스에 rust를 도입을 해서 잠시 반짝하긴 했지만.... 현실적으로 rust는 이미 망해있다고 봅니다. 마이크로 소프트 내에서도 C/C++대체를 위한 프로젝트가 진행되고 있는 걸로 아는데 말이죠. 구글에서도 얼마전에 Carbon을 발표했죠. 근데 이것도 어떻게 될지 모르겠습니다. 기본적으로 보안을 위해? 생산성을 위해? 메모리의 동적 할당을 자동으로 관리하고 어쩌고 저쩌고 하는 건 이제 의미가 없죠. C++에서는 이미 smart pointer류가 널리 쓰이고 있어서 수동으로 동적 메모리를 잘하지 않아서 이미 이런 걸로 고통을 받는 개발자는 거의 없다 볼 수 있습니다. 오히려 smart pointer의 편리성과 성능 그리고 포인터의 장점까지 쓸수 있는 상황이 되어서 점점 심각해지는 garbage collection의 고질적 문제들 보다 훨씬 더 좋은 선택이 될 수 있는 상황이 되었죠. 그리고 보안 문제에 고민을 한다는 것은 C언어의 결함이 있어서??? 라기보다는 C언어로 해킹이 가능해서가 아닌가요?? C언어는 포인터로 메모리를 맘대로 억세스가 가능하기 때문에 고도의 해킹 프로그래밍을 작성하기 때문이죠. 다른 managed 언어들은 언어에서 차단해버리지만 C언어는 해커가 맘만 먹는다면 얼마든지 가능하거든요. 그게 문제란 것이지 C언어 자체가 무슨 보안에 결함이 있어서???라고 보기는 힘들다고 봅니다.
정확히 짚어 주셨네요 그리고 이제 좀 C 와 C++을 따로 분리해 줬으면 좋겠는데 말이죠 C언어와 C++이 주로 사용하는 분야 자체가 완전 달라 진지 꽤 오래전 인데 아직까지 둘을 하나로 묶어서 말하고 심지어 그 둘을 대체? 하겠 다니....... C는 임베디드 쪽에선 독보적 인걸로 알고 있고, C++은 거의 대부분 서버사이드 인데 말이죠...
잘못 알고 계시네요. Rust 의 핵심은 unsafe 한 동작을 효과적으로 격리하고, sound하지 않은 프로그램은 컴파일 타임에 오류를 지적하는 데 있다고 봅니다. 네, 그 raw pointer 가지고 온갖 규격 외 동작 시키는 것들이나 스택 변수 삥땅쳐놓았다가 시스템 폭파시키기, 리소스 락 빼먹고 액세스하다가 터뜨리기 같은 것들이요. 그리고 Rust 에서도 raw pointer 사용 가능합니다. 다만 이게 관리가 C/C++ 보다 훨씬 잘 되는 무언가라는 게 다를 뿐요. 개발자는 unsafe{} 안만 신경 쓰면 되기에 인지 부하가 꽤나 감소합니다. + C는 결함 많은 랭기지가 맞습니다. 당장 널 종결 문자열만 봐도 온갖 최적화 이슈와 수 많은 BoF를 끌고 온 주인공이고, sized_free 도 이제야 들어오네 마네 하고 있는 상황인데...
결국 뭘해도 C언어에 파생되서.. 과연 대체가 될련지 진작에 대체언어가 나왔다면 한참전에 나왔겠죠.. 예전에 누가 그랬죠.. 망한다는 C언어 여전히 버티고있는거보면 크크.. 나온다고 해도 C언어의 테두리에선 절대 벗어날수 없다는건 누구나 다 아는 사실.. 만약 c언어의 실행속도를 앞도적으로 잡아먹는다면 생각다시해볼수도?
Rust ownership으로 안정성을 얻게 되어 로켓의 안정성, 자율주행의 무중단 실행 이슈에 더욱 좋은 대안이 될 수 있는데, 영상에서는 로켓에서 C언어 쓰고, 자율중행에서 C언어 쓰니까 Rust로 대체하기는 그렇다는 영상은 완전 Rust의 장점을 반대로 이야기해서 오해를 불러올 수 있는 내용인 것 같습니다.
@테스트 일부 사람은 예측을 잘못한 것 같네요. 가비지컬렉터라든가 하는거 보면 효율적으로 메모리 관리 못하는데 저라면 당연히 자바로는 임베디드 장악 못할 거라고 생각했었고요. 자바는 메모리 관리를 사람이 안하겠다는 수준으로 나온거고, 러스트는 아예 컴파일 단계에서 엄격하게 관리할 수 있도록 강제하는 규칙을 만들어준거죠. 그래서 안정성이라는 장점을 얘기하는것이고요. 말씀하신 C보다 나은 러스트의 장점은 그 메모리에 대한 접근 관리에서 사람이 할 수 있는 실수를 방지할 수 있다는데 있습니다. 각 MCU개발사들은 레지스터나 메모리에 대한 접근변수들을 사전에 잘 정의만 해주고 컴파일러를 만들어준다면, 문제가 생길 수 있는 메모리 접근을 언어에서 고차원적으로 해결해 줄 수 있는거죠.
네.. 이미 C 많이 사용한다고 대체 못할 이유가 되진 않습니다. 자바는 애초에 비교 대상이 아닌게 메모리, 실행 속도등도 문제고 사용중인 시스템에 jvm이 돌아갈 수 있도록 자바를 깔아야하는데 저장용량, 이식성, 버전 문제 등 다양한 이유로 극한의 자원관리가 필요한 임베디드에서 사용되지 못한거구요 rust의 경우에는 메모리 안정성이 높으면서도 비효율적으로 사용하지 않고 속도도 빠르다보니 넘어가야한다는 말이 나오는겁니다. 그리고 C가 나온게 50년이 넘어갑니다.. 러스트는 그에 비해 관심을 받기 시작한지 얼마 안 되었기 때문에 사용자가 적은것도 당연한거고 그렇기 때문에 차근차근 고쳐 나가야한다는거죠. php를 예시로 들었을때 이 시기에 개발자들에게 코딩하라고 던져 주면 더러운 언어라는 말부터 시작해서 보안이 취약하고 쓸 이유가 전혀 없다는 소리 듣습니다 하지만 그럼에도 아직까지 많이 쓰이고 유지보수 되는게 php입니다. 오래된 언어로 개발된 프로그램이 많은 건 당연한겁니다. 특히나 운영체제 같은 경우에는 오랜 시간을 거쳐서 안정화를 거치고 내놓습니다. 당장에 더 좋은 언어가 나왔다고 하더라도 기존에 쓰던걸 버릴수도 없고 기존것도 유지보수하면서 새로운 걸 개발해야하는데 더 많은 돈과 시간이 들어갈 수 밖에 없죠.
오류는 어디에서 오는가 메모리 겹치는 순간 스죠 우주공간으로 쏴버렸는데, 시속 200키로로 달리고 있는데 딱 오류 납니다. 그럼 다시 쏘면 되고 차탄 사람은 죽으면 그만인것을.. 이게 C고 Rust는 안서요. 죽을일도 없을테고, 프로그래머의 실력차가 나는것도 겹겹이 쌓여있는 프로그램에서 메모리 겹치지 않게 전에 만들어 놓은 메모리 요리조리 피해가면서 만들어야하기 때문인데, Rust는 개발 방법론으로 메모리 겹침을 해결한거라서 신석기 구석기 청동기 철기 구분하듯이 우리가 사용하는 무기가 역사적 구분 바뀔정도로 C의 시대에서 Rust 의 시대로 바뀐겁니다. 라고 말할 수 있을 정도의 변화가 있는 것입니다.우리나라 전자정부 프레임워크도 이제 java spring 그만하고 속도 빠르고 안정적인 Rust 로 바꿔야하지 않을까도 생각합니다. 속도 안정성 그리고 전기도 적게 먹어서 Rust 프로그램을 사용하면 환경보호에도 일조하는 샘입니다. 시간 나면 무조건 Rust 공부하세요. Front Back 모두 Rust OS, IOT 모두 Rust 로 변경됩니다. JAVASCRIPT 도 AR VR 문제로 webassembly 대체하면서 Rust로 변경됩니다. 시대가 바뀐겁니다. 현업은 어쩔수 없겠지만. 새프로젝트나 학생은 무조건 RUST 하세요. 메모리 관리의 혁명이 일어난겁니다. 여러분이 왜 프로그램 하면 어~하는지 아세요. 메모리 관리가힘들어서 그랬던거에요. Rust 때문에 메모리 문제가 해결되어서 심지어 OS가 새로나올 판이 만들어진겁니다. 지금 사용량이 많은 프로그램들은 죄다 Rust로 바꾸고 있어요. 질문이 틀린 겁니다. Rust로 C와 C++ 바꿀수있을까가 아니라 아직도 Rust로 안바꾸고 뭐하고있냐가 시대에 맞는 질문이 아닐까요!
Rust는 MS에서나... 다른데선 그닥... 그네들이 충분히 입맛에 맞는 C/C++ 경력자들로 모두 채우기도 어렵고, 그에 따른 실수는 치명적일때도 있는데다가, 짧거나 서버 백엔드에서 돌릴 코드를 굳이.... 하는 입장에서 차라리 새 언어를 (Rust) 쓰자는 입장에서 주장하는 얘기라고 생각합니다. 다른 산업계에선 이걸 굳이... ?? 학원에서야 좋다면서 이걸 가르칠 일이(?) 있을수도 있겠지만 이게 전망 좋다고 약팔이 하기에도 나온지가 꽤 됐죠?. 어쨋건 향후 사용 전망에 부정적임. 동의하기 힘듦.
rust가 너무 powerful해서 사라질리는 없다. (rust의 소유권 개념을 탑재한 다른 언어가 생기지 않는 이상) 하지만 개발자 양성하는데 너무 진입장벽이 높고, 아마도 최소 대리급 이상 개발자을 뽑을 수 밖에 없을 것이다. 그만큼 개발하는데 단가가 올라간다. 한동안 C++, C, C#, java, rust(&go), python, kotlin, swift같은 언어의 춘추전국시대를 피하기 어려울 거 같다.
@@Snowflake_tv 아. 요지는 회사에서 기존 사용하던 툴.프로젝트들이 시용하던 언어를 대부분 따라간다는 겁니다. Java를 썻다면 java를 쓰는거고. 신규 언어를 작용하려고 하면 아무래도 기존 개발자들이 그걸 모르기도 하고 그렇기에 신규프로젝트에 적용하기는 큰 모험일 수 있죠.
GPT 질문 :rust 와 C 또는 CPP 중에 뭐가 미래에 전망이 높다고 생각되니? Rust와 C/C++은 모두 강력한 시스템 프로그래밍 언어로서 널리 사용되고 있는 언어입니다. 하지만 Rust는 현대적인 언어로서의 특징과 안전성, 병행성, 메모리 안전성 등의 강점을 갖추고 있어 미래에 전망이 높다고 평가됩니다. 이에는 다음과 같은 이유들이 있습니다: 안전성: Rust는 메모리 안전성을 강제하는 고유한 소유권 시스템과 러스트 컴파일러의 엄격한 정적 분석을 통해 메모리 오류, 데이터 경쟁 등의 버그를 사전에 방지할 수 있습니다. 이는 소프트웨어의 안정성과 신뢰성을 높일 수 있으며, 보안 취약점을 최소화하는 데 도움이 됩니다. 병행성: Rust는 메모리 안전성을 유지하면서도 효과적인 병행성 프로그래밍을 지원합니다. 고유한 소유권 시스템과 병행성 패턴을 통해 경합 조건 및 데드락과 같은 문제를 최소화할 수 있습니다. 생산성: Rust는 현대적인 문법과 기능을 제공하여 개발자의 생산성을 높입니다. 잠재적인 버그를 사전에 잡아내는 정적 분석 도구와 함께, 풍부한 도구 생태계와 다양한 라이브러리가 제공되어 개발을 용이하게 합니다. 커뮤니티와 생태계: Rust는 점점 성장하는 활발한 커뮤니티와 생태계를 가지고 있습니다. Rust 개발자 커뮤니티의 지속적인 기여와 업계에서의 관심이 매년 증가하고 있으며, Rust를 사용하는 프로젝트와 도구의 수도 증가하고 있습니다. C/C++은 여전히 많은 소프트웨어 시스템에서 사용되고 있으며, 특히 저수준 시스템 프로그래밍이 필요한 영역에서는 여전히 중요한 역할을 합니다. 그러나 Rust는 현대적인 시스템 프로그래밍 언어로서 더 나은 안전성과 생산성을 제공하므로, 앞으로의 전망이 높아질 것으로 예상됩니다.
MS 개발자들이 윈도우즈 메모리 버그 70% 만들어냈지요. MS C++개발자의 발톱의 때도 못한 님이 더 잘할 가능성은 없다고 보여지네요. 만약 메모리 버그를 만든적이 없다면 님은 그만큼 쉬운 프로젝트만 했다는 방증입니다. 모던언어들은 개발자의 실수를 미연에 방지하는 기술이 필수적입니다. 구태인 C/C++ 밥통 붙들어 매고 싶은 마음은 이해하지만..ㅎㅎ
![[re:COMMIT] Go 언어, 어디에 써야 할까? - 이호민 개발자](/img/1.gif)
글쎄요... Rust가 C/C++ 보다 낫다거나 그 반대의 주장을 아무 배경지식 없이 일방적으로 받아들여서는 안 된다고 생각합니다. C++ 뿐만이 아니라 여러 언어를 두루 실무에 사용해보고 그 장단점을 대체적으로 다 경험해본 개발자 입장에서, 개발자 커뮤니티의 동향까지 두루 알고 있는 입장에서 썰을 좀 풀어보겠습니다.
이런 움직임이 발생하는 이유는 C/C++를 비롯한 지금까지의 언어가 메모리를 적극적으로 제어하지 않아서 메모리 누수라고 불리는 메모리의 과다 사용과, 메모리 관리를 느긋하게 해서 발생하는 메모리 오버플로우나 UAF를 통해 중요 정보의 유출 가능성이 보안성을 해쳤던 전례가 있었던 것을 해결하려는 강력한 업계의 움직임과 관련이 있습니다.
메모리 과다 사용에 관해서는 Mozilla가 메모리를 엄격하게 관리하도록 언어 차원에서 강제하는 Rust라는 언어를 만드는 배경이 되었고, 버려진 메모리 공간에 대한 보안성 확보를 위해 메모리를 타이트하게 관리할 필요가 생긴, 인터넷에서 서비스를 하는 많은 빅테크 기업들의 필요가 Rust를 그들의 주요 프로젝트에 적극적으로 도입하고 서비스를 구현하게 된 계기가 되었습니다. 지금은 상당히 유명한 서비스에 Rust가 도입된 사례를 꽤 많이 찾아볼 수 있죠. 그런데 사실... 개인적으로 메모리의 타이트한 관리가 과연 진짜 보안의 관점에서 메모리 safety를 보장하지는 않을텐데... 기껏해야 필요없는 메모리 레퍼런스를 좀 더 일찍 무효 표시해서 접근하지 못하게 하는 것 말고는 다른 게 없거든요.
또한 최근에 특히 Rust가 주목을 받고 있는 이유는 리눅스의 아버지라고 불리는 리누스 토발즈가 몇 년 전부터 Rust를 커널의 한 부분으로 받아들이게 되어서 입니다. 리누스는 과거에 C++를 커널에 받아들이려 하다가 실패했고 지금도 싫어합니다! 그 이유는 C++가 너무 유연하고 자유로운 나머지 프로그래머들의 나쁜 습관이나 실수까지도 용인하며, 내부적으로 효율적이지 않은 구현의 라이브러리나 STL 요소들을 무 비판적으로 사용하는 프로그래머들이 만들어내는 코드가 프로세스 파워나 메모리를 낭비할 여유가 없는 커널 런타임에 해롭기 때문에 그냥 그런 프로그래머들이 접근하지 못하게 하는 목적과 동시에 그런 나쁜 코드를 받아들이지 않으려는 노력이 같이 작용을 하여 리누스가 C++를 20년도 넘게 최근까지 공개적으로 강하게 비판하는 이유로 작용하였습니다. 최근 (2021년 9월 정도)에도 C++는 쓰레기라는 발언을 하셨지요...
그런 강경한 입장을 가진 리누스가 Rust를 커널에 허용하다니! 큰 뉴스가 아닐수가 없습니다. 도입한 Rust가 앞으로 순수 C로 씌어진 커널 코드를 얼마나 대체할지는 알 수 없어도 25년도 전에 C++를 도입하려다가 실패한 이후로, 여전히 C++에 적대를 보이는 가운데 공식적으로는 처음으로 커널에 진입한 언어이기 때문에 그 주목성이 남다른 것이고, 그 목소리가 앞서 말한 큰 기업의 결정권자들의 목소리에 더해서, Rust가 C/C++를 대체하게 될지도 모른다는 이런 뉴스까지 나오고 있는 것입니다.
아무튼 상황에서 종합적으로 보건데, Rust가 C/C++ 또는 어떠한 다른 언어라도 완전히 대체하지는 못할 것입니다. 아마 커널에 Rust가 받아들여진 이유는 언어 자체가 까다롭고 제한이 강해서 초중급 개발자의 접근성이 떨어지고(?!), 아직은 범용성이 떨어지기 때문에 언어 구조가 비교적 단순하다보니 오히려 특정 영역에서의 성능과 안정성이 어느 정도 보장 되기 때문에 받아들여진 거라고 보이기 때문입니다.
애초에 C/C++가 갑자기 완벽하게 Rust로 대체되는 것은 물리적으로도 불가능합니다. C/C++로 만들어진 라이브러리와 C/C++에 기반한 개발 커뮤니티가 너무 많습니다. 갑자기 모든 개발자들이 아무리 좋아도 Rust로 전부 다시 새로 개발한다는 것은 너무 큰 일입니다. 이건 C가 처음 나왔을 때, FORTRAN이나 COBOL을 대체할 것이라고 했지만, 보수적인 금융권에서는 아직도 COBOL이 사용되고 있는 차원에서 봐도 불가능하다는 점은 너무 확실합니다.
그리고 2011년부터 나오기 시작한 Modern C++를 사용하고 코드에 적극적으로 도입해본 개발자 입장에서는 Rust의 장점이 그리 크게 다가오지도 않습니다. Rust에서 사용하는 메모리 Ownership 개념이나 참조자의 개념은 컴퓨터 과학에서 새로운 개념이 아니며, Rust가 C++가 그런 개념을 언어 차원의 표준으로 받아들이기 전에 먼저 구현을 한 것일 뿐입니다. 모던 C++에서는 unique_ptr, move, weak_ptr, RAII 개념 등을 포함하는 스마트 포인터로 메모리의 라이프사이클을 제어 할 수 있습니다.
C++의 자유로움 때문에 초보자가 쓰면 정말 비효율적인 코드를 만들수도 있고, 고급 프로그래머가 쓰면 효율성이 높은 코드가 나올수도 있습니다. 추상화를 높은 수준으로 하면 효율성이 떨어지고, 추상화를 별로 안쓰면 C 코드를 써서 추상화를 시키는 것과 별 다를 바가 없는 코드를 쓸수도 있습니다... (이런 어중간함을 리누스가 싫어하는 겁니다. 그럴거면 차라리 C로 씌여진 추상화된 코드를 잘 이해하는 고수이길 바라는 거죠. 자기 커뮤니티에 코드를 기여하는 사람이 고수이기를 바라는 겁니다.)
이렇게 C++는 자유로운 만큼 메모리 보안 문제도 해결할 수 있는 방법을 제공했고, C++ 표준으로 채택까지 되었습니다. 그러나 초보 프로그래머들이 이런 기능을 이용하지 않는 것도 자유로이 허용한다는 점이 문제일 뿐입니다. 그러나 앞으로 메모리 관리 문제와 다른 차원의 문제가 발생하더라도 C++를 대응 할 수 있을 것이라는 의미도 됩니다.
이런 입장은 C++의 창시자인 Bjarne Stroustrup의 여러 언급에서도 확인이 됩니다. 그는 리누스의 이야기에 대해 20년 전의 옛날 C++라면 나도 싫다는 언급을 한적이 있습니다. 또한 그런 문제를 피할 수 있도록 하는 The ISO standard C++ 가이드 라인을 지켰는지 분석해주는 정적 분석기를 써보라는 입장을 피력합니다. 그럴 필요를 못느끼는 사람들에게는 할 수 없지만... C++ 원래부터가 C++같이 오래되고 유명한 언어가 기존 개념을 지키면서 그런 이슈를 따라 잡는데는 많은 노력이 필요한데, 새로운 것을 추종하는 사람들은 쉽게 무시하고 일방적이 된다고 하면서 말입니다. 그리고 Rust를 포함해서 보안성을 강조하는 모든 언어는 반드시 '취약한' 부분이 있음을 또한 상기하라고 합니다.
그러면 혹자는 (임베디드) 시스템 프로그래밍의 주된 언어인 C가 Rust의 주된 교체 대상이라고 할지도 모릅니다. 사실 잘 보면, 메모리 보안성이 있는 언어는 Rust를 제외한 나머지가 대부분 Garbage Collector가 있는 언어들 입니다. 주기적으로 독립적인 프로세스가 메모리를 관찰하면서 참조가 없어진 메모리를 해제하는 언어들인데 C/C++은 이러한 기능이 없는게 사실이죠. 하지만 최근 누구보다도 큰 C/C++ 코드베이스 (Chromium, 등)를 가진 구글이 하드웨어적으로 메모리를 주기적으로 스캔해서 접근 할 수 없게 메모리 태깅을 하는 방법을 제안하기도 했습니다! 다른 언어가 순수하게 소프트웨어적으로 접근하고 있는 GC 기법을 하드웨어적으로 보완을 하자는 움직임이 일어나고 있는 것입니다. 실제로 ARM 프로세서에서는 단 2%정도의 오버해드로 이를 수행 할 수 있다고 연구 결과를 내놨습니다.
아무튼 C/C++보다 엄격한 정적인 체크를 해서 때로는 프로그래밍이 더 어려운 C/C++를 쓰는 개발자들이 Rust를 점차 대세로 사용하게 되면서, (초중고급 프로그래머들이 문법 안에서 어떻게 쓰든 모두 자유롭게 놔두는) C/C++를 완전히 밀어낼 것이다? 그건 그걸 바라는 몇몇 사람의 희망 사항으로만 남을 것 같습니다. 고급 프로그래머의 입장에서 봤을 때는 Rust를 할 정도면 C/C++도 잘 할거고 그 반대도 마찬가지이며, 코드 베이스가 수십년간 쌓여왔을 뿐만이 아니라, 이런 메모리 세이프티 이슈 외의 다른 이슈에 있어서도 여전히 대응할 여지가 있는 C/C++가 앞으로도 계속 여러 분야에서 널리 쓰이리라 예상합니다.
C++는 자유롭기 때문에!
@테스트 제 글의 주된 목표는 다른 관점을 제공하려고 했던 것입니다. Rust를 아주 비판적으로 바라보면 메모리 보안성과 트렌디 하다는 장점을 제외하고, 다른 언어에 비해 특별히 더 뛰어난 장점이 없습니다. 그런데도 Rust을 찬양하는 사람들이 넘쳐납니다. 이런 경우 둘 중 하나죠. 아주 경험이 많거나 아주 경험이 적거나.
C/C++ 둘을 이 영상에서는 뭉뚱그려 놓았지만, 세월이 흐르면서 더구나 모던C++까지 나와있는 현 상황에서는 C와 C++ 사이 간격은 Rust가 들어설 정도로 큰 차이가 나 있습니다. Rust는 C와 C++의 틈새시장을 노리는 언어라고 봅니다. C가 오랜 세월동안 어샘블리를 대체하면서 지금에 이르기까지 고급 프로그래밍 개념을 탑제하지 못했는데, C++보다 Rust 접근 방식이 낫다면야 마다할 이유가 없습니다.
그럼에도 불구하고, Rust가 Linux 커널에 받아들여지긴 했지만, 여전히 전면적인 것은 아닙니다. 여전히 EXPERIMENTAL 태그를 달고 있을 것입니다. 다른 여타 언어와 마찬가지로 프로덕션에서는 받아들여지지 않을 확률이 여전히 있습니다. 리누스의 신랄한 반응을 인용하긴 했지만, 사실 커널환경은 그냥 새로운 언어를 받아들이기로 결정하면 그대로 수용 될만한 그런 여유가 있는 곳이 실제로 아닙니다.
말씀하신대로 현재 Rust가 공략하는 쪽은 Linux의 드라이버 쪽인데, 이 부분은 승산이 있긴 있습니다. MacOS에서는 C++로 이 부분을 작성하는데, 왜냐하면 다양한 환경에서 작동해야 하는 특성상 객체지향언어로 잘 설계될 수 있는 특징이 있기 때문입니다.
그래도 Rust in Linux는 넘어야 할 산이 여전히 높고 많습니다: drewdevault.com/2022/10/03/Does-Rust-belong-in-Linux.html
@테스트 unsafe{} 안에서 raw pointer 주소 강제 지정같은 게 가능하고, 이걸로 래핑해서 쓰면 되는데, 이 노가다를 획기적으로 줄여주는 svd2rust 가 있긴 합니다.
그 위에 올라가는 HAL들은 미리 만들어진 HAL 들 있으면 그거 쓰는 게 나으신데, 아직 다른 사람이 HAL을 만들어두는 노가다를 안 했다면... svd2rust 결과 위에서 직접 노가다를 좀 뛰어야...
공감합니다. 그리고 요새 러스트를 배우면 c/c++ 공부 안해도 되는 것처럼 얘기하는데 결국 이미 기존 코드들이 c/c++이기 때문에 필연적으로 학습을 하긴 해야할 겁니다.
기껏해야 메모리 레퍼런스를 좀 더 일찍 무효 표시해서 접근하지 못하게 하는게, 메모리 관련 취약점의 전부입니다
와우 엄청난 내공의 댓글입니다
마크 러시노비치 옛날에 윈도우 해커로 이름을 날리던 분이었는데 게다가 전공도 카네기 멜론에서 컴퓨터공학으로 박사까지 그가 만든 Winternal이란 회사를 마소가 두려워서 사버렸다는 이야기도 있죠 그러면서 MS랑 일하기 시작한거 같은데 지금은 CTO군요. 마크 러시노비치가 20여년전에 도스에서 NTFS파일 시스템을 접근할수 있는 유틸리티를 만든거 보고 정말 놀랬는데
기존에 C/C++ 로 만들어 놓은 건 대체불가. 새로 또는 추가로 만들어야 하는데 C/C++로 만들기에는 부담스러운 것들은 러스트나 고로 만들면 괜찮을 듯.
메인프레임의 코볼이나 파스칼도 C/C++로 대체됬는데 러스트로 넘어가는 것도 가능하죠
@@cc-uk2ry C/C++에서 러스트로 넘어가는게 가능은 하지만, 지금 러스트 대 C/C++의 관계와 코볼, 파스칼 대 C/C++의 관계와 같다고 생각하면 안되죠? 코볼, 파스칼에 비해서 C언어는 장점이 아주 명확한 대체재였기 때문에 많은 사람들이 넘어갈 수 있었던거고, 러스트는 C++에 비해서 장점이 막강하지만 단점도 동시에 많은 언어입니다. 제가 러스트 개발자이기때문에 (또 다른사람들이 공감하는) 러스트의 단점은 개발 환경이 너무 미성숙 하다는겁니다. 하드웨어나 소프트웨어 개발자(사)의 공식적인 지원이 필요한 인터페이스들이 전혀 러스트를 위해 개발되고 있지 않습니다. 이런 마당에 멀쩡히 잘 있는 C/C++로부터 미성숙한 러스트로 넘어오기에는 메리트가 너무 적죠...
세계 it 시장 클라우드로의 대전환 시점에
Wasm은 점점 필수가 될것이고
이에 rust가 폭발적인 시장 점유율을 차지할것이라 확신합니다.
감사합니다 저도 러스트 준비 중에 있습니다
좋은 영상 감사합니다
C/C++이 Rust로 대체될 수 있다는 분들은 거의 개발자가 잘만들면 된다라는 걸 기반으로 말씀을 하시는 것 같네요. 다들 혼자 일하시는게 아니라서 아시겠지만, 내가 아무리 잘 짜놔도 같이 일하는 사람이 그 자유도 때문에 프로그램에 논리적인 실수나 버그를 만들어냅니다.
당장에 프로젝트 내에서 함께하는 사람들의 버그를 어찌저찌 발견해내서 막을 수 있다 하더라도, 유지보수 관점으로 가면 또 얘기가 달라지죠.
자바 같은 것도 그나마 인터페이스 같은 DI로 강제하거나 사람이 관리하는 코딩가이드가 룰에 맞춰서 잘 따르기만 한다면 되겠지만… 그게 되던가요?
컴파일 타임에서 모든 메모리 관련 오류를 100%로 검증하는 것만큼 강력한 방법은 없을 것 같습니다.
그것도 언어 문법 자체로요. Rust의 장점은 사람이 할 슈있는 실수를 막는 안정성입니다. 보안성은 그 뒤에 따라오는 부가적인 일부고요
그게 대체할만한 강력한 이유가 되냐가 문제지
그리고 메모리 객체 소유 개념은 애초에 새로운 개념이 아니고
그게 진짜 보안을 위한 최선이냐도 문제
러스트의 ownership은 흥미로운 개념인 듯.
생각을 해보면 개발자들은 c언어를 사용할 때 복잡성을 줄이려고 malloc과 free를 하나의 함수에 넣도록 스스로에게 족쇄를 걸텐데.
그렇게 정형화해서 사용할거면 malloc과 free를 자동화하는게 좋지 않냐는 아이디어인거 같음.
그런데 가끔 malloc과 free를 떼어놓고 싶을 때도 있을텐데
smart pointer와 같은 개념인가요??
스마트 포인터를 컴파일 타임에 넣은거라 생각하면 됩니다
스마트 포인터도 확실히 편해졌는데 lifetime 체크도 있으면 더 편하겠네요
자세한 설명 감사합니다
유연성이 필요한 경우 unsafe 블록을 사용하면 됩니다.
unsafe 블록을 가능하면 안 사용하는게 좋지만
절대 쓰지 말라는 법은 없다고 생각합니다.
불가피한 경우 사용해도 된다는 게 제 생각합니다.
unsafe 블록만 특별히 신경 써서 테스트/디버깅 하면 되기 때문에 C/C++ 보다 편하다는 생각이 드네요.
그래서 azure에서 rust로 만든 새 프로젝트는 어디에 있는겁니까?
포토샵, 3D맥스, 파이썬컴파일러, 오토캐드, 우리가 아는 거의 모든 프로그램 c++로 이루어져있습니다. 당장 밥묵고 살려면 C++,자바, 파이선, C#에 억메이지 말고
한개라도 깊이있게 알고, 그리고 이거 저거 다 알면 좋죠. 사실 랭귀지가 거기서 거기라 거의 비슷합니다.
어떤 아저씨가 했던 말이 떠올라요 정말 애저 CTO가 Cpp를 러스트로 대체할려고 했다면 MS 모든 라이브러리가(적어도 애저의 라이브러리) 러스트를 지원하고 비쥬얼스튜디오가 훌륭하게 러스트를 지원해준다면 안갈이유가 없다고, 그런데 그거에 대한 이야기가 없으니 그냥 하는 소리일거다 라고 하던말이 기억납니다
그 어떤 아저씨가 김포프죠. 김포프 말이 맞죠. 김포프는 수 년전부터 실제로 러스트 정말 좋아 하더라구요. 근데 vs같은 훌륭한 툴이 없어서 아쉬워 하더군요. 개발자라면 다 알 겁니다. IDE 가 얼마나 중요한지 말이죠. 사람이 못 하는 일을 IDE가 알아서 해 주는 게 너무 많죠. 솔직히 IDE없이 쌩으로 메모장 등에서 할 수 있는 사람이 얼마나 될까요?
정직하게 말해서 c와 cpp의 생산성이 떨어지는 것은 사실이죠. 영상에서 조금 오류가 있게 설명하기도 했지만, 다른 언어에 비해서 c나 cpp에서 다른 언어가 c, cpp를 대체한다고 말이 나올 때마다 이정도로 반발을 하는 것은 사실 c, cpp 를 주력으로 쓰는 개발자들이 다른 언어를 배우는 데에 인색한 것일 수도 있는듯... 언어는 그냥 도구입니다.. 상황에 맞게쓰면 돼요..
다른 언어를 배우는데에 인색하다는 것보다는 그 언어의 역사가 너무 길어서 구현이 전부 가능하단점에서 있다고 봄, C언어를 실전에서 할 정도면 다른 언어들 몇개는 기본적으로 알고도 남음
대체 불가, 겸용은 가능
어셈블리어를 겸용한다고 말하는 곳이 있나요?
같은 논리라고 봅니다
러스트로 대체 가능하다고 봅니다
@@그루브-i3i 제가 말한 겸용의 의미를 이해 못하셨나보네요. 해외가 아닌 국내에 공장이 몇개고 그 공장들에 들어가있는 장비들이 얼마나 노후화 되어 있는지 모르시죠? 국내 대기업 이라는곳도 90년대에 들어온 기계들이 비베6.0 으로 개발되어 있고 그 공장 장비들 하루 멈추면 억대 손해 납니다. C/C++로 이미 다 만들어져 있는거 손댈수가 없습니다. 그러니까 러스트 언어로 새로운 기능 추가나 부가적인 장비를 더 달아서 겸용 하는건 가능해도 30년전에 들어온 수십억대 장비들을 대체 해서 쓰는건 불가능하다는 얘기에요
@@KimCoder_ 이미 만든건 관리만 하면 되지요. 컨텍스트가 훅 나가시네요
아직 멀었고 짜피 임베디드에선 로우레벨 프로그래밍이 아직까진 필수수준이라서 많이 멀었다고 생각함
@@jihyuntube6473 ㅋㅋㅋㅋ 경력이 아직 미흡하구만 ㅋㅋㅋ 열정이 ㅋㅋㅋㅋㅋ 현실적인 애기를 한건데 ㅋㅋ 하고싶은 애기만 자기가 하고 ㅋㅋㅋㅋ 왜 ㅋㅋㅋ 새로운 언어들 사장된 언어들이 어마어마해 ㅋㅋㅋㅋㅋㅋㅋㅋ 무조건 바뀌면 몇해 나올때마다 ㅋㅋㅋㅋㅋㅋ 바꿔 ㅋㅋㅋㅋㅋㅋㅋ
현업에서 자동차 관련 개발을 하지만 RUST는 구경 해 본적도 없습니다. 무슨 근거로 자동차쪽에 RUST가 쓰일거라고 주장하시는지 궁금합니다. 하드웨어 연동되는 곳은 여전히 C/C++이 90%이상입니다. 어셈블리가 크로스플랫폼 이슈 때문에 사라져가고 있지만 하드웨어는 여전히 C/C++ 대체제 찾기 어렵습니다. 러스트는 언어적 관심도에 비해 실제 적용 사례는 많지 않습니다.
백엔드쪽에서 주목을 받고 있기는 하지만 실상 사용빈도는 GO쪽이 훨씬 높습니다. RUST가 특정 부분에서 인지도가 상승하고 쓰일거라고는 보지만 C/C++의 대체제 주장은 수긍하기 어려운 부분입니다. 국내 사업은 특성상 RUST가 필요할 정도의 개발이 그렇게 흔하지 않습니다. 기업 대부분이 여전히 백엔드는 JAVA를 더 선호합니다. JAVA로도 충분할 정도의 백엔드가 훨씬 많습니다. 이걸 굳이 RUST로 개발해야할 이유도 없구요. JAVA 라이센스 이슈 때문에 대체제를 찾는 곳도 대부분은 GO쪽으로 더 관심을 가집니다.
그리고, 언어와 보안이 무슨 상관인지 이해하기 힘든 이야기를 하시는데, JAVA가 보안성이 우수하다고 주장했지만 정작 보안이슈 때문에 JAVA사용을 비권장하는 곳도 있습니다. 메모리 이슈 발생한다고 보안 문제가 발생한다는 주장은 억지논리입니다. C/C++/PASCAL 같은 언어가 메모리를 직접 개발자가 관리해야 하기 때문에 휴먼에러가 많이 발생하지만 이게 언어의 문제는 아닙니다. 사람이 따라가지를 못하니 그걸 언어적 차원에서 걸러내자는 시도이기는 하지만 그게 언어 자체의 문제를 이야기하는건 아닙니다.
그리고, SWIFT, KOTLIN같은 이런 트렌드의 언어 사용해보면 장점만 있지는 않습니다. 언어적 차원에서 휴먼에러를 걸러내다보니 불필요할 정도의 강제가 수반됩니다. 이게 생산성을 떨어뜨리기도 하구요.
메모리 이슈는 애플은 명시적 관리에서 오토 가비지 컬렉터로 갔다가 다시 오토 릴리스를 이용하는 방식으로 전환을 했고, MS는 C++CX에서 예전에 DELPHI가 했던 것처럼 컴파일러가 메모리 해제 코드를 자동으로 삽입하는 방식을 쓰기도 했습니다. C++에서는 수년전부터 Transactional Memory개념에 대해 논의가 이루어지고 있습니다. RUST같은 경우는 컴파일러 단계에서 메모리 이슈를 검증하는 방식을 사용합니다. 이건 컴파일러의 정적 분석 기술과 JIT기술이 발전하면서 나온 방식이구요. 또, 새로운 기술이 나온다면 다른 방식의 시도가 이루어 질 겁니다.
애플 SWIFT의 ARC(Automatic Reference Counting)가 휴먼 에러를 모두 해결해주지는 않습니다.
ARC의 특성을 제대로 이해하지 않고 코딩할 경우 참조 문제로 메모리 누수가 발생할 수 있어요.
물론 C/C++ 보다는 대단히 다루기 쉽습니다.
Rust는 휴먼 에러를 잘 잡아주는 대신에, 코딩이 까다롭습니다.
그래서 빠르게 대중화 되는 건 어려울 거라는 사실을 인정할 수 밖에 없지요.
하지만 Rust는 점점 영역을 넓혀가고 있습니다.
리눅스 디바이스 드라이버를 Rust로 작성할 수 있게 하려는 움직임이 있고
안드로이드 AOSP 개발에도 Rust를 지원하려 하고 있습니다.
(둘다 절대로 전면적인 도입은 아님)
언어적 차원에서 휴먼에러를 걸러내다보니 불필요한 정도의 강제가 수반되어서 생산성을 떨어뜨림 -> 이 말은 그냥 해당 언어에 익숙하지 않아서 생기는 문제 같은데요.
@@그루브-i3i그렇게 말하자면 그냥 C언어에 익숙하다면 장땡 아닌가
넘들이 만든 언어 신경쓰지말고 직접만들어서 쓰세요.
생산성은 직접만든 프로그래밍언어가 최고입니다
Rust는 이미 C대체에 실패했다고 보고 있습니다. 나온지가 7년이나 지났고 이미 수많은 논쟁을 통해 대체 해봐야 의미 없다는 의견이 중론이고 확산에도 실팼죠.
그래서 C/C++을 대체할 다른 프로젝트들이 진행되고 있는데 이것 마져 사실 부정적입니다.
C++을 무조건 싫어하는 토발즈가 리눅스에 rust를 도입을 해서 잠시 반짝하긴 했지만.... 현실적으로 rust는 이미 망해있다고 봅니다.
마이크로 소프트 내에서도 C/C++대체를 위한 프로젝트가 진행되고 있는 걸로 아는데 말이죠.
구글에서도 얼마전에 Carbon을 발표했죠. 근데 이것도 어떻게 될지 모르겠습니다.
기본적으로 보안을 위해? 생산성을 위해? 메모리의 동적 할당을 자동으로 관리하고 어쩌고 저쩌고 하는 건 이제 의미가 없죠. C++에서는 이미 smart pointer류가 널리 쓰이고 있어서 수동으로 동적 메모리를 잘하지 않아서 이미 이런 걸로 고통을 받는 개발자는 거의 없다 볼 수 있습니다.
오히려 smart pointer의 편리성과 성능 그리고 포인터의 장점까지 쓸수 있는 상황이 되어서 점점 심각해지는 garbage collection의 고질적 문제들 보다 훨씬 더 좋은 선택이 될 수 있는 상황이 되었죠.
그리고 보안 문제에 고민을 한다는 것은 C언어의 결함이 있어서??? 라기보다는 C언어로 해킹이 가능해서가 아닌가요??
C언어는 포인터로 메모리를 맘대로 억세스가 가능하기 때문에 고도의 해킹 프로그래밍을 작성하기 때문이죠.
다른 managed 언어들은 언어에서 차단해버리지만 C언어는 해커가 맘만 먹는다면 얼마든지 가능하거든요.
그게 문제란 것이지 C언어 자체가 무슨 보안에 결함이 있어서???라고 보기는 힘들다고 봅니다.
형… 저 아저씨 대신에 형이 이 영살 촬영하는게 어때?
잘 읽었었습니다만 그게 바로 언어 문제 아닌가요? 바로 언어자체가 보안에 핵심적인 근본 문제란걸 님께서 제대로 언급하셨네요 ㅎㅎ
와 진짜 잘아신다...
정확히 짚어 주셨네요 그리고 이제 좀 C 와 C++을 따로 분리해 줬으면 좋겠는데 말이죠 C언어와 C++이 주로 사용하는 분야 자체가 완전 달라 진지 꽤 오래전 인데 아직까지 둘을 하나로 묶어서 말하고 심지어 그 둘을 대체? 하겠 다니....... C는 임베디드 쪽에선 독보적 인걸로 알고 있고, C++은 거의 대부분 서버사이드 인데 말이죠...
잘못 알고 계시네요. Rust 의 핵심은 unsafe 한 동작을 효과적으로 격리하고, sound하지 않은 프로그램은 컴파일 타임에 오류를 지적하는 데 있다고 봅니다. 네, 그 raw pointer 가지고 온갖 규격 외 동작 시키는 것들이나 스택 변수 삥땅쳐놓았다가 시스템 폭파시키기, 리소스 락 빼먹고 액세스하다가 터뜨리기 같은 것들이요.
그리고 Rust 에서도 raw pointer 사용 가능합니다. 다만 이게 관리가 C/C++ 보다 훨씬 잘 되는 무언가라는 게 다를 뿐요. 개발자는 unsafe{} 안만 신경 쓰면 되기에 인지 부하가 꽤나 감소합니다.
+ C는 결함 많은 랭기지가 맞습니다. 당장 널 종결 문자열만 봐도 온갖 최적화 이슈와 수 많은 BoF를 끌고 온 주인공이고, sized_free 도 이제야 들어오네 마네 하고 있는 상황인데...
결국 뭘해도 C언어에 파생되서.. 과연 대체가 될련지 진작에 대체언어가 나왔다면 한참전에 나왔겠죠.. 예전에 누가 그랬죠.. 망한다는 C언어 여전히 버티고있는거보면 크크..
나온다고 해도 C언어의 테두리에선 절대 벗어날수 없다는건 누구나 다 아는 사실..
만약 c언어의 실행속도를 앞도적으로 잡아먹는다면 생각다시해볼수도?
결국 다 c의 업그레이드 버전이긴함
C언어보다는 엄연히 말하자면 어셈블러의 테두리에서 벗어나지 못한다고 보면 됨
제발... 학교서 지금 C++배우고 있단 말이당
알아둬서 나쁠거 전혀없음. 열공해라
C++도 못하년서 컴터 학과 다닌다고 하지 말아라
C++ 낭만과 성능 둘 다를 가진 언어입니다!
Rust ownership으로 안정성을 얻게 되어 로켓의 안정성, 자율주행의 무중단 실행 이슈에 더욱 좋은 대안이 될 수 있는데, 영상에서는 로켓에서 C언어 쓰고, 자율중행에서 C언어 쓰니까 Rust로 대체하기는 그렇다는 영상은 완전 Rust의 장점을 반대로 이야기해서 오해를 불러올 수 있는 내용인 것 같습니다.
맞아요 저 분 말이 이상하네요.
오히려 Rust로 대체할 수 있죠.
레거시 프로그램 가지고 수정 안하고 계속 쓰는 상황 때문에 대체 불가하다는 말은 말이 안되는듯요. 은행권 같은 상황도 아니고
@테스트 일부 사람은 예측을 잘못한 것 같네요. 가비지컬렉터라든가 하는거 보면 효율적으로 메모리 관리 못하는데 저라면 당연히 자바로는 임베디드 장악 못할 거라고 생각했었고요.
자바는 메모리 관리를 사람이 안하겠다는 수준으로 나온거고, 러스트는 아예 컴파일 단계에서 엄격하게 관리할 수 있도록 강제하는 규칙을 만들어준거죠. 그래서 안정성이라는 장점을 얘기하는것이고요.
말씀하신 C보다 나은 러스트의 장점은 그 메모리에 대한 접근 관리에서 사람이 할 수 있는 실수를 방지할 수 있다는데 있습니다. 각 MCU개발사들은 레지스터나 메모리에 대한 접근변수들을 사전에 잘 정의만 해주고 컴파일러를 만들어준다면, 문제가 생길 수 있는 메모리 접근을 언어에서 고차원적으로 해결해 줄 수 있는거죠.
@테스트 윈도우즈마저 C.. 그건 러스트가 나오기 전에 윈도우를 만들때 그를 대체할만한 언어가 없어서 그런거지요. 이미 만든 프로그램이 다 C로 되어있다고 대체 못한 다는 말씀은 말이 안되는거죠
네.. 이미 C 많이 사용한다고 대체 못할 이유가 되진 않습니다. 자바는 애초에 비교 대상이 아닌게 메모리, 실행 속도등도 문제고 사용중인 시스템에 jvm이 돌아갈 수 있도록 자바를 깔아야하는데 저장용량, 이식성, 버전 문제 등 다양한 이유로 극한의 자원관리가 필요한 임베디드에서 사용되지 못한거구요 rust의 경우에는 메모리 안정성이 높으면서도 비효율적으로 사용하지 않고 속도도 빠르다보니 넘어가야한다는 말이 나오는겁니다. 그리고 C가 나온게 50년이 넘어갑니다.. 러스트는 그에 비해 관심을 받기 시작한지 얼마 안 되었기 때문에 사용자가 적은것도 당연한거고 그렇기 때문에 차근차근 고쳐 나가야한다는거죠. php를 예시로 들었을때 이 시기에 개발자들에게 코딩하라고 던져 주면 더러운 언어라는 말부터 시작해서 보안이 취약하고 쓸 이유가 전혀 없다는 소리 듣습니다 하지만 그럼에도 아직까지 많이 쓰이고 유지보수 되는게 php입니다. 오래된 언어로 개발된 프로그램이 많은 건 당연한겁니다. 특히나 운영체제 같은 경우에는 오랜 시간을 거쳐서 안정화를 거치고 내놓습니다. 당장에 더 좋은 언어가 나왔다고 하더라도 기존에 쓰던걸 버릴수도 없고 기존것도 유지보수하면서 새로운 걸 개발해야하는데 더 많은 돈과 시간이 들어갈 수 밖에 없죠.
오류는 어디에서 오는가 메모리 겹치는 순간 스죠 우주공간으로 쏴버렸는데, 시속 200키로로 달리고 있는데
딱 오류 납니다. 그럼 다시 쏘면 되고 차탄 사람은 죽으면 그만인것을.. 이게 C고 Rust는 안서요. 죽을일도 없을테고,
프로그래머의 실력차가 나는것도 겹겹이 쌓여있는 프로그램에서 메모리 겹치지 않게 전에 만들어 놓은 메모리 요리조리 피해가면서 만들어야하기 때문인데, Rust는 개발 방법론으로 메모리 겹침을 해결한거라서
신석기 구석기 청동기 철기 구분하듯이 우리가 사용하는 무기가 역사적 구분 바뀔정도로 C의 시대에서 Rust 의 시대로 바뀐겁니다. 라고 말할 수 있을 정도의 변화가 있는 것입니다.우리나라 전자정부 프레임워크도 이제 java spring 그만하고 속도 빠르고 안정적인 Rust 로 바꿔야하지 않을까도 생각합니다.
속도 안정성 그리고 전기도 적게 먹어서 Rust 프로그램을 사용하면 환경보호에도 일조하는 샘입니다.
시간 나면 무조건 Rust 공부하세요. Front Back 모두 Rust OS, IOT 모두 Rust 로 변경됩니다.
JAVASCRIPT 도 AR VR 문제로 webassembly 대체하면서 Rust로 변경됩니다.
시대가 바뀐겁니다. 현업은 어쩔수 없겠지만. 새프로젝트나 학생은 무조건 RUST 하세요.
메모리 관리의 혁명이 일어난겁니다. 여러분이 왜 프로그램 하면 어~하는지 아세요.
메모리 관리가힘들어서 그랬던거에요. Rust 때문에 메모리 문제가 해결되어서 심지어 OS가 새로나올 판이
만들어진겁니다. 지금 사용량이 많은 프로그램들은 죄다 Rust로 바꾸고 있어요.
질문이 틀린 겁니다. Rust로 C와 C++ 바꿀수있을까가 아니라 아직도 Rust로 안바꾸고 뭐하고있냐가 시대에 맞는 질문이 아닐까요!
c++이 나의 주력이구 싶은 언어인데.. 대체 불가능 해야되ㅛ
Rust는 MS에서나... 다른데선 그닥... 그네들이 충분히 입맛에 맞는 C/C++ 경력자들로 모두 채우기도 어렵고, 그에 따른 실수는 치명적일때도 있는데다가, 짧거나 서버 백엔드에서 돌릴 코드를 굳이.... 하는 입장에서 차라리 새 언어를 (Rust) 쓰자는 입장에서 주장하는 얘기라고 생각합니다. 다른 산업계에선 이걸 굳이... ?? 학원에서야 좋다면서 이걸 가르칠 일이(?) 있을수도 있겠지만 이게 전망 좋다고 약팔이 하기에도 나온지가 꽤 됐죠?. 어쨋건 향후 사용 전망에 부정적임. 동의하기 힘듦.
C,C++ 자체를 메모리릭이 발생하지않게 수정보완 하는건 어려운건가요?
초보라 이런것이 궁금하네요.
unique_ptr, 등을 비롯한 스마트 포인터를 쓰면 됩니다. 그런데 언어 디자인 상 그것을 강제하지는 않습니다.
시큐어코딩이라는 기법이있습니다
모듀가 실수없이 수행할수있다면 시큐어코딩만으로 충분히안전한 개발이가능합니다
근데 한명만알아서 될것도아니고 필연적으로 메모리직접 액세스걸어야하는경우도 있습니다.
이러는도중에 시큐어코딩을알더라도 실수를하는경우가있구여....
하지만러스트는 이런면에서 제어에 문제가발생하면 컴파일단에서 걸러내는데 특화되어있죠 그뿐만아니라 소유개념을넣어서 함수간 이동시 또한 철저하게 검사를해서 메모리안정성 문제를해결하죠
러스트 언어순위 1위 출처가 궁금하내요.
rust가 너무 powerful해서 사라질리는 없다. (rust의 소유권 개념을 탑재한 다른 언어가 생기지 않는 이상)
하지만 개발자 양성하는데 너무 진입장벽이 높고, 아마도 최소 대리급 이상 개발자을 뽑을 수 밖에 없을 것이다. 그만큼 개발하는데 단가가 올라간다.
한동안 C++, C, C#, java, rust(&go), python, kotlin, swift같은 언어의 춘추전국시대를 피하기 어려울 거 같다.
결과물이 나온다면 안전성 만큼은 보증 가능하죠.@IlllIlIlllIIIllIl
C# 이 등장 했을때도 같은 주장을 했었지.
하지만 오히려 망한건 C#임.
우리나라에서 ? 점유율 낮으면 망한거임??
@@sungwonchang 네.
ㅋㅋ 망한논리는 설득력이 없네요
유럽에서는 자바를 압도적으로 이기고있네
@테스트 c#출시때 c, c++ 대체한다는 문서좀??
C#은 다른 객체지향언어를 대체한게 아닌가요?
제가 있는 산업현장에서는 아직 백앤드는 c++ 로 되어있내요. Gui는 c#이지만요
오 C++이랑 C#배웟는데
거기 어디 회사에용? 지원하고싶어요.
설비 업계선 많이들 그렇죠
Rust의 미래가 기대되네요.
이분 좀 설명 하는거들어보니 그닥 코딩 많이해본 전문가가 아닌거같은데...
시대의 조류인 것인가?
cg인줄알았네요
이 말을 c#이 어이없어 합니다.
학생들이랑 학교에 돈 주고 러스트 무료로 배우게 하면 바뀌것지
산업현장에서 다 c c++ 쓰고 있어서 안바뀝니다. 취업후에 다시 C배워야되요. 유지보수할 소스가 기존 프로젝트가 전부 C로 되어있으니.
@@인트-u6e 아 그렇군요 ㅠㅠ C빼먹엇는데... 내년에 재수강 해야겟네여 ㅠㅠ
@@Snowflake_tv 아. 요지는 회사에서 기존 사용하던 툴.프로젝트들이 시용하던 언어를 대부분 따라간다는 겁니다. Java를 썻다면 java를 쓰는거고. 신규 언어를 작용하려고 하면 아무래도 기존 개발자들이 그걸 모르기도 하고 그렇기에 신규프로젝트에 적용하기는 큰 모험일 수 있죠.
겸용도 힘든데 대체는 ㅋㅋ...
GPT
질문 :rust 와 C 또는 CPP 중에 뭐가 미래에 전망이 높다고 생각되니?
Rust와 C/C++은 모두 강력한 시스템 프로그래밍 언어로서 널리 사용되고 있는 언어입니다. 하지만 Rust는 현대적인 언어로서의 특징과 안전성, 병행성, 메모리 안전성 등의 강점을 갖추고 있어 미래에 전망이 높다고 평가됩니다. 이에는 다음과 같은 이유들이 있습니다:
안전성: Rust는 메모리 안전성을 강제하는 고유한 소유권 시스템과 러스트 컴파일러의 엄격한 정적 분석을 통해 메모리 오류, 데이터 경쟁 등의 버그를 사전에 방지할 수 있습니다. 이는 소프트웨어의 안정성과 신뢰성을 높일 수 있으며, 보안 취약점을 최소화하는 데 도움이 됩니다.
병행성: Rust는 메모리 안전성을 유지하면서도 효과적인 병행성 프로그래밍을 지원합니다. 고유한 소유권 시스템과 병행성 패턴을 통해 경합 조건 및 데드락과 같은 문제를 최소화할 수 있습니다.
생산성: Rust는 현대적인 문법과 기능을 제공하여 개발자의 생산성을 높입니다. 잠재적인 버그를 사전에 잡아내는 정적 분석 도구와 함께, 풍부한 도구 생태계와 다양한 라이브러리가 제공되어 개발을 용이하게 합니다.
커뮤니티와 생태계: Rust는 점점 성장하는 활발한 커뮤니티와 생태계를 가지고 있습니다. Rust 개발자 커뮤니티의 지속적인 기여와 업계에서의 관심이 매년 증가하고 있으며, Rust를 사용하는 프로젝트와 도구의 수도 증가하고 있습니다.
C/C++은 여전히 많은 소프트웨어 시스템에서 사용되고 있으며, 특히 저수준 시스템 프로그래밍이 필요한 영역에서는 여전히 중요한 역할을 합니다. 그러나 Rust는 현대적인 시스템 프로그래밍 언어로서 더 나은 안전성과 생산성을 제공하므로, 앞으로의 전망이 높아질 것으로 예상됩니다.
러알못들아 러스트가 압도적이다.
그냥 바꿔라
발음이 심각하네
이미 처먹고 있는 점유율은 못뺐지
rust가 개발자 선호 1위라는 언어라는 엉뚱한 이야기에 웃음이 피식.
설문조사에 따르면 러스트가 개발자 선호 1위 언어인건 사실임 ㅋㅋㅋㅋ 피식은 뭔 피식 ㅋㅋㅋ C/C++를 완벽히 대체하기에는 너무 미성숙한 개발환경이라서 그렇지 지금 Go로 넘어가던 회사들도 Rust로 넘어가는 마당에 무슨 피식
웃기고....메모리버그는 니가 포인터를 못써서 그런가부지 왜 언어탓을하고 그러냐
MS 개발자들이 윈도우즈 메모리 버그 70% 만들어냈지요. MS C++개발자의 발톱의 때도 못한 님이 더 잘할 가능성은 없다고 보여지네요. 만약 메모리 버그를 만든적이 없다면 님은 그만큼 쉬운 프로젝트만 했다는 방증입니다. 모던언어들은 개발자의 실수를 미연에 방지하는 기술이 필수적입니다. 구태인 C/C++ 밥통 붙들어 매고 싶은 마음은 이해하지만..ㅎㅎ
너무 단순한 지적인것 같네요. 언어를 하나만 알면 그런 생각을 가질수도 있지요.
희대의 개소리라 생각함
단언컨대 100년 안에 교체는 불가하다 또는 그 이상이 걸릴 수도 있다고 생각한다
100년은 뭔..
100년이면 프로그래밍 역사와 비슷한 수준인데 그 안에 안바뀔리가..ㅋㅋ
100년이면 전세계 프로그래머들 95퍼 없어진다.