3 ms·

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 lang

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!

hajile 2y ago
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).
- joseferben 2y ago
  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.
  - hajile 2y ago
    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.
    - nequo 2y ago
      > 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 https://modular-implicits.github.io/report.pdf [1] https://arxiv.org/abs/1512.01895 https://arxiv.org/abs/1512.01895
      - hajile 2y ago
        https://www.cs.cmu.edu/%7Erwh/papers/mtc/short.pdf 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.

hajile 2y ago

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).

joseferben 2y ago
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.
- hajile 2y ago
  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.
  - nequo 2y ago
    > 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 https://modular-implicits.github.io/report.pdf [1] https://arxiv.org/abs/1512.01895 https://arxiv.org/abs/1512.01895
    - hajile 2y ago
      https://www.cs.cmu.edu/%7Erwh/papers/mtc/short.pdf 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.