4 ms·

>nominally typed structs aren't nearly as good OCaml structs are structurally typed. > They also have 3 competing standard libraries. There is only one stand

>nominally typed structs aren't nearly as good OCaml structs are structurally typed. > They also have 3 competing standard libraries. There is only one standard library, stdlib.

rndmio 7y ago
You know what he meant, if you want functionality comparable to the Go stdlib you are going to have to choose between Core or Batteries, then for async do you choose Async or Lwt? And as said the build system (when you're used to Go) is poor. I like a lot of what OCaml offers, but there's a lot of friction.
- ernst_klim 7y ago
  > if you want functionality comparable to the Go stdlib you are going to have to choose between Core or Batteries He is talking about SML here. Care to elaborate, what Go has to do with Core or Batteries? Both are mostly container libraries, and you don't need them since most of the useful staff is in stdlib. Check revdeps in OCaml, nobody uses batteries, and nearly nobody safe JS uses Core. XML parsers, Lwt, servers are in separate packages, which is the only and right thing to do. >then for async do you choose Async or Lwt Lwt, it's a non-question. Async is for JaneStreet only. > And as said the build system (when you're used to Go) is poor. Dune [1] is far superior to Go's build system. Extremely fast, composable, supporting packaging and os-dependent configurations, extremely easy to config. No abomination like "import github.com/package" or "//go:" in your code. Go build system doesn't have even a fraction of nice features dune have. For example I could `dune utop ./path/to/my/libs` to build my libs and run a nice repl to test them. Go doesn't even let you to configure your warnings precisely. [1] https://dune.build/ https://dune.build/
hajile 7y ago
> OCaml structs are structurally typed. You can read about Ocaml's nominal record typing in the [ReasonML docs](https://reasonml.github.io/docs/en/record https://reasonml.github.io/docs/en/record) (it's more clear there IMO). SML gets this right in my opinion. If I create a record `{foo = "abc", bar = 123}`, I can pass that record on to ANY function that needs a record that looks like {foo:string, bar:int} fields because it looks at the structure rather than the type of the record constructor. Another nice property of the SML approach is that you don't need named arguments. Instead, pass a tuple with names (aka a record). One set of syntax rules covers both cases. I also rather like the ability to access record fields with the hash syntax (eg, `#foo myrecord`) when I don't want to destructure.
- ernst_klim 7y ago
  >You can read about Ocaml's nominal record typing in the [ReasonML docs](https://reasonml.github.io/docs/en/record https://reasonml.github.io/docs/en/record) (it's more clear there IMO). You are confusing records with structures, it seems. Structures exist in module language. Records are nominal in SML as well. Access functions for tuples and records are a dirty ugly hack build-in for convenience, they have nothing to do with structural typing, they are inferred in place. OCaml has structural typed records, they are called objects. let obj = object method pi = 3.14; method name = "Pi" end val obj : < pi : float ; name : string > is structurally typed record. > I can pass that record on to ANY function No, you can't. #foo { foo = 42 } works, but fun f x = #foo x doesn't. It's an ugly hack, typing is still nominal. A hack, just like SML's arithmetic op overload. Compare it to OCaml, which have proper structural typing for objects and raw polymorphism let f x = x#foo f : < foo : 'a; .. > -> 'a Edit: sorry, indeed typing is structural since you can write `{x:typ} -> typ`. Anyways OCaml have structural typed records and raw polymorphism and subtyping support for them. > Another nice property of the SML approach is that you don't need named arguments. Instead, pass a tuple with names (aka a record). What's your point? You can use records as arguments in OCaml as well.

>nominally typed structs aren't nearly as good OCaml structs are structurally typed. > They also have 3 competing standard libraries. There is only one standard library, stdlib.

rndmio 7y ago

You know what he meant, if you want functionality comparable to the Go stdlib you are going to have to choose between Core or Batteries, then for async do you choose Async or Lwt? And as said the build system (when you're used to Go) is poor. I like a lot of what OCaml offers, but there's a lot of friction.

ernst_klim 7y ago
> if you want functionality comparable to the Go stdlib you are going to have to choose between Core or Batteries He is talking about SML here. Care to elaborate, what Go has to do with Core or Batteries? Both are mostly container libraries, and you don't need them since most of the useful staff is in stdlib. Check revdeps in OCaml, nobody uses batteries, and nearly nobody safe JS uses Core. XML parsers, Lwt, servers are in separate packages, which is the only and right thing to do. >then for async do you choose Async or Lwt Lwt, it's a non-question. Async is for JaneStreet only. > And as said the build system (when you're used to Go) is poor. Dune [1] is far superior to Go's build system. Extremely fast, composable, supporting packaging and os-dependent configurations, extremely easy to config. No abomination like "import github.com/package" or "//go:" in your code. Go build system doesn't have even a fraction of nice features dune have. For example I could `dune utop ./path/to/my/libs` to build my libs and run a nice repl to test them. Go doesn't even let you to configure your warnings precisely. [1] https://dune.build/ https://dune.build/

hajile 7y ago

> OCaml structs are structurally typed. You can read about Ocaml's nominal record typing in the [ReasonML docs](https://reasonml.github.io/docs/en/record https://reasonml.github.io/docs/en/record) (it's more clear there IMO). SML gets this right in my opinion. If I create a record `{foo = "abc", bar = 123}`, I can pass that record on to ANY function that needs a record that looks like {foo:string, bar:int} fields because it looks at the structure rather than the type of the record constructor. Another nice property of the SML approach is that you don't need named arguments. Instead, pass a tuple with names (aka a record). One set of syntax rules covers both cases. I also rather like the ability to access record fields with the hash syntax (eg, `#foo myrecord`) when I don't want to destructure.

ernst_klim 7y ago
>You can read about Ocaml's nominal record typing in the [ReasonML docs](https://reasonml.github.io/docs/en/record https://reasonml.github.io/docs/en/record) (it's more clear there IMO). You are confusing records with structures, it seems. Structures exist in module language. Records are nominal in SML as well. Access functions for tuples and records are a dirty ugly hack build-in for convenience, they have nothing to do with structural typing, they are inferred in place. OCaml has structural typed records, they are called objects. let obj = object method pi = 3.14; method name = "Pi" end val obj : < pi : float ; name : string > is structurally typed record. > I can pass that record on to ANY function No, you can't. #foo { foo = 42 } works, but fun f x = #foo x doesn't. It's an ugly hack, typing is still nominal. A hack, just like SML's arithmetic op overload. Compare it to OCaml, which have proper structural typing for objects and raw polymorphism let f x = x#foo f : < foo : 'a; .. > -> 'a Edit: sorry, indeed typing is structural since you can write `{x:typ} -> typ`. Anyways OCaml have structural typed records and raw polymorphism and subtyping support for them. > Another nice property of the SML approach is that you don't need named arguments. Instead, pass a tuple with names (aka a record). What's your point? You can use records as arguments in OCaml as well.