Hacker News Reader

Hacker News

Comment by sandGorgon | Hacker News Reader

Parent Full thread

sandGorgon

Could someone from the ocaml world comment on Typescript vs Ocaml ?

Is Typescript as close you get to Ocaml world... without writing a "ml" ?

View on HN

No. Reason would be the closest you can get without using OCaml itself.

Reason's actual name is Reason ML, and is just a different syntax for regular OCaml.

Clean or Purescript or Haskell or Rust would be the closest you can get to the OCaml world without writing the word ML.

No, Reason's actual name is Reason. The Reason ML name is similar to Go's "golang" name -- to work around the SEO nightmare the choice of the name really is. Your comment is otherwise correct in that Reason is an alternative syntax for good 'ole OCaml.

IIRC it was simply called Reason at first but then the slightly more descriptive ML was added for better searchability. People call it both Reason and Reason ML now. That seems fine to me :) You are right it mostly is just a different syntax for OCaml but like in the Erlang/Elixir case there is a bit more to the story (js interop, js ecosystem, new ideas here and there, more diverse community as a result, etc).

I still call it reason, especially when I talk about it with other js developers ;)

F# is as close you get to OCaml world without writing a "ml".

Typescript is unrelated to OCaml in any way.

This, F# is the modern and more friendly (syntax, interoperability ...) version of OCaml.

I'd say the link between TypeScript and F# is the pragmatic approach that Microsoft took. Different paradigms but with the same care for usability. They are both great language for projects.

Besides ReasonML (a dialect of Ocaml), if you’re looking for a layer on top of JavaScript or a supersets of JS that has a type system similar to or inspired by Ocaml, Flow comes closest: https://flow.org

Flow has a quite powerful type system that mimicks (and is inspired by) OCaml. Flow itself is written in Ocaml, by Facebook.

Probably Typescript is as close you get to Java world using web technologies.

I disagree, Typescript has algebraic data types, conditional types, type inference, type guards, many or all of which are missing in Java. The class syntax is just another optional feature and it is possible to write quite functional / ocaml like code in typescript.

It's more like C# than Java.

But on the other hand, C# is more like Java (with extras) than JavaScript, haha.

Does TS has pattern matching?

No and that’s one of biggest problems, pattern match is runtime decision not compile time one. It’s a shame because pattern matching with algebraic types is the full picture of the whole thing. Without it it’s just one-legged weirdo. It would be possible to emit runtime checks, similar to how tcomb+flow does it, but that’s not gonna happen anytime soon.

You can use switch statements for a pattern matching analogue. See the "Exhaustiveness Checking" heading at https://www.typescriptlang.org/docs/handbook/advanced-types.....

The goal of typescript is to provide static type analysis at compile time and mimic Ecmascript spec features. If Typescript starts bundling a runtime with it to do things completely unrelated to Javascript, then it's not just javascript with types anymore, it becomes its own language which defeats the entire purpose of Typescript.

This trade off is good because there is no runtime overhead, only desugaring. Typescript should never become ML or anything else that Javascript is not. If you want pattern matching in Typescript you need to convince the Ecma committee to put pattern matching into Javascript first.

Your comment seems like a non-sequitur. What does pattern matching have to do with runtimes?

Isn't one part of pattern matching to ask for a type and the other to ask which values the (instance?) of that type holds?

When a language has algebraic data types -- i.e., data types that have multiple, disjoint constructors -- pattern matching generally means determining which constructor was used to create the value being matched, and branching on that. I'm guessing this is the kind of pattern-match that TypeScript users would be eager to have.

What I don't see is how this requires the addition of a "runtime" on top of the JS model to make it work. I don't use TypeScript, and don't know how it implements its data types, so there may be something obvious here that I'm missing.

Pattern matching doesn't require any kind of runtime support, and can be implemented through desugaring.

How so?

Why would it need runtime support? It would just desugar into an if-else chain.

I believe there was/is a stage 0 proposal for pattern matching in ECMAScript

Stage 1 and yes, this one simply uses destructuring.

But it could use JavaScripts own types.

But it couldn't use TypeScripts types.

Reply on news.ycombinator.com