3 ms·

The issue with TS is that its way too easy to fallback to unsafe code. Also the TS typesystem is WAY, WAY too complex. They pile new hard to grasp niche feature

The issue with TS is that its way too easy to fallback to unsafe code. Also the TS typesystem is WAY, WAY too complex. They pile new hard to grasp niche features that has made it really hard to grasp. The TS sweetspot was (imho) somewhere around 1.8-2.0 era. These days you can run doom in the typesystem. I cant say about hiring, as i dont hire a dev that knows language X, i hire engineers that know the ins and outs of how software should be written, and know when to pick Go, when to pick ocaml and when to go with C/Rust. Also i would never use 99.9% of npm packages (js or ts) so i dont really care that much. As an example writing typeheads for reasonml is not really that hard, as a benefit you know exactly what parts you use. Also i dont use AI, and we dont accept any PR that are videcoded.

koakuma-chan 11mo ago
Why would you ever pick OCaml over Rust or Go?
- phplovesong 11mo ago
  If i need something that must be proven correct. Something that really cant (ungracefully) fail, where there is no null pointer exceptions, or other panics (eg rust has unwrap, and Go has nills). Something that does not need to run on C speeds (both Go and OCaml have similar performance, somewhere around 80-90% of C/Rust give or take), and when i want to have a fast feedback cycle (the OCaml compiler is even faster than Go's compiler). Basically OCaml when i want to have a good sleep at night, and be sure im not paged at 2AM for some weird panic or null pointer error. Thats why i glue stuff together, i might have some "this-is-critical-as-fuck" code written in OCaml, and a webserver written in Go, and some perf critical feature written in Rust/C. It all depends on the requirements. Its a shame devs shy away from that, and use their only tool (language) for all things, leading to more brittle and overcomplex software.
epolanski 11mo ago
It's not that easy to fall to unsafe code if you know what you're doing, do not have typescript skill issues and use the right libraries, such as fp-ts or effect-ts (an evolution of Scala's ZIO on TypeScript). Those ecosystems are huge by the way, effect is still very niche-y due to its usage of functional programming and effect systems, niche in a sense, it gets more downloads than Angular. [1] https://gcanti.github.io/fp-ts/modules/ https://gcanti.github.io/fp-ts/modules/ [2] https://effect.website/ https://effect.website/ I have my beefs with TypeScript's complexity, verbosity and limits, don't get me wrong but I don't see any realistic alternative for who wants to write type safe code. I loved Elm or Reason, but they are not realistic nor productive choices unless your IT team has North American startup budget. In my real world, we don't have the budgets to lure the kind of brilliant engineers that know when to pick Ocaml and when to go with Rust (or have ever used any of them).
- phplovesong 11mo ago
 I get the idea of libraries like fp-ts and effect-ts, but like most libraries in this area, they are just boltons. I dont like to write unidiomatic code for given language if it is not designed for it. This means if i wrote a applicative that must satisfy homomorphism in javascript: APP.ap(APP.of(ab), APP.of(a)) = APP.of(ab(a)) Im pretty sure not a single dev would understand what the hell is going on, and i would have to buy quite a few beers to get that passed in a CR. I write idiomatic code for the language: Eg. In Go i loop and use mutability when its the correct thing to do, but in OCaml i almost exclusively use recursion and favour a monadic api, and javascript being a middle-ground i tend to just just the builtins map/filter/reduce and pals for most things. I dont need a monad for the sake of it. That said i tend to step out of this rule when it comes to errors, and avoid throwing as much as possible. Errors as values is invaluable.
 - epolanski 11mo ago
 > Im pretty sure not a single dev would understand what the hell is going on, and i would have to buy quite a few beers to get that passed in a CR. That's a questionable example imho, for few reasons. The first is that understanding an applicative functor requires you to first understand map, apply and lift. Starting from an applicative, in any language, including Haskell, is like starting from a monad, (as you know very well they are almost the same thing as a monad is an applicative with one more rule) and then it's quite clear why we get endless blog posts that leave you no brighter. The second is that we're talking about TypeScript, not JavaScript. Let's make an example. Given a definition for map in TypeScript: map: <A, B>(f: (a: A) => B) => ((fa: F<A>) => F) which requires a minimal typescript understanding (a function from A to B and a value of type F<A> you get F) to read. If you can read map you can read ap in TypeScript: const ap: <A>(fa: F<A>) => (fab: F<(a: A) => B>) => F It's almost the same, with one major difference: you don't have a function from a to b, but one that is lifted in a datatype F, thus F<a => b>.

koakuma-chan 11mo ago

Why would you ever pick OCaml over Rust or Go?

phplovesong 11mo ago
If i need something that must be proven correct. Something that really cant (ungracefully) fail, where there is no null pointer exceptions, or other panics (eg rust has unwrap, and Go has nills). Something that does not need to run on C speeds (both Go and OCaml have similar performance, somewhere around 80-90% of C/Rust give or take), and when i want to have a fast feedback cycle (the OCaml compiler is even faster than Go's compiler). Basically OCaml when i want to have a good sleep at night, and be sure im not paged at 2AM for some weird panic or null pointer error. Thats why i glue stuff together, i might have some "this-is-critical-as-fuck" code written in OCaml, and a webserver written in Go, and some perf critical feature written in Rust/C. It all depends on the requirements. Its a shame devs shy away from that, and use their only tool (language) for all things, leading to more brittle and overcomplex software.

epolanski 11mo ago

It's not that easy to fall to unsafe code if you know what you're doing, do not have typescript skill issues and use the right libraries, such as fp-ts or effect-ts (an evolution of Scala's ZIO on TypeScript). Those ecosystems are huge by the way, effect is still very niche-y due to its usage of functional programming and effect systems, niche in a sense, it gets more downloads than Angular. [1] https://gcanti.github.io/fp-ts/modules/ https://gcanti.github.io/fp-ts/modules/ [2] https://effect.website/ https://effect.website/ I have my beefs with TypeScript's complexity, verbosity and limits, don't get me wrong but I don't see any realistic alternative for who wants to write type safe code. I loved Elm or Reason, but they are not realistic nor productive choices unless your IT team has North American startup budget. In my real world, we don't have the budgets to lure the kind of brilliant engineers that know when to pick Ocaml and when to go with Rust (or have ever used any of them).

phplovesong 11mo ago
I get the idea of libraries like fp-ts and effect-ts, but like most libraries in this area, they are just boltons. I dont like to write unidiomatic code for given language if it is not designed for it. This means if i wrote a applicative that must satisfy homomorphism in javascript: APP.ap(APP.of(ab), APP.of(a)) = APP.of(ab(a)) Im pretty sure not a single dev would understand what the hell is going on, and i would have to buy quite a few beers to get that passed in a CR. I write idiomatic code for the language: Eg. In Go i loop and use mutability when its the correct thing to do, but in OCaml i almost exclusively use recursion and favour a monadic api, and javascript being a middle-ground i tend to just just the builtins map/filter/reduce and pals for most things. I dont need a monad for the sake of it. That said i tend to step out of this rule when it comes to errors, and avoid throwing as much as possible. Errors as values is invaluable.
- epolanski 11mo ago
 > Im pretty sure not a single dev would understand what the hell is going on, and i would have to buy quite a few beers to get that passed in a CR. That's a questionable example imho, for few reasons. The first is that understanding an applicative functor requires you to first understand map, apply and lift. Starting from an applicative, in any language, including Haskell, is like starting from a monad, (as you know very well they are almost the same thing as a monad is an applicative with one more rule) and then it's quite clear why we get endless blog posts that leave you no brighter. The second is that we're talking about TypeScript, not JavaScript. Let's make an example. Given a definition for map in TypeScript: map: <A, B>(f: (a: A) => B) => ((fa: F<A>) => F) which requires a minimal typescript understanding (a function from A to B and a value of type F<A> you get F) to read. If you can read map you can read ap in TypeScript: const ap: <A>(fa: F<A>) => (fab: F<(a: A) => B>) => F It's almost the same, with one major difference: you don't have a function from a to b, but one that is lifted in a datatype F, thus F<a => b>.