4 ms·

Go’s dependency management story is not just “not pretty” it is a total disaster as recent story with hijacked repo had shown. It does not allow proper versioni

Go’s dependency management story is not just “not pretty” it is a total disaster as recent story with hijacked repo had shown. It does not allow proper versioning, repo management, total garbage. And how is making packages is a problem? You jast add opam file and that is all. You can do versioning, pin any opam or git repo, or even some fs resource. Yes ocaml compiler is light years ahead Go’s one in terms of optimizations and code analysis (and even correctness [1]). It is still not as great as haskell’s one, but very good, especially with new lambda middle end. Go compiler is straightforward as hell and can’t do much inlining or optimizations that ocaml can. Windows support was always tier 1 in compiler. Jbuilder also supports windows and even cross-compilation with windows as a target. Opam now compiles on Windows was too. As for libraries opam now have thousands of these and ocaml libraries’ quality is often much higher than the quality of libs of this other imperative language due to quality of language. >go standard library lol no math for ints, no data structures beyond map, but crappy http and Json serialization. [1] https://blog.janestreet.com/proofs-and-refutations-using-z3 https://blog.janestreet.com/proofs-and-refutations-using-z3

weberc2 9y ago
> it does not allow proper versioning, repo management, total garbage. This reads like you're trying to pass a stylistic objection off as a functional objection. If that's not the case, feel free to add substance. > And how is making packages is a problem? You jast add opam file and that is all. You can do versioning, pin any opam or git repo, or even some fs resource. Ignoring the one-off syntax choice, opam files require you to bring your own installation and build scripts. > Yes ocaml compiler is light years ahead Go’s one in terms of optimizations and code analysis (and even correctness [1]). It is still not as great as haskell’s one, but very good, especially with new lambda middle end. Go compiler is straightforward as hell and can’t do much inlining or optimizations that ocaml can. I don't care about "light-years of optimizations" if the end result is still slower than Go. > lol no math for ints, no data structures beyond map, but crappy http and Json serialization. This is an enumeration fallacy. I can rattle off a laundry list of OCaml standard library problems as well. This isn't constructive discussion. > As for libraries opam now have thousands of these and ocaml libraries’ quality is often much higher than the quality of libs of this other imperative language due to quality of language. I find this not to be true, at least in the case of OCaml vs Go. 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. Again, I agree that Go the language needs work, but the ecosystem is fantastic. Of course, improvements to the language could benefit the ecosystem (for example, sum types would bring sanity to JSON), but I can still be far more productive in Go than in OCaml.
- ernst_klim 9y ago
  >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

> it does not allow proper versioning, repo management, total garbage. This reads like you're trying to pass a stylistic objection off as a functional objection. If that's not the case, feel free to add substance. > And how is making packages is a problem? You jast add opam file and that is all. You can do versioning, pin any opam or git repo, or even some fs resource. Ignoring the one-off syntax choice, opam files require you to bring your own installation and build scripts. > Yes ocaml compiler is light years ahead Go’s one in terms of optimizations and code analysis (and even correctness [1]). It is still not as great as haskell’s one, but very good, especially with new lambda middle end. Go compiler is straightforward as hell and can’t do much inlining or optimizations that ocaml can. I don't care about "light-years of optimizations" if the end result is still slower than Go. > lol no math for ints, no data structures beyond map, but crappy http and Json serialization. This is an enumeration fallacy. I can rattle off a laundry list of OCaml standard library problems as well. This isn't constructive discussion. > As for libraries opam now have thousands of these and ocaml libraries’ quality is often much higher than the quality of libs of this other imperative language due to quality of language. I find this not to be true, at least in the case of OCaml vs Go. 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. Again, I agree that Go the language needs work, but the ecosystem is fantastic. Of course, improvements to the language could benefit the ecosystem (for example, sum types would bring sanity to JSON), but I can still be far more productive in Go than in OCaml.

ernst_klim 9y ago
>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?