This is a hasty attempt to summarise this thread with a light bit of categorisation: https://discuss.ocaml.org/t/what-are-the-biggest-reasons-newcomers-give-up-on-ocaml/10958
- Compiler errors which came up multiple times with slightly different slants from different people.
- Built-in deriving mechanisms so you get printers just from the compiler (for example)
- Syntax
- Relocatable compilers
- No docs on how to use OCaml with a REPL
- Modular Implicits
- Friction with things in the stdlib
- Example of using buffers which lead to discussion about improved docs for
In_channeletc. and also the base v stdlib discussion.
- Example of using buffers which lead to discussion about improved docs for
- No single debugging tool
- "Opam and dune should be one tool" i.e. a cargo like experience.
- Fragmentation for core libraries like HTTP
- Naming conventions for modules and packages (
opampackage names,ocamlfind, OCaml library archive and OCaml module names). - Opam specific idiosyncrasies
- Dune specific idiosyncrasies
(libraries xxxx)corresponds to- S-expressions are fine but better tooling for them/docs
- Better string manipulation support
- People would like to run OCaml from dune like cargo build.rs
- Min. 3 files for a dune project
- Dune's decision to search hierarchy upwards is confusing
- Default
devprofile treats warnings as errors and it is complicated to turn that off and it is noted that there is structured output mode which might help - No output on successful
dune runtest - No affinity for sexps, but it's a massive project to find alternative and switch. There's a long discussion after this about s-exps vs. any other format bouncing between it being obscure and a blocker and the fact that there aren't many alternatives that can meet the needs of what dune can do. Some discussion of an OCaml DSL with a 1:1 mapping
- Not great experiences with instrumentation and docs for it
- Structuring projects and namespacing
- Test libraries could be improved
- Distinguish projects that are actively maintained vs. dead
- Windows support
- Bazel support
- Formatters
- VSCode plugin
- General concepts aren't easy to find on the web
- Dune needs better "tutorial"-style documentation
- Generic, end-to-end tutorial-style documentation
- An example using dune, caqti etc.
- Centralised docs exist but we can't force beginner tutorials, but improved search is coming and jump to source
- Testable Docs which relates to MDX (which has some limitations)
- Elixir school docs
- Free-form answers in survey want docs
- Entry-point for libraries is not necessarily clear, more example-style docs but praise for centralised docs although some bugs in odoc don't help encourage people to write docs
- Document all the issues newcomers face
- Various discussions about what the community actually wants e.g. does it want to grow or sustain and thrive