:: 게시판
:: 이전 게시판
|
- 자유 주제로 사용할 수 있는 게시판입니다.
- 토론 게시판의 용도를 겸합니다.
통합규정 1.3 이용안내 인용"Pgr은 '명문화된 삭제규정'이 반드시 필요하지 않은 분을 환영합니다.법 없이도 사는 사람, 남에게 상처를 주지 않으면서 같이 이야기 나눌 수 있는 분이면 좋겠습니다."
15/05/15 15:37
전체적으로 C/C++랑 매우 유사합니다. 모토를 한 문장으로 나타내면 '가비지 컬렉션 없는 안전한 메모리 관리'고요. 혹시 C++를 아신다면 C++에서 unique_ptr, shared_ptr만 남겨놨다고 보시면 됩니다.
여기에 함수형 언어 개념들이 짬뽕되어 있어서 하이레벨의 코드를 작성하기에도 용이합니다. 단, 가비지 컬렉션이 있는 언어들과 달리 메모리 관리를 직접 해야 하므로 불편합니다. 하지만 이 경우에도 C++처럼 메모리 관리를 실패해서 segmentation fault가 난다든지 그러지는 않습니다. 컴파일러 오류가 나죠. 따라서 주된 타깃은, 성능을 최우선으로 잡아야 하기에 가비지 컬렉션을 이용할 수 없는 게임 프로그래밍, 커널 드라이버 같은 저수준 프로그래밍, 동시성 서버 프로그래밍 등이 될 것 같습니다. 대부분 C++이 주로 쓰이는 분야들이죠. 저는 웹 개발을 러스트로 해 보려고 시도하는 중입니다만 역시 자바스크립트나 파이선만큼 편하진 않습니다.
15/05/15 15:43
아, 그리고 깜빡 했는데, 러스트는 모질라의 프로젝트이고, 이미 러스트로 웹 브라우저를 만드는 중입니다.
https://github.com/servo/servo 사실 모질라가 러스트를 만든 것도 C++가 성능이 빨라서 어쩔 수 없이 쓰긴 하지만, 제대로 사용하기가 너무 어렵다는 점에서 출발했거든요. 파이어폭스가 C++로 작성되어 있으니까 모질라 입장에서는 대체재가 절실한 상황이었죠. 올해 말까지 파이어폭스에 러스트 코드가 들어갈 예정이라고 하니, 러스트 언어 자체의 성공과 관련 없이 앞으로 모질라쪽 프로젝트에서는 꾸준히 쓰이게 되지 않을까 싶습니다. 그래서 저도 좀 낙관적입니다. 아무리 망해도 모질라는 쓸 테니...
15/05/15 16:54
궁금한게 있는데요
현재 파폭의 C++코드사용비율이 어느정도 되는지요? 그걸 러스트가 다 대체 가능한건가요? 그리고 컴파일러 에러가 나는 언어와 런타임에러가 나는 언어를 각각 컴파일한 후 링크할 때 에러가 나지는 않나요? 프로그래밍언어 못알 입니다
15/05/15 17:09
https://github.com/mozilla/gecko-dev 에 들어가서 윗쪽의 알록달록한 막대를 눌러 보면 언어별 코드 줄 수가 보입니다. C++ 40%, 자바스크립트 20% 정도군요.
대체할 수 있는지 여부만 말한다면, 물론 가능합니다. 그러나 늘 그렇듯, 시간과 돈의 문제죠. 파이어폭스 코드가 몇십만 줄일 텐데, 이것을 일시에 러스트도 재작성하는 것은 너무 어렵습니다. 지금 모질라 리서치의 계획은 몇몇 부품만 시험 삼아 러스트로 다시 짜 보고, 잘 되면 다른 부분도 해 보고, 이렇게 할 생각인 것 같습니다. 위에서 말한 Servo는 이와 다르게 아예 바닥부터 다시 짜는 실험용 웹 브라우저입니다. 이미 파이어폭스에 비해 2-3배 빠르다고 하는군요. 이게 실험으로 남을지, 아니면 차세대 웹 브라우저로서 모질라의 주력이 될지는 아직 모르고요. 컴파일러 오류가 나는 언어는 다르게 말하면 런타임 오류가 나는 언어의 부분 집합이라고 할 수 있습니다. 전자의 모든 코드는 후자에서 실행 가능하지만, 후자의 모든 코드가 전자에서 실행할 수 있는 것은 아니죠. 따라서 링크 시에 오류가 나지는 않습니다. 최종 결과물은 똑같으니까요. 러스트의 목표는 프로그래머의 자유를 제약해서 안전한 프로그래밍을 이루겠다는 것입니다. 따라서 C++ 코드를 '그대로' 가져다 쓸 수는 없습니다. 그러면 그냥 C++니까요. 컴파일러의 엄격한 훈육을 받은 코드만 러스트에서 쓸 수 있다고 생각하시면 되겠습니디.
15/05/15 20:45
그렇군요. 왜 만드나 라는 생각이 들어서 여쭤본겁니다. 제가 궁금한 점을 다 말씀해주셨습니다. 기존의 언어부분까 마법의 효과가 발생하는건 아니군요.
자유를 희생하여 에러를 사전에 방비하는 기존 언어의 보완판인데 장래에는 대체제가 되기를 희망하는 언어이다 라고 말할 수 있겠네요. 나중에 한번 공부해보고 싶습니다.
15/05/15 22:37
그렇습니다. 러스트는 결코 마법의 도구가 아니에요. 러스트로 코딩하면 기존 언어에 비해 엄청 불편한 면도 많습니다. 컴파일러가 특정 방식으로 짜도록 강요하기 때문이죠. 하지만 일단 프로그램을 완성하고 나면 C/C++에 비해 런타임에 터질 우려는 상당히 줄어드는 게 매력 포인트죠.
따라서 관건은 '기존 프로그래머들이 불편함을 감수하고서라도 안전함에 신경을 쓸 것인가?'에 달려 있다고 볼 수 있겠습니다. 러스트에 비관적인 사람들은 '기존에도 안전함을 강조한 언어들은 있었지만, 프로그래머들 그리고 기업들은 안전함보다는 당장의 개발 편의성을 보기 때문에, 대부분 주류로 편입되는 데 실패했다'고 말하곤 합니다. 저도 만일 러스트가 실패한다면 너무 불편해서일 거라고 보고 있습니다. 하지만 재밌게도, 러스트는 기존의 안전함을 강조한 언어들 [중에서는] 가장 쓰기 쉬운 편입니다. 따라서 '이번에는 진입 장벽이 충분히 낮아졌는가?'가 성공 여부를 결정할 거라고 생각해요.
15/05/15 16:37
지방은 닥버로우하고 있어야겠습니다, 어흑.
- 언어 자체는 관심이 가네요. 어자피 중딩때 C++ 독학으로 시작한 프로그래머 인생인데 비슷한 계통 언어 하나 더 한다고 해서 손해는 안 보겠군요... 혹시 관련 링크들 제공을 부탁드려도 될까요? 쪽지든 리플이든 상관없습니다.
15/05/15 16:40
저도 대전 사는데 올라갑니다! 하하. 하지만 이게 지방 사시는 분들을 오시게 할 정도로 영양가 있는 행사는 아닐 것 같아서 권하기는 좀 주저스럽네요! 그래도 러스트에 관심 주셔서 고맙습니다.
본문에서도 썼지만 1.0 출시를 맞아 언어가 안정화되면서 슬슬 사람들이 문서화 작업에 착수하고 있습니다. 요즘 이 문서들을 한 곳에 모으는 작업을 하고 있는데요. https://github.com/ctjhoa/rust-learning 에서 러스트를 배우는 데 도움이 될 만한 링크들을 보실 수 있습니다. 일단 가장 첫 링크인 공식 튜토리얼( http://doc.rust-lang.org/nightly/book/ )부터 보시는 것이 좋을 것 같군요. 또한 러스트 관련 글들은 레딧 소모임( http://www.reddit.com/r/rust )에 주로 올라옵니다. 이걸 구독하셔도 괜찮겠지요.
15/05/15 16:46
........저도 대전이라 엄청 찔리는군요;;;
근데 가봤자 아예 써본적도 없어서 대화에 끼지도 못할꺼 같으니 이번은 패스해야겠습니다.(.......사실은 생활비 바닥나서 월급날까지 점심 제외 라면 한개로 때워야 하는 인생이라;;; orz.) 링크는 감사합니다. 퇴근해서 한번 쭉 훝어봐야겠네요.
15/05/15 16:53
지난번 올려주신 재미있는 러스트 글부터 관심있게 읽고 있습니다.
테스트좀 해보려니까 최근 릴리즈에서 Cargo 쓸때 버그가 발생하는것 같더라고요. 도큐먼트도 아직 만들어가는 단계이고.... 그래도 새로운 언어의 시작에 개국공신(?) 처럼 함께하는것은 좋은 경험인것 같네요.
15/05/15 17:17
허, cargo에 버그가 있다면 그건 큰일입니다. 괜찮으시다면 내일 나올 1.0에서도 버그가 발생하는지 확인해 보시고, 여전하다면 저에게 버그를 알려주신다면 제가 신고하도록 하겠습니다. 아니면 직접 신소해 주시면 더욱 좋고요!
러스트가 성공할지 안 할지 아무도 모르지만 역사적인 순간(?!)에 같이 한다는 것 자체만으로도 꿀잼입니다. 기여자 목록에 이름도 남기고요. 흐흐
15/05/15 16:58
랜덤여신님 글 보고 며칠 전에 Cargo로 첫 프로젝트 생성했습니다! 공부 할 시간이 많이 안 나고 모임은 가봐야 알아들을 것 같지도 않지만 틈틈이 해보려고요. 하다보면 언젠가는 러스트로 임베디드 할 수 있는 날도 오나요?
15/05/15 17:13
이미 ARM 보드에 러스트를 올리신 분들이 계십니다. 오늘은 플레이스테이션 1에 러스트 올리신 분도 나왔네요. :-)
https://barosl.com/up/raw/373/psx-rust.png 러스트는 ARM 타깃을 지원하기 때문에 웬만한 범용 임베디드 장치에는 별 고민 없이 올릴 수 있습니다. 안드로이드 같은 경우에는 공식 지원 타깃입니다. 그러나, 상당수의 특수 목적 임베디드 보드들은 제조사가 C 컴파일러만 제공한다든지 하는 경우가 많아서 그런 곳은 어렵지요.
15/05/16 01:26
훨씬 어렵습니다. 러스트는 기계와 가까운 언어입니다. CPU나 메모리 구조에 대해 어느 정도 지식이 있어야 제대로 쓸 수 있지요. 반면에 파이선은 훨씬 높은 수준에서 움직이죠. 러스트 난이도는 C/C++와 비슷한 정도라고 생각하시면 됩니다.
15/05/16 01:31
예전에 gc없는 메모리 관리에 관심이 가서 흥미롭게 봤었는데 이번에 1.0 출시된다길래, rust 깔고 sublime text에 환경 세팅하고 게임 개발자라 게임 샘플을 몇 개 다운 받아서 컴파일을 해봤는데 (depedency에 대해 알아서 다운로드 해주고 컴파일 해주는 cargo는 깔끔하네요.) 이글에서 쓰신것처럼 하위호환 문제로 결국 최종적으로 컴파일 되는 것이 하나도 없네요. 현재 버전 컴파일러에서 컴파일되고 잘 동작하는 gui 샘플은 없을까요.
그외에 몇 개 더 gui 받아봤는데 역시나... 하위호환 문제로 1.0 릴리즈와 더불어 컴파일/실행이 잘되는 어플리케이션 리스트가 필요해보입니다.
15/05/16 02:00
슬프게도 GUI가 꽤나 어려운 분야라서, 당분간 러스트에서 깔끔하고 멋진 GUI를 볼 수 있을 것 같진 않습니다. 일단 awesome-rust에도 나와 있듯이 현재 컴파일이 되는 GTK 바인딩이 있긴 한데, 이게 윈도에서도 동작하는지는 또 다른 문제거든요. 높은 확률로 리눅스와 OS X에서만 제대로 동작할 가능성이 높습니다.
투박한 GUI라도 좋으니 뭐라도 표시해보고 싶으시다면 conrod( https://github.com/PistonDevelopers/conrod )는 어떠신가요. OpenGL/SDL 위에 자체 GUI 위젯을 그리는 건데... 당연히 네이티브는 아니지만 바인딩이 아닌 순수 러스트 솔루션이라면 이 정도가 한계일 것 같네요. 사실 저는 GUI 프로그래밍은 그냥 플랫폼 네이티브로 하는 게 가장 깔끔하다고 생각합니다. OS X에서는 오브젝티브 C, 윈도에서는 C#, 리눅스에서는... 음... 뭘로 하지..? 아마도 Qt? 뭐 이렇게요. 자체 GUI 솔루션이 미려하고 예쁜 걸 본 적이 없어서요. 아니면... 웹을 쓰거나요! 로컬 웹 서버 돌리고 그걸 GUI처럼 쓰는... 예전의 구글 데스크톱 검색처럼 말입니다. 러스트로 작성된 웹 서버는 이미 있기 때문에 이건 쉽게 가능합니다. 크로스 플랫폼을 해야 한다면 이것도 괜찮은 선택이죠. 저 자신이 상당 부분 웹 개발자이기 때문에, 어글리하긴 하지만 만일 앞으로 GUI 프로그래밍을 해야 할 일이 있으면 이렇게 할 확률이 높을 것 같습니다... 흑흑
15/05/16 02:21
sdl2는 현 시점에서 잘되네요. 10여개 받아서 처음로 컴파일과 실행이 되는 프로젝트네요 !
https://github.com/AngryLawyer/rust-sdl2
15/05/16 02:25
다행입니다. :-) 혹시 게임을 만드실 생각이라면 'piston'이라는 게임 엔진이 있으니 그걸 사용해 보세요.
http://www.piston.rs/ 여기서 비주얼 스튜디오용 러스트 플러그인도 만듭니다.
15/05/16 02:33
사실 처음 rust 설치하고 한 일이 piston lib 페이지가서 'games made with piston'링크 가서 게임을 하나씩 차례대로 받아봤는데,
컴파일조차 되는게 하나도 없더라구요. ...
15/05/16 02:38
흐흐 그렇군요. 2048 같은 경우 2개월 전에 마지막으로 수정했는데, 2개월이면 러스트 기준으로는 이미 고대라서...
그런데 다른 게임(또는 패키지)들은 컴파일이 될 수도 있어 보입니다. 사실 이게 비밀이 있는데, 스테이블 버전에는 나이틀리 버전의 기능 중 '안정(stable)'으로 표시된 것만 들어갑니다. 그런데 지금까지 대부분의 러스트 프로젝트들은 나이틀리 버전을 기준으로 만들어졌기 때문에 아직 1.0에서도 컴파일이 되도록 업데이트하지 않은 (또는, 나이틀리 버전에만 있는 기능들을 써서 1.0 버전으로 맞출 수 없는) 패키지들은 나이틀리 컴파일러를 써야 제대로 동작해요. 정 안 된다면 나이틀리를 쓰시는 것도 하나의 수단입니다. 다만 모두가 나이틀리를 쓰게 되면 스테이블의 존재 의의가 없어져버리니까 가급적 1.0을 써야 하는 게 맞지만요.
15/05/16 02:59
안그래도 unstable feature ... 나오면서 에러룰 뿜길래 nightly 버전을 설치중입니다. 프로그램마다 사용하는 library 별로 버전이 달라 지옥을 맛볼 때 어떤 언어에서는 라이브러리별로 버전 세팅을 간단히 변경하는 식으로 이를 피했는데, 얘도 Python 처럼 c:/python25, c:/python26 c:/python27 같이 앞으로 관리 될 예정일까요.
15/05/16 03:04
제 예상으로 러스트는 파이선보다는 하위 호환성이 더 중대하게 관리될 것 같습니다. 러스트 1.6에서 돌아가는 프로그램은 '거의' 예외 없이 러스트 1.7에서도 돌아갈 수 있어야 합니다. 그래서 안정 버전에 편입되기 전에 온갖 실험을 할 수 있도록 나이틀리를 따로 두는 것이고요.
러스트 2.0이 나오면 그때서야 비로소 중대한 하위 호환성 파괴를 저지를 것이라고 예상되는데, 이 경우에는 Cargo가 처리하는 게 좋아 보입니다. 말씀하신대로 패키지별로 이 패키지는 러스트 1.x을 쓴다, 러스트 2.x를 정해둘 수 있겠죠. 러스트 2.0이 나오려면 최소 5년(어쩌면 10년?)은 더 필요해 보이니 아직까지 먼 미래의 일이긴 합니다. :-)
15/05/16 03:16
제가 글을 좀 모호하게 썼군요. 여기서 토론하기는 약간 어긋난 주제이긴 하지만요.
보통 프로그램처럼 rust1.1(nightly)를 설치하려니까 아예 다른 디렉토리로 설치가 되길래 이러면 컴파일을 하는 유저가 명시적으로 다른 디렉토리에 설치된 컴파일러를 지정하여 컴파일을 명령내려야 하니까요. 가령 cargo.toml 안에서, rustc = 1.1 처럼 컴파일러 버전을 지정하면 컴파일러를 잘못 선택한 유저에게 엉뚱한 장문의 에러 메세지대신에 단순히 컴파일러가 없다는 에러 메세지를 출력할 수 있겠죠. 그리고 rust 1.2에서 완벽하게 1.1과 하위호환이 된다면 1.1 없이도 에러 없이 1.2 컴파일러로 컴파일 해주면 되구요. 막 개발중인 언어를 사용하다보면 흔히 생기는 문제라 일종의 푸념(?) 섞인 내용이긴 하네요.
15/05/16 03:18
아아, 기본 설치 경로가 이미 다른 게 문제군요. Cargo에 rustc 경로를 지정하는 기능이 있었나 모르겠네요. 아마 지금은 그냥 PATH에서 rustc 보고 실행할 것 같아서... 이 부분은 버그 보고를 해 보는 게 좋을 것 같습니다.
15/05/16 03:05
http://i.imgur.com/e3ESeUR.png
old_io 라는 이름을 보니 오늘 이 전투는 여기서 물러나는게 현명해보이는군요. 오늘은 여기서 후퇴합니다.
15/05/16 03:08
껄껄 old_io면 진짜로 고대 프로젝트군요. 그래 봤자 3개월 전이지만 (..)
러스트에 관심 가져 주셔서 고맙습니다. 들어가세요. (_ _)
15/05/16 03:10
러스트 팀에서 1.0에서 잘 돌아가는 패키지 목록을 발표했네요. 이름만 나와 있고 어떤 패키지인지 설명이 없어서 좀 아쉽지만 목록만 보기에는 좋아 보입니다.
https://gist.github.com/brson/fdad02b569bce2201d6e
15/05/16 02:04
http://blog.rust-lang.org/2015/05/15/Rust-1.0.html
1.0 발표! 제 이름도 있네요. 껄껄 Barosl Lee <vcs@barosl.com>
|