문자열부터 스트링, 스트링 리터럴, 스트링 슬라이스 세가지라 헷갈리던데. 에러처리를 위한 result나 널 대신 옵셔널을 일일이 매치로 다 처리하는것도 피곤하고. 다른 언어라면 그냥 두루뭉술하게 추상화 해주는 부분을 다 꼬치꼬치 따져서 피곤함. - dc App
익명(110.8)2025-02-22 21:25
답글
귀찮으면 unwrap 쓰면 다른 언어랑 똑같이 쓸 수 있고, Result/Option은 and_then, map_err, map_or_else 같은 메소드덕분에 편하면 편했지 더 귀찮다고 생각은 안해봤는데
익명(220.94)2025-02-22 21:43
답글
무조건 패닉으로 프로그램 죽일거면 상관 없는데 어디선가 try catch 같은걸 해야할 경우 러스트는 try catch가 없어서 그 모든 함수의 호출 스택을 다 result 반환하도록 변경해야한다는 점이 스트레스다. 명시적으로 함수가 에러가 날 가능성이 있음을 명확히 표시해준다는 점은 훗날 유지보수에 더 도움이 되겠지만 초반에 빠르게 개발할 때 함수 시그니쳐를 다 바꿔줘야하는게 귀찮았음. - dc App
익명(110.8)2025-02-22 22:13
답글
그거 anyhow 쓰면 훨씬 편해짐
익명(220.94)2025-02-22 22:59
답글
라이브러리 갖다쓰기 싫다는거 같은데 그럴거면 glibc 도 쓰지말고 리눅스도 쓰지마셈 - dc App
익명(220.87)2025-02-23 00:28
C나 C++ 사용자라면 오히려 쉬운 것이 맞음
C는 이제 가물가물한데 C의 char*가 가리키는 것이 문자열 리터럴일 때는 러스트의 &'static str, 배열은 &mut str이나 &str, malloc으로 할당한 메모리는 String하고 비슷할 것임
여기에 더해서 일부러 unsafe를 켠 것이 아니라면 UTF8라고 가정하고 코드를 작성할 수 있음
러스트의 엄밀한 문법하고 컴파일러가 실수를 크게 줄여줌
반대로 말하면 C나 C++수준의 접근이 필요하지 않은 다수의 환경에서는 복잡하고 어렵기만 할 것임
컴파일이 어려움
명시적 라이프타임부터
immutable인거만 쓰면 쉬움
문자열부터 스트링, 스트링 리터럴, 스트링 슬라이스 세가지라 헷갈리던데. 에러처리를 위한 result나 널 대신 옵셔널을 일일이 매치로 다 처리하는것도 피곤하고. 다른 언어라면 그냥 두루뭉술하게 추상화 해주는 부분을 다 꼬치꼬치 따져서 피곤함. - dc App
귀찮으면 unwrap 쓰면 다른 언어랑 똑같이 쓸 수 있고, Result/Option은 and_then, map_err, map_or_else 같은 메소드덕분에 편하면 편했지 더 귀찮다고 생각은 안해봤는데
무조건 패닉으로 프로그램 죽일거면 상관 없는데 어디선가 try catch 같은걸 해야할 경우 러스트는 try catch가 없어서 그 모든 함수의 호출 스택을 다 result 반환하도록 변경해야한다는 점이 스트레스다. 명시적으로 함수가 에러가 날 가능성이 있음을 명확히 표시해준다는 점은 훗날 유지보수에 더 도움이 되겠지만 초반에 빠르게 개발할 때 함수 시그니쳐를 다 바꿔줘야하는게 귀찮았음. - dc App
그거 anyhow 쓰면 훨씬 편해짐
라이브러리 갖다쓰기 싫다는거 같은데 그럴거면 glibc 도 쓰지말고 리눅스도 쓰지마셈 - dc App
C나 C++ 사용자라면 오히려 쉬운 것이 맞음 C는 이제 가물가물한데 C의 char*가 가리키는 것이 문자열 리터럴일 때는 러스트의 &'static str, 배열은 &mut str이나 &str, malloc으로 할당한 메모리는 String하고 비슷할 것임 여기에 더해서 일부러 unsafe를 켠 것이 아니라면 UTF8라고 가정하고 코드를 작성할 수 있음 러스트의 엄밀한 문법하고 컴파일러가 실수를 크게 줄여줌 반대로 말하면 C나 C++수준의 접근이 필요하지 않은 다수의 환경에서는 복잡하고 어렵기만 할 것임