3 ms·

>opam files require you to bring your own installation and build scripts. What do you mean? >if the end result is still slower than Go. Benchmarks? >OCaml l

>opam files require you to bring your own installation and build scripts. What do you mean? >if the end result is still slower than Go. Benchmarks? >OCaml libraries are typically overly-abstract or they prefer unintuitive operators and identifiers and generally take much longer to grok than the time they save to use. Examples? I’ve never seen any of this in a whole mirage stack, lwt, angstrom/faraday, yojson or any other major ocaml lib.

weberc2 9y ago
> What do you mean? build: [ ["./configure" "--prefix=%{prefix}%"] [make] ] > Benchmarks? I'm not asserting that Go is faster, I'm saying that you need to provide evidence that OCaml is faster if you want me to believe that OCaml's compiler is "light-years ahead of Go's in terms of optimizations". Perhaps you didn't mean "OCaml is faster", but only "OCaml is hard to very hard to make fast, but the OCaml compiler does a fantastic job despite". In which case you'll need to justify why that matters to me if it's not actually faster than Go (especially if the performance is worse and/or less intuitive). > Examples? I’ve never seen any of this in a whole mirage stack, lwt, angstrom/faraday, yojson or any other major ocaml lib. It's been a while, so the details are foggy. Looking at the RealWorldOCaml page for yojson, however, immediately takes us through an example with a dozen `|>` operators and functional combinators. Perhaps this is a documentation problem and there are more straightforward mechanisms, but that's no great comfort to me as a user. Something as common as JSON should be dead simple, at least in the main cases. And while I have lots of criticism for Go's JSON handling, it is dead simple in the main cases. Note that this isn't a particularly good example of OCaml libraries being overly abstract; it's just the most concrete example I could provide in a 5 minutes.
- ernst_klim 9y ago
  >build: Nowadays it's just build: ["jbuilder" "build" "-p" name "-j" jobs ] It's just one line of config and it is worth it since it gives an opportunity to use any build system you want to (or for some reasons have to) use. Still much better then pulling "deps" from github repos directly. >I'm saying that you need to provide evidence that OCaml is faster >"OCaml is hard to very hard to make fast, but the OCaml compiler does a fantastic job despite". In which case you'll need to justify why that matters to me if it's not actually faster than Go (especially if the performance is worse and/or less intuitive). Sure, you can write manually a ton of boilerplate for each numeric type in go, just like it's done in gonum. I'm not sure if it is good since more code means more issues and bugs, and I definitely prefer to write or hack something like this: https://github.com/inhabitedtype/httpaf/blob/master/lib/parse.ml https://github.com/inhabitedtype/httpaf/blob/master/lib/pars... instead of this: https://github.com/valyala/fasthttp/blob/master/header.go https://github.com/valyala/fasthttp/blob/master/header.go (and this is only a header) and let the compiler do all the dirty work. > with a dozen `|>` operators how the hell is `|>` an obscure combinator? It's just a "unix pipe's" typesafe kin. I've never seen any usage of obscure combinators in ocaml beyond parser-combinator libs ofc but these usually are well documented and you wouldn't use them if you don't like combinators anyway. >Something as common as JSON should be dead simple It is dead simple, just add [@@deriving yojson] to your data structure, and you'll get to\of_yojson functions, what could be more simple?
  - weberc2 9y ago
    > Nowadays it's just build: ["jbuilder" "build" "-p" name "-j" jobs ] It's just one line of config and it is worth it since it gives an opportunity to use any build system you want to (or for some reasons have to) use. Still much better then pulling "deps" from github repos directly. I strongly disagree here. Deps is rather ugly, but it works and it's easy to use. A language should have 1 build tool that works for 99% of use cases, and the rest of the tooling should support that by default. This is especially painful for beginners, amplified by the fact that the docs point you to Makefiles by default. > Sure, you can write manually a ton of boilerplate for each numeric type in go, just like it's done in gonum. I'm not sure if it is good since more code means more issues and bugs, and I definitely prefer to write or hack something like this: I'm confused; you're responding in the context of compilers producing fast code, but you seem to be advocating for a more generic type system than Go has, which I've already agreed about. > how the hell is `|>` an obscure combinator? It's just a "unix pipe's" typesafe kin. I've never seen any usage of obscure combinators in ocaml beyond parser-combinator libs ofc but these usually are well documented and you wouldn't use them if you don't like combinators anyway. I didn't claim it was obscure; I claimed that it's not useful--it's optimizing for fewer keystrokes and not readability. I can appreciate code-golf for its own sake, but I need my team to be able to jump into code quickly, and that often means that naive is better than clever and a little boilerplate is better than terseness. BTW, the HTTP parser that you shared is a good example of this. The Go version might be imperative, but at least it's clear. > It is dead simple, just add [@@deriving yojson] to your data structure, and you'll get to\of_yojson functions, what could be more simple? Like I said before; this might not be a good example, it's just the first one that came to my mind. Maybe the problem here is that the good documentation is so hard to find. Still, I've come across lots of unnecessarily abstract libraries before, I just don't recall the details.
    - ernst_klim 9y ago
      >I claimed that it's not useful--it's optimizing for fewer keystrokes and not readability. it makes code much more readable produce_collection () |> Col.filter pred |> Col.map to_json Only pure logic of the program remained, no garbage like intermediate vars, loops, etc. >The Go version might be imperative, but at least it's clear. Depends on how do you define clear. If huge manually optimized pile of imperative spagetty is clear, than yes. My definition of clear presumes sophisticated abstractions making hard things easier to reason about and comprehand, not a pile of hand-written state machines. >Still, I've come across lots of unnecessarily abstract libraries before, So many that you couldn't find an example?

