4 ms·

Go is also known for treating developers like cattle, so, I'll take Rust's trade-off, thanks.

by couchand 5y ago

yawaramin 5y ago
OCaml is a powerful, expressive language with generics from day one, and Go-like build speeds.
- pdimitar 5y ago
  All that remains is for it to gain a build tool like mix or cargo. Futzing around with esy works but takes more time than I'm willing to regularly invest in it. Super excited about 5.00 and multicore!
  - yawaramin 5y ago
    I really go and forth on this. By separating the package manager and build tool, they leave the door open for either to be swapped out (which is what esy does, incidentally). The flexibility comes at a price of complexity, but it usually works well after climbing the learning curve.
    - pdimitar 5y ago
      I don't disagree and you're correct, the problem is that I'm usually investing 1-2h segments in playing with OCaml once every few weeks. Having 80% of that time swallowed by a build tool leaves a sour taste. :| I get what you're saying but it applies to people who already work full time with OCaml. For guys like myself who want to periodically dip their toes and make a slow and steady progress... it makes us feel we're not welcome. (Obviously we're not owed a made bed but I'm hopeful that you get my point and you wouldn't interpret it as entitlement.) A potential improvement: a very opinionated guide to esy, perhaps? I'd love to author such a guide one day (and would be delighted if somebody beats me to it).
      - yawaramin 5y ago
        I don't take it as entitlement but more as a case of expectations not matching with reality. With 1 to 2 hrs every few weeks, it's very difficult to ramp in a meaningful way with most languages. Unless they're toy languages or unless people have spent large amounts of time/money for those use cases. Perhaps you would be best off finding a fully set-up Docker image with a working installation of OCaml/opam, and connecting VSCode to that to act as your dev environment. That's how some educators are teaching it nowadays.
        pdimitar 5y ago
        Yep, agreed again. I'll invest the proper amount of hours to not only nail an automated project bootstrapping with esy which I'll then proceed to script with bash/zsh. I'll also exercise a few paths like adding an external dependency, splitting the project to a library and binary, being able to use a REPL (`utop` I think?) in the project, etc. After that's done I'll also document the entire thing. At that point that might make a good candidate for a blog post to enrich the OCaml ecosystem, too. Only after that point can I play casually with it, that's true. There's always an initial ramp-up price that has to be paid and in my case that price was higher than I wanted. I'm still willing to go through it all because I absolutely love what OCaml is in every way that I've been exposed to so far (with the exception of build tooling as already said). While I am going through this I can indeed make use of Docker images and see what they do that I failed to do before. Could be very illuminating.

Go is also known for treating developers like cattle, so, I'll take Rust's trade-off, thanks.

yawaramin 5y ago

OCaml is a powerful, expressive language with generics from day one, and Go-like build speeds.

pdimitar 5y ago
All that remains is for it to gain a build tool like mix or cargo. Futzing around with esy works but takes more time than I'm willing to regularly invest in it. Super excited about 5.00 and multicore!
- yawaramin 5y ago
  I really go and forth on this. By separating the package manager and build tool, they leave the door open for either to be swapped out (which is what esy does, incidentally). The flexibility comes at a price of complexity, but it usually works well after climbing the learning curve.
  - pdimitar 5y ago
    I don't disagree and you're correct, the problem is that I'm usually investing 1-2h segments in playing with OCaml once every few weeks. Having 80% of that time swallowed by a build tool leaves a sour taste. :| I get what you're saying but it applies to people who already work full time with OCaml. For guys like myself who want to periodically dip their toes and make a slow and steady progress... it makes us feel we're not welcome. (Obviously we're not owed a made bed but I'm hopeful that you get my point and you wouldn't interpret it as entitlement.) A potential improvement: a very opinionated guide to esy, perhaps? I'd love to author such a guide one day (and would be delighted if somebody beats me to it).
    - yawaramin 5y ago
      I don't take it as entitlement but more as a case of expectations not matching with reality. With 1 to 2 hrs every few weeks, it's very difficult to ramp in a meaningful way with most languages. Unless they're toy languages or unless people have spent large amounts of time/money for those use cases. Perhaps you would be best off finding a fully set-up Docker image with a working installation of OCaml/opam, and connecting VSCode to that to act as your dev environment. That's how some educators are teaching it nowadays.
      - pdimitar 5y ago
        Yep, agreed again. I'll invest the proper amount of hours to not only nail an automated project bootstrapping with esy which I'll then proceed to script with bash/zsh. I'll also exercise a few paths like adding an external dependency, splitting the project to a library and binary, being able to use a REPL (`utop` I think?) in the project, etc. After that's done I'll also document the entire thing. At that point that might make a good candidate for a blog post to enrich the OCaml ecosystem, too. Only after that point can I play casually with it, that's true. There's always an initial ramp-up price that has to be paid and in my case that price was higher than I wanted. I'm still willing to go through it all because I absolutely love what OCaml is in every way that I've been exposed to so far (with the exception of build tooling as already said). While I am going through this I can indeed make use of Docker images and see what they do that I failed to do before. Could be very illuminating.