Java의 발전이 정말 반가움. 그래도 프런트엔드 작업을 많이 하고 전체 스택에서 같은 언어를 쓰고 싶어서 TypeScript를 더 선호함.
TypeScript에서도 모든 경우를 빠짐없이 검사하는 패턴 매칭이 가능함! https://github.com/gvergnaud/ts-pattern.
아직 Scala로 코드를 쓰지만 언제까지 그럴지는 모르겠음. 그래도 Scala로 코딩하는 건 정말 즐거움.
프랑스 시처럼 우아하고, 번거로운 이펙트 시스템도 없이 Martin Odersky가 의도한 그대로 쓸 수 있음!
Java는 계속 Kotlin을 따라잡으려 하고 있음. https://kotlinlang.org/docs/sealed-classes.html.
비교 대상이 C++, Ruby, Python이던 시절에는 Java도 괜찮았음. 하지만 기능을 가리지 않고 받아들이다 실패한 듯한 Scala를 거쳐, 특히 Kotlin을 써 보고 나니 돌아갈 이유를 찾을 수 없음.
물건을 쌓아 두는 사람에게 소파가 다섯 개 있다고 해서 내가 소파 하나를 사는 게 그 사람을 따라잡으려는 행동은 아님. Java는 Kotlin의 모든 기능을 갖추려 하지 않으며, 오히려 그렇게 되지 않으려고 무척 노력함. Kotlin의 기능을 그대로 채택한 적도 없고, 공통된 영감의 원천인 ML 계열 언어에서 출발하더라도 대개 다른 형태로 구현함.
어떤 언어는 풍부한 기능을, 다른 언어는 간결함을 지향함. 둘 다 시간이 지나며 기능이 늘겠지만 속도는 크게 다름. 우리는 언어의 복잡성을 낮게 유지하는 것이 매우 중요해서, 추가되는 복잡성을 정당화할 가치가 있다고 확신할 때까지 수년씩 기능 도입을 미룸.
더 풍부한 언어를 좋아한다면 Java 플랫폼 안에 선택지가 있음. 하지만 더 작은 언어를 선호하는 개발자도 많으며, 지난 15년 이상 Java 플랫폼 개발자 중 Java 언어를 쓰는 비율은 약 90% 로 거의 일정하게 유지됨. 기능이 풍부한 언어를 선호하는 적지 않은 소수도 지원함. 어쨌든 JDK의 95%는 런타임인 표준 라이브러리·JVM과 도구이므로, 어떤 언어를 선호하든 그 혜택을 누릴 수 있음.
Java의 좋은 점은 의도적으로 늦게 움직이는 언어라는 점임. 최신 유행을 쫓기보다는 다른 언어에서 검증된 기능을 살펴봄.
Kotlin과 C#의 약속에는 다소 냉정해지게 됨. 겉보기에는 훌륭하지만 복잡한 코드를 다루기 시작하면 결점이 금방 드러나는 편임. Java는 놀랄 만큼 일관적이고 예상치 못한 함정도 거의 없음. 제네릭과 타입 소거를 감안하더라도, 언어의 의미 체계와 씨름한 일은 Java보다 C#에서 훨씬 잦았음.
Scala의 기능을 20% 정도 덜어 내고 싶기는 하지만, 주된 실패 원인은 느린 컴파일 속도였다고 봄. 그보다는 영향이 작겠지만, 입문하자마자 sbt를 마주해야 하는 것도 도움이 되지 않았음.
Kotlin을 못 쓰게 하고 Java와 Scala 중 하나를 고르라고 총을 겨눈다면, 작은 프로젝트에는 최신 Java를 고를 것 같음. 여러 팀이 참여하는 대규모 핵심 업무 프로젝트라면 차라리 총알을 맞겠음. 그래도 Scala에서 많이 배웠고 여전히 애정이 있음.
상당히 2018년 같은 이야기임. 내가 아는 기업 대부분은 주류인 Java로 돌아왔음. 다만 LLM 시대에는 채용 가능한 인력 규모의 우선순위가 낮아지고 기술 스택 이전의 마찰도 크게 줄어든 만큼, 다시 바뀔지는 지켜볼 일임.