3 ms·

Ocaml’s ecosystem feels much better than Go’s. At least Ocaml has such a great package manager, better compiler, repland an allocation profiler. The only thing

Ocaml’s ecosystem feels much better than Go’s. At least Ocaml has such a great package manager, better compiler, repland an allocation profiler. The only thing it lacks is multicore runtime.

weberc2 9y ago
I disagree. Here are a few things about OCaml's ecosystem that are strictly worse than Go's, and which I find to be particularly frustrating: 1. Documentation. It's lacking or spread thinly across the Internet, and it's mostly low quality in my experience. 2. Windows support was dodgy last I checked. 3. Build tooling is byzantine and fragmented 4. Standard libraries - The official standard library is limited and frustrating - Other standard libraries are limited and frustrating - There is more than one standard library 5. Devs seem more interested in adding language features than making it useful to people who want to write real applications > At least Ocaml has such a great package manager As long as I'm consuming packages, it's great. Making packages is a nuisance. Go's dependency and distribution tooling isn't pretty, but at least it gets out of my way--`dep` does what I need it to do and I haven't had any problems. Still, both Go and OCaml's package management story is a far cry from Rust's Cargo. > better compiler What does this mean? Certainly not "faster" or "produces faster code" or "works better across platforms". > repl Granted, but I program in Python professionally and rarely touch the repl. I use it more often as a command line calculator than anything. If I were doing data science, I might feel differently, but for application development I don't miss it. > allocation profiler Go has had an (excellent) allocation profiler built into the toolchain for years. Besides, it's much easier to intuit about (and control) allocations in Go than it is in OCaml. If I could borrow anything into Go from OCaml, it would be generics and sum types. The rest (syntax, runtime, tooling, libraries, etc) I'll leave be.
- ernst_klim 9y ago
  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

Ocaml’s ecosystem feels much better than Go’s. At least Ocaml has such a great package manager, better compiler, repland an allocation profiler. The only thing it lacks is multicore runtime.

weberc2 9y ago

I disagree. Here are a few things about OCaml's ecosystem that are strictly worse than Go's, and which I find to be particularly frustrating: 1. Documentation. It's lacking or spread thinly across the Internet, and it's mostly low quality in my experience. 2. Windows support was dodgy last I checked. 3. Build tooling is byzantine and fragmented 4. Standard libraries - The official standard library is limited and frustrating - Other standard libraries are limited and frustrating - There is more than one standard library 5. Devs seem more interested in adding language features than making it useful to people who want to write real applications > At least Ocaml has such a great package manager As long as I'm consuming packages, it's great. Making packages is a nuisance. Go's dependency and distribution tooling isn't pretty, but at least it gets out of my way--`dep` does what I need it to do and I haven't had any problems. Still, both Go and OCaml's package management story is a far cry from Rust's Cargo. > better compiler What does this mean? Certainly not "faster" or "produces faster code" or "works better across platforms". > repl Granted, but I program in Python professionally and rarely touch the repl. I use it more often as a command line calculator than anything. If I were doing data science, I might feel differently, but for application development I don't miss it. > allocation profiler Go has had an (excellent) allocation profiler built into the toolchain for years. Besides, it's much easier to intuit about (and control) allocations in Go than it is in OCaml. If I could borrow anything into Go from OCaml, it would be generics and sum types. The rest (syntax, runtime, tooling, libraries, etc) I'll leave be.

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