14 ms·

Reflections on my first completed application in OCaml

113 points by mseri 6y ago

ahh 6y ago
For string interpolation, check out: https://github.com/janestreet/ppx_string https://github.com/janestreet/ppx_string I was just remarking to a coworker Friday how happy this made me; you get to write nice, obvious, readable string expressions with the right substitions, for ~arbitrary types.
nikitaga 6y ago
Ocaml is rock solid as a foundation, yet the ecosystem appears to be very fragmented. For example, not only does Ocaml not support unicode strings natively, there are several competing libraries offering this functionality. This is just bizarre. Why is it like this? Not unicode specifically but like, in general. Doesn't Ocaml have some kind of language improvement process?
- yawaramin 6y ago
  Yes, it does. However a lot of it is driven by long-time ecosystem contributors and they generally work somewhat behind the scenes, presenting on the progress ~annually at conferences like ICFP. Here's the latest progress report, in case you're interested: https://www.youtube.com/watch?v=E8T_4zqWmq8 https://www.youtube.com/watch?v=E8T_4zqWmq8 Now this is not the same language/community improvement system that many popular projects nowadays use, but OCaml has been stewarded in its way for a few years now, and it's something the contributors feel is sustainable given the size of the project and the resources available. About Unicode specifically, there is of course support at the library level as you mentioned (the most well-known library is Camomile), but to try to justify not including it in the language distribution itself, to a certain extent many applications just don't need it. Those that do can of course use libraries, but many (say, backend servers) don't really need to process Unicode strings, they just need to shovel bytes from point A to point B and not actually touch the contents.
  - nikitaga 6y ago
    > many applications just don't need it. Those that do can of course use libraries, but many (say, backend servers) don't really need to process Unicode strings I can't speak for actual Ocaml users, but I've personally rejected Ocaml for my user-facing webapps because of things like this. Treating unicode as something optional was fine for early 2000s, but it's really not fine today. Most user facing applications need first class support for internationalized strings much more than other stuff like Big_int that's actually implemented in Ocaml stdlib. I'm guessing the status quo works fine for existing Ocaml users, but that's kinda circular, and would explain Ocaml's limited adoption outside of its traditional niches.
    - fbsvvc123 6y ago
      Actual ocaml user here. User-facing web apps just aren’t a core application target for most people who use Ocaml, and probably won’t ever be. There are many perfectly good languages out there that address that need, so if ocaml doesn’t, so be it. Maybe I’m just in the minority - I like the fact that there are lots of languages out there, some of which choose not to cater to every possible development scenario. This is why I know lots of languages - instead of trying to apply one to every situation, I look at a situation presented to me and can go into my mental toolbox to pull the right language out for the job. I don’t see language design/implementation as a competition to acquire users. Do a job, do it well, and some subset of people will be happy - those that aren’t can move along and continue browsing the catalog of languages until they find one that meets their needs.
      - davidbrennerjr 6y ago
        are there any advantages to using OCaml for making web apps?
        fbsvvc123 6y ago
        No. You can get similar language-level benefits from languages with stronger ecosystems around web-relevant technologies. For example, F# is very close to Ocaml, but has a healthier ecosystem for web stuff.
- lmm 6y ago
  The language itself is very small and consistent and stable, and the community puts a higher value on getting things right than being consistent. So if there's a disagreement on the right way to implement something, you'll likely see multiple competing implementations, because people would rather implement their own library than use something they see as the wrong approach. Hopefully over the long term this means the best approach wins out and the ecosystem will converge on it, but with the small number of people involved this tends to be a slow process.
