Okay...so you have to add a third party library to print? Yes, recursive data structures are a pain in Rust (well, recursive multi-owner data structures). But that's like comparing changing your oil to opening your car door. We do one of these a lot more. And bear in mind, I had to find this answer by googling and reading a random forum post. That's some pretty poor documentation.
And that's not talking about aesthetics. `T.show foo` or `Foo.to_bar value` is a lot of syntactic overhead for a rather common task.
And again, these are the lesser concerns to the other ones I outlined. Reading the code, building the code, and understanding the compiler errors are the big ones.
Not really third-party; ocaml-ppx is something similar to `javax` in the Java space? But it is optional and doesn't come bundled with OCaml.
Recursive structures are only rare in Rust _because_ they suck to write and have terrible performance characteristics in the language. In languages like Haskell, OCaml and Scala using tagless initial encodings for eDSL's [2] are really, really common.
I don't write Rust like I write any semi-functional language with function composition because, well, it's _painful_ and not a good fit for the language.
> `T.show foo` or `Foo.to_bar value` is a lot of syntactic overhead
The `T.()` opens a scope so OCaml code generally looks like:
```
let foo = T.(if equal zero x then show x else "not here")
```
Even when talking about usage, each language community for better or worse has a predefined workflow in mind. Your questions and workflow are specific to a particular language; you don't, for example, ask about the REPL, the compile times, debugging macros, the cold-start of the compiler, whether hot-reloading is a thing, the debugger, how it interacts with perf, how to instrument an application. Presumably because the language you use or the programs that you make don't have those components as part of their main workflow.
A lot of these things that you mentioned are valid flaws in Rust. I'm not going to dismiss them as not important or non-problems because they are genuine issues. Compile times suck. We could use hot reloading and a REPL. Debugging macros, instrumentation and perf stuff is good, but I assume it could be better. That's what I expect from a language community. Not constant denial about the state of usability. And it really does feel like many of the smaller language communities fall into this hive-mind where type signatures are valid documentation and who needs to use an editor other than emacs?
They are genuine issues, within Rust, but the way you /categorize/ the severity of the issue is different within language communities. They don't impact usability /much/ because of Rust's community, focus, size and niche.
Compile times in Rust are a problem, but the RLS does a good enough job of feedback and the development loop happens enough in compile time, that users don't miss it enough, compared to, say, Java which relies heavily on runtime behaviour/reflection for application behaviour.
Debugging token macros could be better, such as with a better macro-stepper, but you don't write enough macros in Rust to care heavily about it to make it a big deal, unlike in a Lisp.
Hot reloading would be nice, but not and ~essential~ part of development and deployment like in BEAM. Better reflection utilities might be nice but I doubt Rust libraries will ever be heavily dependent on it in the same way that Go or Java are.
If you are referring to OCaml, many people in the community care a lot about writing good documentation so that it's not just the type signatures. In fact the OCaml website team have made amazing leaps and strides integrating package documentation directly in the website.
And the experience using OCaml LSP Server with VSCode nowadays is honestly pretty good--type annotations displayed, error messages, go to definition, generating interface files. The core functionality is all there.
That's good to hear! I don't mean to be too negative. I'm genuinely glad that OCaml is making these strides. I'm hopeful that OCaml can find its equivalent of Esteban Küber[1] and they can make the language a truly fun and friendly experience.
You don't need a third-party library to derive a pretty-printer for your types, it just makes it simpler. OCaml takes the approach that the core compiler doesn't do any codegen, that is left to PPXs (basically, middlewares which transform code) which run before the compiler.
You can write a pretty-printer yourself using the conventions of the `Format` module. Is it manual and annoying? Yeah. That's why the PPX exists. It's a tradeoff.
> `T.show foo` or `Foo.to_bar value` is a lot of syntactic overhead for a rather common task.
A lot of syntactic overhead sounds like a stretch. I suppose you could drop the `T` like you do in Haskell but I personally like my language to be a bit more explicit. It improves readability.
And that's not talking about aesthetics. `T.show foo` or `Foo.to_bar value` is a lot of syntactic overhead for a rather common task.
And again, these are the lesser concerns to the other ones I outlined. Reading the code, building the code, and understanding the compiler errors are the big ones.