Reason and BuckleScript community alone produced so many cool things that can only taken away from my cold dead hands, so I strongly disagree here. My first encounter with OCaml was through that, and ReasonReact, and everything that came after that was cherry on top. I can name lots of “killer OCaml apps” for the work I do. Just the last few commenters on this topic alone produced so many high quality and well-documented libraries I thoroughly enjoy using.
I haven’t been a part of this community long enough to have a concern about its size or direction, if there should be some. Maybe it’s because I’m used to being part of even smaller language communities with tiny industry adoption, or maybe because I’m not a person that usually thinks about things like “community building”, “growth”, “beginner-friendliness”. But still, I disagree with the alarmist attitude. I already got back so much more than my money’s worth from what little investment I’ve made learning OCaml.
edit: I’m getting off topic quite a bit, but bear in mind that I’m a newcomer who’s looking at OCaml community from outside most of the time. And I explicitly want to grow more and be a part of “the labor pool available for working on improvements” you mentioned, no matter how small it is at the moment. Because of this, I guess I’m inclined to strongly disagree with your statements and won’t get convinced of them easily 
I as well; OCaml is a very productive language to work in. That’s a reason I still use it and will continue to do so. I think, however, people often are too tribalistic about such things, and as a result, fail to look at the flaws in the projects they are associated with very realistically in favor of being supportive of their affiliation group. I think it is generally better to look at such things in a clear eyed way; it makes it easier to make rational decisions.
I don’t think this is true. If it was true, it would be possible to help resolve these cases by contributing to the triaging of issues – pinging people on PRs that fits this criterion, for example. Would you like to provide examples of such PRs? (I’m assuming that the PRs have been reviewed – otherwise of course they cannot be merged – and do not conflict with evolutions in the codebase – otherwise someone needs to fix the conflicts.)
In my personal experience, we are indeed sometimes limited by the a limited bandwidth of people doing reviews and taking actions on PRs (reviewing a proposed change with high quality standards can be a lot of work), and more contributions could of course help – note that most people doing reviews today do so on their free time, or at least instead of work they would get more recognition for; in particular it is very rare to have “please review PRs” on your job description.
There are a few cases of discussions ending up with no consensus, because we don’t know of a solution that has no downsides giving us pause. These issues can be blocked for years, and then revisited when someone comes with an idea that is clearly a big advance over the existing proposals, and then the situation can move fast. One example would be the let ... in .. with exn -> ... syntax that people have tried to propose in various forms over the years, have stalled, and were swiftly replaced by the match .. with exception ... construct which is better on all counts. But there are not “many” issues blocked in this way – fortunately it’s an uncommon situation.
I don’t mean to single it out, it just comes to mind without looking, but let-def’s patch for tail recursion mod constructor has taken a very long time. I suspect I could find more without much trouble, but I’m on my phone.
Apathy is perhaps the wrong word, but there’s definitely the appearance of “it’s okay for it to take a few years or longer”. I don’t think I would have the patience myself for that.
The tail-recursion modulo cons (TRMC) PR is #181 18, and I don’t think it fits your description. It has indeed been around for years, but the main reason is that the author has decided to work on other things than making necessary updates (which is perfectly ok, given that this is a contribution on his free time), and also that no one has stepped up to review it so far. Given that most of the delay comes from waiting on the people doing the work (the original author, or someone else willing to help; and a reviewer), I don’t see what could be done differently in our processes to make resolution faster – in particular, pressuring the authors to work more on their free time doesn’t really sound sustainable to me.
Of course we could say “if a PR looks good-in-theory but hasn’t seen much progress in a year, we close it”, and this would have been closed in a timely way, but I fail to see the benefit of that.
No that’s basically it. I mainly use rust for areas where I don’t want a GC, and/or heavy parallelism.
Honestly, as a ~30 year C++ Primary dev and a ~15 year OCaml hobby/tool dev the thing that attracts me most to Rust is the lifetime system combined with RAII can handle any resource management, unlike GC’s that manage only memory (and in a very… squishy way), basically encoding how I’ve worked with C++ for decades but baking that whole style into the language itself, it “feels” very safe and productive, I don’t have to worry about things or how things are being accessed or anything like that. It’s like taking the type safety of OCaml combining it with the resource management of C++ into a very nice union.
I mainly work on back-end servers and tiny embedded chips, only incidentally front-end stuff when I have to, and OCaml is lacking a lot in these, where C/C++ has reigned king (and quickly upcoming Rust).
My use of OCaml has mostly been for what most use Python for, making Tools to manage things with.
What I think is that’s mostly because it’s the first language that is actually drawing C/C++ devs, which is an absolutely massive ecosystem.
C/C++ absolutely HATE, like teeth-seething chair-throwing hate the C/C++ dependency management and build ecosystems (not through any fault of the languages, but just because it is long since past for any one thing to take over, there is ‘too much’), and if you notice this is where Rust is absolutely shining. C/C++ have loved autogenerated documentation (doxygen has been a long love) and this is also where Rust is shining (baked into the language ecosystem itself).
Rust is also growing as-a-language very quickly, and there are a lot of discussions around the changes made as well, this is also very nice from the usual slow-moving C/C++ improvements.
I still like the OCaml type system more, Rust is lacking very useful features in some way (which you can mostly emulate with more code), but the Uniform Resource Management patterns of RAII and lifetimes blow GC away especially as GC can’t manage sockets or files or GPU connections or anything like that properly, it’s deterministic and comfortable and expected.
I’m not actually a fan of Rust’s syntax, too much like C+±noise, I would prefer OCaml’s, but eh…
This, big time, that’s why I love making tools in it!
Recently Rust works hard towards algebraic effects 69, soundness of the trait system with Chalk 36(Prologish interpreter), asynchronous programming 15, and many other interesting things. So it might beneficial for OCaml developers to keep an eye on Rust developments.
I’m kind of surprised no one mentioned type inference yet.
OCaml will infer the most general types for almost everything (except for objects with polymorphic methods and functor arguments) whereas Rust requires much more type annotations. The extra boilerplate makes Rust more verbose and less flexible if you end up wanting to change types around.
