러스트 이미 스펙 졸라 복잡하던데(특히 어트리뷰트 개똥망) 저렇게 하나하나 추가하면서 그언어처럼 되겠네
스펙이 간단하다고 마냥 좋은건 아님 Go보셈
물론 너무 복잡해지면 배우기 어렵겠지만 아직은 책한권에 다 담길정도라
러스트처럼 개잡탕 상태로 가느니 차라리 고가 나음
러스트가 무슨 책 한권에 다 담김 그 많은 어트리뷰트들, 러스토노미콘에 나오는 언세이프 기능들 싹다 무시하고 코딩 불가능한 상태
어트리뷰트 derive inline allow features macro_use 말고 써본적이 없는데 뭐가 그리 복잡하노
오픈 소스들 까봐도 프로그램 로직이랑 상관 없이 언어 기능 자체가 오피셜북으로 파악할 수 없는 것들로 가득차있음
그리고 프로젝트 구성 파악하려면 결국 카고북도 봐야함
매크로 라이브러리는 못봐주겠는데 나머지는 볼만하던데
라이브러리 개발이야 원래 하던놈껄 분석하니까 어려운거고 사용은 라이브러리마다 문서화 다 돼있자너
뭣보다 go가 2.0에서 왜 제네릭이나 에러핸들링 같은걸 넣으려는지 생각해보셈 없으니까 generate로 흉내내고 if err != nil 맨날 해서 커뮤니티에서 맨날 넣어달라고 하자너
언어 스펙은 복잡해질지라도 그만큼 보일러 플레이트 빠지니까 넣는거임 콜백지옥이 더 심플한데 다들 async await 넣잖아
복잡한거 같으면 C++ 스펙 보고 오자.
러스트 이미 스펙 졸라 복잡하던데(특히 어트리뷰트 개똥망) 저렇게 하나하나 추가하면서 그언어처럼 되겠네
스펙이 간단하다고 마냥 좋은건 아님 Go보셈
물론 너무 복잡해지면 배우기 어렵겠지만 아직은 책한권에 다 담길정도라
러스트처럼 개잡탕 상태로 가느니 차라리 고가 나음
러스트가 무슨 책 한권에 다 담김 그 많은 어트리뷰트들, 러스토노미콘에 나오는 언세이프 기능들 싹다 무시하고 코딩 불가능한 상태
어트리뷰트 derive inline allow features macro_use 말고 써본적이 없는데 뭐가 그리 복잡하노
오픈 소스들 까봐도 프로그램 로직이랑 상관 없이 언어 기능 자체가 오피셜북으로 파악할 수 없는 것들로 가득차있음
그리고 프로젝트 구성 파악하려면 결국 카고북도 봐야함
매크로 라이브러리는 못봐주겠는데 나머지는 볼만하던데
라이브러리 개발이야 원래 하던놈껄 분석하니까 어려운거고 사용은 라이브러리마다 문서화 다 돼있자너
뭣보다 go가 2.0에서 왜 제네릭이나 에러핸들링 같은걸 넣으려는지 생각해보셈 없으니까 generate로 흉내내고 if err != nil 맨날 해서 커뮤니티에서 맨날 넣어달라고 하자너
언어 스펙은 복잡해질지라도 그만큼 보일러 플레이트 빠지니까 넣는거임 콜백지옥이 더 심플한데 다들 async await 넣잖아
복잡한거 같으면 C++ 스펙 보고 오자.