당연히 주관적인 내용임.
1. 자바같은 vm 언어가 쓰레기 같이 보임.
이건 내가 속한 조직이 좀 병신같고 거지같은 문제일 수도 있는데 서버비 아낀다고 서비스 일부를 ec2 스팟 인스턴스를 쓰더라고. 가끔 뒤졌는데 다시 안올라와서 장애 발생할 때도 있는데 그렇게 서버비 몇푼이 아까우면 러스트로 만들어서 ec2 최하 인스턴스 하나에 서비스 10개씩 처박으면 되지 않나? 그런 생각이 듬. 아 물론 러스트 말고 고언어 써도 10개씩 처 박을 수 있을듯. vm 문제는 성능보단 메모리를 많이 먹는게 문제라서. 사실 조직이 짠돌이가 아니라면 별로 신경쓰고 싶지 않은 문제.
2. null이나 error throw가 병신같이 보임.
nullalble 문제는 typescript typeorm 쓰면서 겪은건데 이 새끼 nullable한걸 nullable하다고 표시를 안해줌. entityRepository.firnd(): Entity 함수 시그니처는 이렇게 생겼는데 당연히 find해서 나온 엔티티가 없으면 결과는 널임. Entity | null이나 Entity? 형으로 반환해야 맞지 않나? 특히 연관 엔티티가 find 할 때 relation인가 지정 안해주면 널인데 타입에는 널러블 안해줘서 개빡친 기억이 있음. 러스트는 널 자체가 없고 Option<E>를 써서 널인 경우에 대한 처리를 강제로 하게 만드는게 마음에 듦.
throw는 러스트 개인프로젝트 하면서 느낀건데 러스트 레디스 라이브러리에선 조회 결과가 Result타입인거임. 사실 너무나 당연한건데 레디스 서버 내려가있으면 당연히 실패하겠지. 그런데 자바나 js로 작업할 때는 레디스 작업에 대해서 try catch 처리한 적이 없음. 그냥 무지성으로 실패할 리가 없는 작업 또는 실패해서는 안되는 작업으로 생각해버린거지. 만약 레디스가 죽어서 문제가 발생하면 누가 레디스 죽였나 범인 찾기 하고 그랬음. 그런데 레디스가 api 응답 캐싱 같은 용도였으면 실패했을 떄 그냥 디비 조회해서 응답하고 센트리 같은데다가 레디스 뒤졌어요 알림 주는 식으로 처리하는게 더 견고한 서비스이지 않나? 그런 생각이 듦. 물론 try catch로도 구현할 수 있는데 try catch 사고 방식 자체가 에러를 좀 뭉뜨그리는 그런 느낌이 듦. 러스트는 실패할 가능성이 있을 때마다 항상 내게 묻는거지. '너 이거 실패하면 어쩔건데? 니가 하고 싶은게 그게 맞아?' 집착 광녀 느낌이 들어서 기분 좋음.
3. switch에서 enum 모든 경우의 수 안따지는 언어는 병신값음
러스트 match는 무조건 들어가는 변수의 경우의 수를 모두 다 빠짐없이 커버하도록 강제함. 물론 디폴트 있음. 코틀린 다트에는 그런 기능 있던데 최근 언어들은 그런 추세인 모양. 아주 바람직한 흐름인듯.
4. 툴이 막 난잡하게 분리되어 있는거 병신같음
러스트는 cargo라는 툴이 있는데 프로젝트 시작할 때 cargo new 라이브러리 추가할 때 cargo add 이런식으로 씀. 별거 아닌거 같지만 여기에 코드 포맷팅 기능도 있는데 개꿀임. prettier 설정 맞춘다고 개지랄 할 필요 없이 git push할 때 cargo fmt 한번 돌리면 됨. github에서 cargo fmt 안되어 있으면 머지 안되게 설정할 수도 있지 않을까? 물론 해보진 않았음. 같이 러스트로 작업하는 팀이 없어서
5. c cpp와 비교해서
이건 잘 모름. 러스트가 제일 강조하는게 메모리 안전성이고 메모리를 제일 위험하게 다루는게 c 계열인데 c/cpp는 대학에서만 깔짝 하고 그 뒤로는 한 적이 없음. 현업에서는 vm이 알아서 메모리를 관리해주는 문란한 언어밖에 안써봐서 안정성에 대해서는 크게 와닿는건 없음. 대학에서 c 하면서 굉장히 사소한 포인트 실수로 디버깅 시간 엄청나게 날려먹기도 했는데 기억도 잘 안나고 디버깅 툴도 제대로 못다뤄서 printf로 찍어가며 디버깅한 거라서 현업에선 뭐 어떻게 돌아가는지도 몰라서 "러스트로 개발하면 c가지고 디버깅하는 시간을 아껴서 xx% 빠르게 끝낼 수 있다" 이런 느낌이 없음. 물론 러스트의 안정성은 공짜가 아니지. 굉장히 생소한 문법들을 지켜야하는데 빌림자 가지고 뭔가 하다가 뻑나면 뭔소린지 이해하는것부터가 힘듦. 물론 하나하나 이해 못할 내용은 아닌데 그냥 귀찮아서 to_string()이나 copy() 난사함. 뭐 대충 자바나 자스보다만 효율적이면 되는거 아닐까?
러스트로뭐만들엉?
axum으로 웹서비스 만들어봄. 공공 api조회해서 버스 정류소 도착 알림 - dc App
vm언어라는 철학 자체는 쓰레기가 맞는듯 - dc App
컴퓨터 하드웨어 성능은 비약적으로 발전하면서 가격은 오히려 싸지던 시절에는 나쁘지 않은 방식이라고 봄. 다만 클라우드 컴퓨팅 환경에선 더 이상 컴퓨터 자원은 싼게 아니게 된 듯. 아니면 몇 푼 아낀다고 발악떠는 내 회사만 개거지 병신이던가. - dc App
spot이 문제가 아니라 확률적으로 찐빠나는 네 구현체가 문제 아닐까
ㄴㄴ 내가 진빠 안냄. 스팟은 원래 남이 안쓰는거 자투리로 싼 값에 줏어서 쓰는거라 언제든지 내려갈 수 있음. 프로그램을 잘못짜서 죽는게 아님. 다시 안뜨는건 아마존이 잘못했거나 인프라가 잘못설정한거지 일단 내 잘못은 아닌듯. - dc App
spot이 뭔지는 나도 알아. 가끔 aws에서 interruption notice 제때 안줘서 gracefully shutdown 안되는건 그렇다쳐도 확률적으로 안뜬다거나 하는건 네 구현체 문제다 이말이야. 아니면 네말대로 인프라팀이 뭔가 잘못했거나. 요지는 spot은 원래 언제든지 죽을수 있다는걸 전제로 하고 어플리케이션을 충분히 robust하게 구현해야 한다는거
@ㅇㅇ(110.8) 니문제 맞음 - dc App
개병신 학식충인걸 길게도 쳐말하노 ㅋㅋ
원래 에러핸들링이 애미 뒤진거아닌가 ?
4번 설정을 모두에게 강제하는게 있는지는 모르겠고 나 혼자 고언어쓸때 git hook에 go fmt 박아서 커밋할때 자동으로 go fmt을 먼저 실행하도록 설정함
검색해보니 github은 webhook을 설정해서 특정 브랜치에 머지하거나 푸시할때 실행할 명령어 설정하는거 가능한듯
오 git hook 좋네 ㄱㅅ - dc App
스팟에 서비스 띄우고 스팟 뒤지면 서비스 안된다는 개 병신같은 씹좆소 들어간 니탓이지 뭘 ㅋㅋ
다른 언어에 대한 경험이 너무 없는 것 같다 보통 러스트 빠는 애들 평균이긴 함
원래 아는만큼 보임