weberc2 9y ago

> What do you mean? build: [ ["./configure" "--prefix=%{prefix}%"] [make] ] > Benchmarks? I'm not asserting that Go is faster, I'm saying that you need to provide evidence that OCaml is faster if you want me to believe that OCaml's compiler is "light-years ahead of Go's in terms of optimizations". Perhaps you didn't mean "OCaml is faster", but only "OCaml is hard to very hard to make fast, but the OCaml compiler does a fantastic job despite". In which case you'll need to justify why that matters to me if it's not actually faster than Go (especially if the performance is worse and/or less intuitive). > Examples? I’ve never seen any of this in a whole mirage stack, lwt, angstrom/faraday, yojson or any other major ocaml lib. It's been a while, so the details are foggy. Looking at the RealWorldOCaml page for yojson, however, immediately takes us through an example with a dozen `|>` operators and functional combinators. Perhaps this is a documentation problem and there are more straightforward mechanisms, but that's no great comfort to me as a user. Something as common as JSON should be dead simple, at least in the main cases. And while I have lots of criticism for Go's JSON handling, it is dead simple in the main cases. Note that this isn't a particularly good example of OCaml libraries being overly abstract; it's just the most concrete example I could provide in a 5 minutes.

ernst_klim 9y ago
>build: Nowadays it's just build: ["jbuilder" "build" "-p" name "-j" jobs ] It's just one line of config and it is worth it since it gives an opportunity to use any build system you want to (or for some reasons have to) use. Still much better then pulling "deps" from github repos directly. >I'm saying that you need to provide evidence that OCaml is faster >"OCaml is hard to very hard to make fast, but the OCaml compiler does a fantastic job despite". In which case you'll need to justify why that matters to me if it's not actually faster than Go (especially if the performance is worse and/or less intuitive). Sure, you can write manually a ton of boilerplate for each numeric type in go, just like it's done in gonum. I'm not sure if it is good since more code means more issues and bugs, and I definitely prefer to write or hack something like this: https://github.com/inhabitedtype/httpaf/blob/master/lib/parse.ml https://github.com/inhabitedtype/httpaf/blob/master/lib/pars... instead of this: https://github.com/valyala/fasthttp/blob/master/header.go https://github.com/valyala/fasthttp/blob/master/header.go (and this is only a header) and let the compiler do all the dirty work. > with a dozen `|>` operators how the hell is `|>` an obscure combinator? It's just a "unix pipe's" typesafe kin. I've never seen any usage of obscure combinators in ocaml beyond parser-combinator libs ofc but these usually are well documented and you wouldn't use them if you don't like combinators anyway. >Something as common as JSON should be dead simple It is dead simple, just add [@@deriving yojson] to your data structure, and you'll get to\of_yojson functions, what could be more simple?
- weberc2 9y ago
  > Nowadays it's just build: ["jbuilder" "build" "-p" name "-j" jobs ] It's just one line of config and it is worth it since it gives an opportunity to use any build system you want to (or for some reasons have to) use. Still much better then pulling "deps" from github repos directly. I strongly disagree here. Deps is rather ugly, but it works and it's easy to use. A language should have 1 build tool that works for 99% of use cases, and the rest of the tooling should support that by default. This is especially painful for beginners, amplified by the fact that the docs point you to Makefiles by default. > Sure, you can write manually a ton of boilerplate for each numeric type in go, just like it's done in gonum. I'm not sure if it is good since more code means more issues and bugs, and I definitely prefer to write or hack something like this: I'm confused; you're responding in the context of compilers producing fast code, but you seem to be advocating for a more generic type system than Go has, which I've already agreed about. > how the hell is `|>` an obscure combinator? It's just a "unix pipe's" typesafe kin. I've never seen any usage of obscure combinators in ocaml beyond parser-combinator libs ofc but these usually are well documented and you wouldn't use them if you don't like combinators anyway. I didn't claim it was obscure; I claimed that it's not useful--it's optimizing for fewer keystrokes and not readability. I can appreciate code-golf for its own sake, but I need my team to be able to jump into code quickly, and that often means that naive is better than clever and a little boilerplate is better than terseness. BTW, the HTTP parser that you shared is a good example of this. The Go version might be imperative, but at least it's clear. > It is dead simple, just add [@@deriving yojson] to your data structure, and you'll get to\of_yojson functions, what could be more simple? Like I said before; this might not be a good example, it's just the first one that came to my mind. Maybe the problem here is that the good documentation is so hard to find. Still, I've come across lots of unnecessarily abstract libraries before, I just don't recall the details.
  - ernst_klim 9y ago
    >I claimed that it's not useful--it's optimizing for fewer keystrokes and not readability. it makes code much more readable produce_collection () |> Col.filter pred |> Col.map to_json Only pure logic of the program remained, no garbage like intermediate vars, loops, etc. >The Go version might be imperative, but at least it's clear. Depends on how do you define clear. If huge manually optimized pile of imperative spagetty is clear, than yes. My definition of clear presumes sophisticated abstractions making hard things easier to reason about and comprehand, not a pile of hand-written state machines. >Still, I've come across lots of unnecessarily abstract libraries before, So many that you couldn't find an example?