보통 러스트 홍보 글에 use-after-move를 방지해준다는 내용을 많이 언급함
근데 이건 clang-tidy를 통해서 미리 잡아낼 수 있는 오류임
이런 식으로.
요즘은 C++, JS, 파이썬 같은 상대적으로 유연한 언어에 붙일 수 있는 린터들이 많이 나오더라고
그래서 궁금해짐. 과연 러스트가 제공하는 안정성은 C++에 린터를 달아서는 도달할 수 없는 영역임?
그리고 러스트 찍먹하다가 정 떨어진 부분이 있는데, 언어가 전반적으로 verbose하게 느껴짐.
스트링 리터럴 (내가 이해한 바가 맞다면 &str이 아니라 str이라서 그렇다고 하던데) 사용하려면 String::from이나 .into() 또는 .to_string() 말고는 방법이 없음?
나름 모던하다는 언어 튜토리얼에 저렇게 써있는거 보니까 이게 맞나 싶더라.
C++에서도 auto a = std::string("foo") 대신에 auto b = "foo"s 처럼 쓰는게 가능함.
예외 처리가 아니더라도 코드가 장황하게 느껴지는데 찾아보면 이건 나만의 생각은 아니라고 보임.
이것에 대한 해결책이나 해결하기 위한 계획이 있음?
린터는 결국 추가적으로 설정을 하는거고, 강제가 아니여서 그럼 - dc App
언어레벨에서 강제로 잡아버리면 그런 문제를 고민할 필요가 없잖아 - dc App
나 혼자서는 린터든 뭐든 쓰겠지만 내가 보게/쓰게 될 남이 쓴 코드를 신뢰할 수 없다 라고 이해했는데 맞음? 린터 성능이 아무리 좋아도 강제가 아니라는 점은 확실히 문제긴 하겠네
프로젝트 마다 린터 세팅이 다를탠데 그러면 라이브러리 가져다 쓸때도 전부 고민해야 할거고, 불편함을 감수하고 안정성을 얻은게 러스트인데 편하려면 고랭이나 다른언어를 찾아야 한다고 생각함 - dc App
ㄴ ㅇㄱㅁㄷ
정적 체크로는 잡을 수 없는 버그들도 많음 물론 러스트도 unsafe 쓰면 버그 나지 않냐 말하면 할말은 없긴 하지만... - dc App
예를 들어 인스턴스 하나를 두개 이상의 스래드에서 참조하다 한 스레드에서 free 하는 경우도 저 린터가 막을 수 있을까? - dc App
리터럴은 'static &str로 사용가능한데
그런걸로 치면 C로도 다 가능함 ㅋㅋㅋ 어차피 다 C 베이스로해서 만들어진거잖아 걍 각 언어마다 만들어진 의도가 있고 그 의도에 맞춰서 쓰는거지 그외에 딱히 따져야할게 있나 싶음
to_string은 메모리 allocation 하기땜에 명시적인게 좋은건데
그리고 cargo 편해 ㅎㅎ
린터로 다 잡을 수 있으면 얼마나 좋겠냐마는... 편의성하고 안전성, 성능 이 세마리 토끼를 동시에 잡을 수는 없다고 보면 돼. 그 사이 어딘가에서 트레이드오프인거고 Rust는 코드가 좀 장황해지더라도 안전과 성능을 택한거지. 대신 현대 프로그래밍 언어학의 성과를 이것저것 도입해서 그 번잡성이 사람이 감당가능한 선에서 유지되도록 하고자 한 거고
그 린터가 정적으로 100% 잡아낸다고? ㅋㅋ 그러면 러스트 나오지도 않았을거다. 100% 정적체크가 되는 것과 99%가 되는 것은 완전히 달라. 100% 보장이 되면 그 위에서 신세계가 열려릴 수 있어. 특히 비용 측면에서. 구글 마소 인텔 등등이 참여한 C++ 커미티에서 러스트처럼 만들어볼려고 온갖 발악을 했는데 하위호환성 지키면서 러스트처럼은 못한다고 이미 결론나고 그 결론난 뒤에 C++ 개같이 버리고 이제 다들 러스트 대동단결하는 중이다. 그 회사들이 괜히 러스트 빠는게 아님.