Hacker News Reader

Comment by joseferben | Hacker News Reader

having written ocaml in production for a few years, i think soundness comes at a cost of dev ergonomics. at least with the type systems of today’s industry languages.

it blows my mind weekly how ergonomic and flexible typescript’s type system is. it allows me to write great apis for my team mates.

is it possible for the type checker to end up in an infinite loop or for a junior developer to abuse “as”? absolutely, but it doesn’t really matter in practice.

i wouldn’t want to run typescript in rockets or submarines tho!

View on HN

Ocaml types are USED by the compiler to generate FAST code.

TS types are IGNORED by the JIT to generate SLOW code.

All the features that make Typescript more ergonomic for devs also allow it to generate slower JS code. AssemblyScript tries to be TS for WASM and it doesn't support huge swaths of TS because they output unusably slow garbage.

I also suspect that more than a few Ocaml ergonomic issues are due to nominal typing. StandardML's structural typing and inference give an experience very similar to TS, but without the major soundness issues (though it must be noted that ANY generics in JS will be slow unless the compiler is creating multiple function variants).

for my use case (web dev) ts is fast enough. but i do miss the ocaml compile times!

it's mainly the lack of ad-hoc polymorphism that makes ocaml feel a bit clunky to me at times. but structural typing sure would be nice.

i used to avoid typescript because of similar soundness issues. but in the context of web dev this weird type system that evolved from adding types to javascript turned out to be so nice to use. it's bonkers because on paper it shouldn't be this nice haha.

Ocaml messed up with their operators. StandardML had a better approach and I hope a future version adds module typeclasses (to help limit the type soup we see in Haskell).

As I wrote elsewhere in this thread, TS makes it incredibly easy to unintentionally make megamorphic functions that don’t have any inline cache and don’t get optimized at all. You think you’re writing efficient, DRY code, but it’s really just dog slow because you’ve neutered the JIT.

> Ocaml messed up with their operators. ... I hope a future version adds module typeclasses

Do you mean modular implicits?[1] The original paper was published in 2014. There's an internship report from 2023 that summarizes the design and implementation issues:

https://modular-implicits.github.io/report.pdf

[1] https://arxiv.org/abs/1512.01895

https://www.cs.cmu.edu/%7Erwh/papers/mtc/short.pdf

I believe modular implicits and modular typeclasses are similar and aim to solve the same issues, but they are not quite the same.

Reply on news.ycombinator.com