JavaScript/TypeScript가 원하는 코드 스타일과 기술적·인체공학적으로 충돌한다면, 수많은 JS로 컴파일되는 언어 중 하나를 쓰면 되지 않나 싶음
Haskell, Elm, F#이 언급되고, PureScript, js_of_ocaml, Reason, LunarML 등 글쓴이가 더 쓰고 싶어 하는 계열의 언어도 많음. 글쓴이는 Why TypeScript Won’t Save You라는 글까지 쓰며 선호 언어들과 더 비교했고 https://learnelm.dev도 운영함.
아니면 비교 자체가 목적이라서, TypeScript가 많은 경우 충분하지 않다는 걸 보여주고 다른 도구체인이나 아이디어 채택을 유도하려는 건가 싶기도 함

기존 코드베이스, 팀의 특정 언어 숙련도나 회사 지침, 더 적은 지원·도구·커뮤니티 규모 같은 제약이 있음
대부분은 그냥 다른 언어를 고를 선택권이나 시간이 없음

보통은 큰 TypeScript 코드베이스가 있거나, 다른 언어에는 없는 TypeScript 라이브러리를 쓰기 때문일 것 같음

업무에서 브랜디드 타입(branded type) 을 아주 좋아하지만, 브랜디드 숫자로만 인덱싱 가능한 Array나 TypedArray를 만들 수 없다는 점이 정말 거슬림
TypedArray는 브랜디드 숫자를 저장하거나, 더 정확히는 꺼내 읽는 것조차 안 됨. IndexArray나 IndexTypedArray 같은 별도 타입 세트가 필요하더라도, 이런 기능이 꼭 있었으면 함

나도 브랜디드 타입을 좋아하지만, 얘기해보면 다들 들이는 노력에 비해 별로라고 봄
꽤 복잡한 데이터베이스 스키마에서 모든 ID에 브랜디드 타입을 쓰면, 말이 안 되는 조인이나 조건을 만들 때 TypeScript가 잡아줌. 함수 시그니처도 더 명확해지고 여러 실수를 만들기 어려워짐

충분히 세게 거짓말할 의향이 있다면, 브랜디드 숫자로만 인덱싱 가능한 Array를 만들 수는 있음
원한다면 TypedArray의 값에도 같은 식으로 가능함

직장에서는 “스마트 enum”과 커스텀 배열 타입을 써서 TArray<Foo, MyEnum>처럼 작성할 수 있음. 다만 이건 C++ 얘기임
Zig의 std 라이브러리에는 comptime으로 구현된 EnumArray가 있음. 조밀한 enum이나 희소한 enum을 인덱싱에 쓰고, 컴파일 시점에 올바른 인덱서를 계산하는 등 더 넓은 기능도 제공함.
이런 정밀한 타입 지정이 점점 마음에 듦. 코드베이스에 논리 버그가 들어오는 것 자체를 많이 막아줌