5 ms·

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 ~

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.
    - johnnycerberus 6y ago
      If you are interested in web apps, you should pick a platform first: * Node with TypeScript * JVM with Scala * CLR with F#
    - kdkeyser 6y ago
      ReScript (formerly called ReasonML), is an interesting option for web apps (especially the front-end part), if you are interested in Ocaml-like languages. Language-wise, it is Ocaml with a different syntax layer, so all of the nice things about the language are still available.
    - yawaramin 6y ago
      Yes, especially in the ReScript toolchain ( rescript-lang.org/ ), there are many benefits: - Super-fast compiler - Readable and succinct JS output with nearly 1-to-1 mapping from OCaml source - Simple module system with no need to explicitly import modules--the compiler takes care of it for you - High-quality React and other bindings - The standard advantages of the type system like expressive power of data types and pattern matching with exhaustivity checking - Tons of super useful built-in lints like 'unused variable', 'unused function parameter', 'discarding a value', etc.
  - brmgb 6y ago
    > User-facing web apps just aren’t a core application target for most people who use Ocaml, and probably won’t ever be. Some industrial Ocaml users use the web as a UI. I'm fairly certain Jane Street does it for exemple. That's very much user-facing web apps. I understand that it's not something that interests you but there has been plenty of work geared towards building web applications in Ocaml (and Reason). Saying it probably won't ever be a core application target seems quite wrong.
- LeonidasXIV 6y ago
  > 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. This is certainly a valid argument, but honestly most languages handling of Unicode is really poor to the point where I actually prefer OCaml's not handling it since then I can use dbunzli libraries and get stuff to work correctly. Just try reversing a Unicode string and you'll see all kind of languages "with Unicode support" fail miserably, e.g reversing 🇺🇦 into 🇦🇺. Go outside the BMP and see how nearly nobody has bothered to implement proper support for Unicode glyphs, let alone word boundaries etc. Swift might be one of the exceptions but outside of that? Bummer. Bonus points to Python 3 for breaking compatibility because of Unicode and then doing it wrong anyway.
- ronilav 6y ago
  > Treating unicode as something optional was fine for early 2000s, but it's really not fine today. The issues are: * how unicode support is implemented in third party libraries: how easy it turns out to manipulate this datatype with those libraries * how easy it is to integrate third party libraries in a project OCaml went a long way in both accounts since the early 2000s, perhaps you should give it a second look?

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.
  - johnnycerberus 6y ago
    If you are interested in web apps, you should pick a platform first: * Node with TypeScript * JVM with Scala * CLR with F#
  - kdkeyser 6y ago
    ReScript (formerly called ReasonML), is an interesting option for web apps (especially the front-end part), if you are interested in Ocaml-like languages. Language-wise, it is Ocaml with a different syntax layer, so all of the nice things about the language are still available.
  - yawaramin 6y ago
    Yes, especially in the ReScript toolchain ( rescript-lang.org/ ), there are many benefits: - Super-fast compiler - Readable and succinct JS output with nearly 1-to-1 mapping from OCaml source - Simple module system with no need to explicitly import modules--the compiler takes care of it for you - High-quality React and other bindings - The standard advantages of the type system like expressive power of data types and pattern matching with exhaustivity checking - Tons of super useful built-in lints like 'unused variable', 'unused function parameter', 'discarding a value', etc.
- brmgb 6y ago
  > User-facing web apps just aren’t a core application target for most people who use Ocaml, and probably won’t ever be. Some industrial Ocaml users use the web as a UI. I'm fairly certain Jane Street does it for exemple. That's very much user-facing web apps. I understand that it's not something that interests you but there has been plenty of work geared towards building web applications in Ocaml (and Reason). Saying it probably won't ever be a core application target seems quite wrong.
LeonidasXIV 6y ago
> 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. This is certainly a valid argument, but honestly most languages handling of Unicode is really poor to the point where I actually prefer OCaml's not handling it since then I can use dbunzli libraries and get stuff to work correctly. Just try reversing a Unicode string and you'll see all kind of languages "with Unicode support" fail miserably, e.g reversing 🇺🇦 into 🇦🇺. Go outside the BMP and see how nearly nobody has bothered to implement proper support for Unicode glyphs, let alone word boundaries etc. Swift might be one of the exceptions but outside of that? Bummer. Bonus points to Python 3 for breaking compatibility because of Unicode and then doing it wrong anyway.
ronilav 6y ago
> Treating unicode as something optional was fine for early 2000s, but it's really not fine today. The issues are: * how unicode support is implemented in third party libraries: how easy it turns out to manipulate this datatype with those libraries * how easy it is to integrate third party libraries in a project OCaml went a long way in both accounts since the early 2000s, perhaps you should give it a second look?