- throwaway894345 6y ago
  I get the distinct feeling that Ocaml’s leadership isn’t very interested in making a practical language, but rather playing with abstract type system ideas. Which is too bad because it clearly has a lot of potential. At this point, I think Rust will end up eating a lot of Ocaml’s potential market—Rust’s weakness is that memory management is harder than OCaml, but even that has become significantly easier between non-lexical lifetimes and rust-analyzer, and the pace of development of the Rust language is very fast while Ocaml moves like a glacier (still waiting on multicore!).
  - maattdd 6y ago
    Well for example in the upcoming 4.12, the core team has integrated plenty of "practical" language features (such as support for iOS/OSX ARM64, or many changes related to multicore).
    - throwaway894345 6y ago
      No doubt, but why are there still so many “standard” libraries? Where are is of the guides for building production applications? Why is the documentation so poor? How do the editor plugins compare to those for Go, Rust, etc? How familiar is the syntax to the broader body of developers? I’m not saying the Ocaml community never does anything practical; only that they don’t do enough to make their language mainstream. And maybe they don’t want their language to be mainstream—that’s perfectly fine, but that undermines all of the arguments that this or that project should be (re)written in Ocaml or that Ocaml is otherwise a better language than $x for general software development.
      - yawaramin 6y ago
        > why are there still so many “standard” libraries? There is one standard library--the one that ships with OCaml. You can use replacement libraries if you really need them--I haven't yet needed to, but for heavy-duty production use maybe one day I will. > Where are is of the guides for building production applications? Is the emphasis on 'building' here, as in 'build tool'? If so, then https://dune.build/ https://dune.build/ is what you need. If the emphasis is on 'production application', then I'm sure there are others but https://shonfeder.gitlab.io/ocaml_webapp/ https://shonfeder.gitlab.io/ocaml_webapp/ comes to mind immediately. > Why is the documentation so poor? Which documentation specifically? If you mean OCaml itself, then you should check out https://ocaml.org/ https://ocaml.org/ , it has tons of high-quality documentation. If you mean third-party libraries, then it's probably mostly a lack of tooling that publishes docs automatically, but I think this is starting to change. > How do the editor plugins compare to those for Go, Rust, etc? The OCaml Language Server and its main editor plugin (for VSCode) are nearly feature-complete. The older Merlin tooling has been used for a long time. > How familiar is the syntax to the broader body of developers? Syntax can be learned, but for those who don't want to try, there is always ReasonML syntax that uses semicolons and curly braces to make OCaml look like JavaScript. > I’m not saying the Ocaml community never does anything practical; only that they don’t do enough to make their language mainstream. It's easy to make assertions without actually knowing anything, but it's better to do the research first to back them up, instead of asking a bunch of questions ;-)
red2awn 6y ago
My biggest frustration with the Ocaml is with third-party libraries documentation. The majority of the docs are just function signatures without explanation, let alone usage examples. The language however is quite nice and the stdlib is fairly complete. Edit: Another problem I see is the (over?) reliance on PPX preprocessors. It does make a lot of tasks simpler, but it is too much magic for me personally.
- rbjorklin 6y ago
  I wholeheartedly agree with everything you said! What’s making the PPX situation even worse is that they seem to break with every new release of the compiler.
  - kdkeyser 6y ago
    I second this. I dislike the liberal usage of metaprogramming, especially in the context of a code base that you have to work on with multiple people. It adds another layer of concepts/complexity/magic that everyone in the team has to learn. With PPX, the barrier to use metaprogramming has become lower (especially compared to camlp4), resulting in most modern Ocaml codebases depending on it. But the ergonomics of the end-to-end software delivery have not really followed: the fact that PPX's break between compiler versions means that in practice, a compiler upgrade becomes a very costly thing to do. It is difficult to make the case for this in an industrial setting, where languages with almost religious backwards compatibility are common (Java, C++, even Go). For Ocaml, it is especially sad, because the core language is already quite powerful and expressive, lowering the need for metaprogramming (imo). For scenarios where code generation is needed, I prefer a separate code generation step, which produces explicit "standard" code (e.g. like protoc)
- aldanor 6y ago
  It's funny that I could say the opposite about Rust if you asked what I enjoy most about the ecosystem - many third party libraries have outstanding documentation. Wonder why is that - in the end, it's just some folks like you and me spending their free time writing those. Why is it different for different languages then, is it the tooling like rustdoc and docs.rs or just the standards set by the community? Not sure.

113 points by mseri 6y ago

ahh 6y ago

For string interpolation, check out: https://github.com/janestreet/ppx_string https://github.com/janestreet/ppx_string I was just remarking to a coworker Friday how happy this made me; you get to write nice, obvious, readable string expressions with the right substitions, for ~arbitrary types.

nikitaga 6y ago

Ocaml is rock solid as a foundation, yet the ecosystem appears to be very fragmented. For example, not only does Ocaml not support unicode strings natively, there are several competing libraries offering this functionality. This is just bizarre. Why is it like this? Not unicode specifically but like, in general. Doesn't Ocaml have some kind of language improvement process?

yawaramin 6y ago
Yes, it does. However a lot of it is driven by long-time ecosystem contributors and they generally work somewhat behind the scenes, presenting on the progress ~annually at conferences like ICFP. Here's the latest progress report, in case you're interested: https://www.youtube.com/watch?v=E8T_4zqWmq8 https://www.youtube.com/watch?v=E8T_4zqWmq8 Now this is not the same language/community improvement system that many popular projects nowadays use, but OCaml has been stewarded in its way for a few years now, and it's something the contributors feel is sustainable given the size of the project and the resources available. About Unicode specifically, there is of course support at the library level as you mentioned (the most well-known library is Camomile), but to try to justify not including it in the language distribution itself, to a certain extent many applications just don't need it. Those that do can of course use libraries, but many (say, backend servers) don't really need to process Unicode strings, they just need to shovel bytes from point A to point B and not actually touch the contents.
- nikitaga 6y ago
  > many applications just don't need it. Those that do can of course use libraries, but many (say, backend servers) don't really need to process Unicode strings I can't speak for actual Ocaml users, but I've personally rejected Ocaml for my user-facing webapps because of things like this. Treating unicode as something optional was fine for early 2000s, but it's really not fine today. Most user facing applications need first class support for internationalized strings much more than other stuff like Big_int that's actually implemented in Ocaml stdlib. I'm guessing the status quo works fine for existing Ocaml users, but that's kinda circular, and would explain Ocaml's limited adoption outside of its traditional niches.
  - fbsvvc123 6y ago
    Actual ocaml user here. User-facing web apps just aren’t a core application target for most people who use Ocaml, and probably won’t ever be. There are many perfectly good languages out there that address that need, so if ocaml doesn’t, so be it. Maybe I’m just in the minority - I like the fact that there are lots of languages out there, some of which choose not to cater to every possible development scenario. This is why I know lots of languages - instead of trying to apply one to every situation, I look at a situation presented to me and can go into my mental toolbox to pull the right language out for the job. I don’t see language design/implementation as a competition to acquire users. Do a job, do it well, and some subset of people will be happy - those that aren’t can move along and continue browsing the catalog of languages until they find one that meets their needs.
    - davidbrennerjr 6y ago
      are there any advantages to using OCaml for making web apps?
      - fbsvvc123 6y ago
        No. You can get similar language-level benefits from languages with stronger ecosystems around web-relevant technologies. For example, F# is very close to Ocaml, but has a healthier ecosystem for web stuff.
lmm 6y ago
The language itself is very small and consistent and stable, and the community puts a higher value on getting things right than being consistent. So if there's a disagreement on the right way to implement something, you'll likely see multiple competing implementations, because people would rather implement their own library than use something they see as the wrong approach. Hopefully over the long term this means the best approach wins out and the ecosystem will converge on it, but with the small number of people involved this tends to be a slow process.
throwaway894345 6y ago
I get the distinct feeling that Ocaml’s leadership isn’t very interested in making a practical language, but rather playing with abstract type system ideas. Which is too bad because it clearly has a lot of potential. At this point, I think Rust will end up eating a lot of Ocaml’s potential market—Rust’s weakness is that memory management is harder than OCaml, but even that has become significantly easier between non-lexical lifetimes and rust-analyzer, and the pace of development of the Rust language is very fast while Ocaml moves like a glacier (still waiting on multicore!).
- maattdd 6y ago
  Well for example in the upcoming 4.12, the core team has integrated plenty of "practical" language features (such as support for iOS/OSX ARM64, or many changes related to multicore).
  - throwaway894345 6y ago
    No doubt, but why are there still so many “standard” libraries? Where are is of the guides for building production applications? Why is the documentation so poor? How do the editor plugins compare to those for Go, Rust, etc? How familiar is the syntax to the broader body of developers? I’m not saying the Ocaml community never does anything practical; only that they don’t do enough to make their language mainstream. And maybe they don’t want their language to be mainstream—that’s perfectly fine, but that undermines all of the arguments that this or that project should be (re)written in Ocaml or that Ocaml is otherwise a better language than $x for general software development.
    - yawaramin 6y ago
      > why are there still so many “standard” libraries? There is one standard library--the one that ships with OCaml. You can use replacement libraries if you really need them--I haven't yet needed to, but for heavy-duty production use maybe one day I will. > Where are is of the guides for building production applications? Is the emphasis on 'building' here, as in 'build tool'? If so, then https://dune.build/ https://dune.build/ is what you need. If the emphasis is on 'production application', then I'm sure there are others but https://shonfeder.gitlab.io/ocaml_webapp/ https://shonfeder.gitlab.io/ocaml_webapp/ comes to mind immediately. > Why is the documentation so poor? Which documentation specifically? If you mean OCaml itself, then you should check out https://ocaml.org/ https://ocaml.org/ , it has tons of high-quality documentation. If you mean third-party libraries, then it's probably mostly a lack of tooling that publishes docs automatically, but I think this is starting to change. > How do the editor plugins compare to those for Go, Rust, etc? The OCaml Language Server and its main editor plugin (for VSCode) are nearly feature-complete. The older Merlin tooling has been used for a long time. > How familiar is the syntax to the broader body of developers? Syntax can be learned, but for those who don't want to try, there is always ReasonML syntax that uses semicolons and curly braces to make OCaml look like JavaScript. > I’m not saying the Ocaml community never does anything practical; only that they don’t do enough to make their language mainstream. It's easy to make assertions without actually knowing anything, but it's better to do the research first to back them up, instead of asking a bunch of questions ;-)

red2awn 6y ago

My biggest frustration with the Ocaml is with third-party libraries documentation. The majority of the docs are just function signatures without explanation, let alone usage examples. The language however is quite nice and the stdlib is fairly complete. Edit: Another problem I see is the (over?) reliance on PPX preprocessors. It does make a lot of tasks simpler, but it is too much magic for me personally.

rbjorklin 6y ago
I wholeheartedly agree with everything you said! What’s making the PPX situation even worse is that they seem to break with every new release of the compiler.
- kdkeyser 6y ago
  I second this. I dislike the liberal usage of metaprogramming, especially in the context of a code base that you have to work on with multiple people. It adds another layer of concepts/complexity/magic that everyone in the team has to learn. With PPX, the barrier to use metaprogramming has become lower (especially compared to camlp4), resulting in most modern Ocaml codebases depending on it. But the ergonomics of the end-to-end software delivery have not really followed: the fact that PPX's break between compiler versions means that in practice, a compiler upgrade becomes a very costly thing to do. It is difficult to make the case for this in an industrial setting, where languages with almost religious backwards compatibility are common (Java, C++, even Go). For Ocaml, it is especially sad, because the core language is already quite powerful and expressive, lowering the need for metaprogramming (imo). For scenarios where code generation is needed, I prefer a separate code generation step, which produces explicit "standard" code (e.g. like protoc)
aldanor 6y ago
It's funny that I could say the opposite about Rust if you asked what I enjoy most about the ecosystem - many third party libraries have outstanding documentation. Wonder why is that - in the end, it's just some folks like you and me spending their free time writing those. Why is it different for different languages then, is it the tooling like rustdoc and docs.rs or just the standards set by the community? Not sure.