OCaml build tools: What would you change?
Having a coherent OCaml toolchain distribution.
Improve cross compilation experience
more integration, e.g. Rust's cargo style
tools are complex, evolve rapidly : better explained, small, self-contained examples of different use cases would greatly help!
you need a proper build system and package manager: the compiler cli is more uncomfortable than gcc
I'm dreaming about better support of camlp5 in the merlin/ocaml-lsp
Make tooling more intutive, similar to rust's tooling
Add more examples-based doc to dune and opam
(not sure if this question just refers to build tools or all of the above) a decent debugger is sorely missing, several of the OcamlPro projects (multicore, unboxed data) are very urgent
I’d like better documentation and examples for cross compilation with dune.
Windows support for libraries; ocamlbuild;
Dune: allow an easy way to extend the expect-test + dune promote workflow with the tests and expected input/output written into separate files (e.g. test1.in, test1.expected) - managing dependencies to get this to build and work correctly is quite tricky. Opam: recently asked me to update and when I did, completely broke my Merlin-Vscode IDE integration. (For some reason, all my packages were uninstalled in the update process - ??). I think the overall experience with tools like opam and dune can be very patchy and issue-prone e.g. Dune seg-faults semi-regularly.
Better integration with RPM, i.e. different build and install paths.
Cross-compilation could be easier.
One big problem is that two versions of the same library cannot cohabit. And another problem is that there is no official tooling, only a de facto one.
merge dune, opam, make, etc. config files
Ship the jane street standard library with ocaml?
Improve documentation. More examples and tutorials
Native Windows Support
Strongly deprecate everything but Dune.
my impression is that building small tools (<1kloc) with library dependencies has quite an overhead. dune / custom makefiles are overkill and keeping .merlin / .ocamlinit updated to run scripts via #use in utop is a bit cumbersome as well. a simplified dune setup for such cases would be awesome. but it's not so much of a problem that i'd use a different language instead.
- I would initiate an Install project along the lines of Opam and Dune. I don't think this has been a priority for the OCaml community because Opam and Dune emerged from meeting the needs of the community, esp. JaneStreet, all of whom already have OCaml installed. (Obviously.) The putative Install project might have a menu of installation options and a single Install button. After clicking it, a person could edit, compile and run OCaml programs on their system. 2. Would it be possible to absorb all of the functionality of ocamlfind/findlib/topfind into the existing tools? Would it cause some problem to issue a #use "topfind" in an ocaml REPL as part of the boot process for the REPL? I think ocamlfind performs important work, but it seems wrong to have to type: > ocamlfind ocamlc ... 3. As far as the PL goes, it is obviously fantastic! Thank you all! I sometimes lament that variant symbols/constructors and field projections are 2nd class ... I assume making them first class runs afoul of type inference. I sometimes lament the ambiguity of nested match expressions.
Better documentation for opam and dune?
missing up to date .annot for vim + improve scientific support
Have the dependencies tied to the project, instead of being global and having to use switches to change versions of dependencies. (Basically like go module, ./venv in python, or stack in haskell)
Documentation of dune and especially opam is often impenetrable and incomplete. Documentation of commonly recommended libraries is often quite poor.
Improve documentation of build tools
It's horridly difficult to install on Windows.
Better documentation on how all the pieces fit together
Saner defaults (no warning as errors by default), have a real tutorial on ocaml.org, add a dune command similar to ocamlfind for quick testing without having to write dune files, make the devs listen to the community.
The stuffing of dune, ppxlib, opam and other tyranically opinionated and tightly coupled, uncustomizable software down everyone's throats. The 'adoption' is just a network effect and not a testament to the quality of the tooling.
I'd love to have a better workflow for sandboxed builds, where a given project has the source files checked out at whatever versions it needs, and Dune is building the whole thing so go-to-definition works throught the whole codebase. That, plus artifact caching, would be amazing...
Streamlined build for native and web.
I just want to stick to plain old makefiles
Ensure reproducible builds
It has gotten better, but the use case of being a distribution manager and trying to build packages from source without necessarily wanting to use opam was not well supported. I'd like this option to remain available.
Source- and binary-level backwards compatibility. Any industrial programming language takes these seriously, and it is frustrating to see how much they are ignored in OCaml development.
Too many build tools, standard libs. Hard to stay up to date
I think there were this idea of a "meta-building tools", a unique tool accepted by the community to do everything (opam+dune+merlin, etc.). Probably a good thing for beginners to have one entry point in the OCaml community.
ocaml-language-server is a fantastic step in the right direction but it's very very slow in large files. Especially ones with any sort of ppx
Windows build of Jane Street libraries
more documentation and tutorials
I would like opam switches to be as fast to create as python's virtual environments
Dune documentation is incomplete and confusing for advanced use cases, in my experience new users have hard time grasping how it works at first. The impossibility to relocate builds is a huge pain
If dune could scaffold new projects that would be wonderful.
Adopt a cargo-like tooling, by merging opam and dune
Developer tooling has really improved, but can still be lacking on Windows, especially around paths in spaces etc. Additionally, some new users seem to expect/want a VSCode style debugger. Tooling can also be a bit of a black box, so they don't know to look at dune docs etc, if using esy.
dune has been great, though I find the documentation lacking - it would have been nice to have some common recipes, instead of this: https://dune.build/examples also the documentation similar to other typical OCaml documentations make many assumptions about the users - that they would be already familiar with the terminology and other tools. from the quick start guide: https://dune.readthedocs.io/en/latest/quick-start.html ppxes, byte code, compilation flags, cppo, toplevel - these things don't speak anything to someone just trying out OCaml. they either don't have a place in a quick start or need to be introduced with links to resources where you can read more about
More focus on functional programming ideas
While dune is great, and a big step forward. The number of files becomes annoying, as they gave repetitative content (ppxs). Some kind og project wide dedinitions are fine for inhouse applications that do not care about too many dependencies. So many things to understand in dune because of legacy
Library vs package confusion
Better editor integration
I think by "OCaml tooling" you mean the open-source stuff, like dune and opam, which I have not used much. I think our internal stuff is okay, but not great either.
Ease of setting up a full-featured dev environment
focus on making dune a build + package management system (duniverse?), with proper lockfiles (cargo-style, including hash; not just the opam versions which are not immutable). Generally, more opinionated tools like dune. Too many tools is a curse, beginners should only need dune + ocaml-lsp.
Having a support of Mirage and Eliom in dune will be awesome. Having a proper library for SQL queries
add a tool like Rust’s cargo as an opinionated, all inclusive default workflow; adopt or create an official language server implementation for better editor tooling
I don’t know exactly but I have found cargo is quite easy for beginners to use and dune is confusing
Nothing, dune is just fantastic
Better monorepo support, ability to use "public" libraries in the same repository without its "private" sub-projects also being visible.
The ecosystem got too complex for me. (more documentation?)
Namespaces, esy as default tool, json in dune files, a package.json-inspired or cargo-inspired build system.
The biggest pain point for me (by far) is jumping to definition not working properly. There are a number of open GitHub issues or threads on OCaml discuss about this -- specifically that there's a problem where Merlin can't disambiguate between opam libraries that provide the same definitions (https://github.com/ocaml/merlin/issues/894) and a problem where Merlin can't jump to definitions once inside those libraries (https://github.com/ocaml/dune/issues/3276). This directly impedes people's ability to analyze and understand the libraries they want to use. It's also a nuisance that makes the whole OCaml experience feel unpolished.
dune is hard to understand and use in "strange" cases
Better support for nix, better support for bazel. More templates and tutorials for newcomers.
It would be nice to use Dune to easily build documentation for modules internal to my project, with a proper index.
We need opinionated intro material that shows new users how to get started with different kinds of OCaml projects. Defaults matter, so if we can set good examples for new and early users, it will help smooth the process of getting started and reduce a lot of early frustration users may face. Information is also scattered in lots of different locations. A user has to know about opam and dune and ocamlformat and merlin/ocaml-lsp-server and the standard library to get started with a basic development environment. A clear, friendly and centralized intro to the platform would help a lot when introducing new users to the ecosystem.
The community needs a hard reset, to become welcoming to others and alternative views. Even viewing the message boards it becomes incredibly clear that core members are often dismissive and unwelcoming.
Dune has this property where if you don't know exactly how to do the thing that you want, it'll just refuse to do anything and not even tell you that it didn't do anything
I would try to make the ecosystem easier for newcomers. I teach OCaml in some courses: my students told me that sometimes they have difficulties in understanding what tool/library is the best choice, e.g., dune vs ocamlbuild, core vs stdlib vs batteries, etc.
Remove dependencies on environment variables; add "ocaml build" as a subcommand which internally calls "opam" to install dependencies and then "dune" to build and "ocaml test" which runs unit tests. So "git clone" "ocaml build" "ocaml test" "ocaml toplevel" or similar. Tools like "opam" are great but just like "ocamlfind" before it I'd like it to be a behind-the-scenes implementation detail and not something a new user needs to remember and think about. I think "go" does a good job of this (but is bad in lots of other ways, obviously!). Another Go facility worth copying is the "Go playground" where people can run code immediately on the web. Documentation has links to the playground which is really helpful.
Editors (LSP) and build tools.
Centralize the documentation and curate core tools and recommend them on ocaml.org.
Dune sexp config to more modern format
Combine OPAM and Dune
Make the tooling easier and better. Make IDE integration much much better. Add support for things that make ocaml easier to use and write than other languages (use merlin to provide type/value holes, for example) so people get excited about something interesting and different.
Make it easier to publish opam packages, whether its update documentation to include help with cryptic messages and/or a unified build and packaging tool (drum is starting)
improve support for 'other-than-emacs'
Hope to have more articles to guide the development direction of different stages.I think the configuration of the development environment should be explicitly given on the official website. The use resources I studied are Cornell cs3110 and RWO, I think this is a good way. I hope there can be a better way to integrate learning paths.Sorry, my native language is not English
- More flexible syntax / better support for DSL development and integration (e.g. defining individual macros without having to create a whole syntax extension). 2. Less magic in the build process - dune relies on conventions that make me uncomfortable in ways that remind me of ruby in the 2000's. 3. Clear guidance from community leadership on navigating the fracture between the vanilla and Jane Street camps.
Barrier to entry is very high with regard to dev environment setup (opam, merlin, dune, ocp-indent, etc.). This could all be encapsulated, or at least very prominently documented for newcomers. Aside: Things improved dramatically with the arrival of dune/jbuilder.
I want cargo for ocaml
Dune and opam are honestly great tools, but there are some times where you hit random issues and have no idea how to proceed.
Take some cues from Go. 1. Integrate some external tools into the language. For example, deriving code from type definitions should use an easy, built-in, well-supported mechanism that has nothing to do extending the language syntax. 2. Facilitate application distribution by providing out-of-the-box cross-compilation and static linking. 3. Deprecate or mark as experimental some features of the language or stdlib that result in overly complicated and obscure code, such as various weird extensions of the original module system (first-class modules for example) 4. Namespaces. A namespace is the name of a vendor. A vendor distributes multiple libraries separately. Someone please explain that to Y Minsky and have them put all their stuff into the Janestreet namespace like a good citizen.
Being able to integrate with building other website assets (HTML pages from templates)
I would like to have : A tool to easily refactor code (variable renaming for example), and a well integrated, easy to use, debugger
Make it easier to understand the build process and its many different targets
Integrate all the tools in a Cargo like project manager
Esy helps, just need to mature
If most users can use the same build tools (dune?) then perhaps we can focus efforts and improve performance.
The last time I looked, the Dune docs were very confusing for newcomers. I spent a lot of time in the Dune docs trying to figure out relatively simple things, and eventually had to get answers elsewhere in some cases. That was a year or two ago, so maybe it's a lot better now.
I can't say tbh. I just feel like I have to "ask an adult" to help me get it up and running, every time I need to work on a project that's written in OCaml.
Need a real IDE with step by step debug, breakpoint, jump between files to inspect implementation. Tool to find all calls of a function etc...
I dislike dune syntax
D'une is not ready yet, make is pain
I write plugins for Coq, and it's becoming a pain to understand the different building tools, which are very fragile w.r.t. the specific OCaml version.
Integrated/blessed build system and package manager, a la Rust
Improve runtime (std) lib
Make it easier to cross compile between OS/Architectures
Better build caching (possibly using cloud)
Quite a lot of complexity around build tools
Being able to set dune as bluid dependency
The newcomer experience
FFI is hell. There are a basquillion different tools, and none of them have the same defaults. (Dune and -linkpkg, I'm looking at you.) The ecosystem works great if you stick only to OCaml stuff, but...
An easier to install IDE
More stable opam upgrade, better dune integration with opam, dune maturity
add refactoring tools
Work to remove fragmentation and focus on a modern toolset in all documentation and official resources ie dune, ocamlformat, merlin, opam, vscode.
Modern documentation on the current recommended tooling setups, with comparisons to other language tooling and
more references for newcomers, especially around best practices
Same suggestion as learning pain point: provide a Racket-style all in one option for new users with common libs, compiler, opam, and a basic pre-configured IDE set up to work with ocaml (like DrRacket does for Racket). Easier to get new users on board that way, less chance a problem scares them away.
I would make the tooling much more friendly towards newcomers - it can be difficult to figure out, although the OCaml lsp-server is making leaps and bounds towards this goal.
Newcomer docs: one signle fullproof tooling-oriented onboarding place
Improve the visibility of well known and tested libraries/tools (tools is ok, libraries is still missing good pointers)
I would integrate ocamlfind, opam, and dune. Having to understand three different systems to do anything is a drag.
I would like something similar to Haskell stack that uses nix-style sandboxed library installations, and where the sets of packages have been vetted for internal coherency, the way they are on Stackage.
make dune easier to understand and less obscure maybe
Less boilerplate would be nice. Better documentation.
documentation and standardization
Easier and more lightweight per-project package and dev env management
Building RPM packages is only compatible with Dune but not Opam Workflows because Opam mixes compilation and installation which is problematic for RPMs.
The opam cli is very confusing to me and I can never get it right. I mostly use esy instead but that is not complete either
make something as straightforward as the tools in rust
more basic dune example repos in an easily discoverabble spot. fleshed out a lot.
Better integration with the REPL. Easier code reloading without restarts.
Introduce more convention over configuration reducing build system boilerplate
Esy/reftmerr support for watch mode
- more documentation for dune, especially user- and beginner-oriented documentation
I'd quite like
dune @fmt to allow registering custom formatters, but that's such a minor thing.
Better support for several sub-projects sharing some source files in the same root directory
Ease the use of the ocaml top-level within the projects (dynamically load of library, improve dune compatibility
Opam and Dune are geared towards daily developers. For more casual programmers, they are hard to understand, in particular when they fail. We need many short tutorials (in the form of a curriculum?) to understand not only how but, above all why, to use their sophisticated features.
Better documentation for building projects with a syntax-based part (menhir / ppx)
A current book about dune would be very helpful.
Have more integrated and supported tooling Have more projects using dune 2 "sandboxed" workflow
maybe dune and opam should converge into one tool, like Rust's cargo
Continued development on dune to be able to handle more use-cases. Better dune/emacs integration (e.g. live build status, jumping to errors, etc.).
I find Dune's documentation a bit hard to follow. There are the quick recipies and then the formal references. But, so far, I haven't been able to understand "its essence", for example, the reasoning behind some of its design decisions. In other words, I don't feel confident enough to write a dune file in a situation not covered by the quick recipes.
Better documentation, More beginner friendly
I'd like a better debugging support.
Going from OCambuild to Dune is a terrible amount of work in many projefcts. There should be some form of feature parity and automatic conversion.
More tight integration between package manager and build system. Listing dependencies in 2 places, and under different names (needs some fiddling to figure out what to write in dune file given some opam package name) is confusing, especially for newcomers. Dune by itself is pretty awesome!
Sometimes can be hard to figure out how to do something in dune. The documentation is there, but more examples of not so common workflows would be nice. Occasionally you want to include external files or depend on external files to generate other artifacts.
Need a useful debugger--I'm reduced to print statements and endless builds in order to debug. In particular, there should be a built-in way to view data structures, to see defined global/local symbols. Handle polymorphism as well as possible (e.g. maybe let user specify type parameters at debug time). It would help to have a way to access type definitions programmatically so it's possible to write generic code to print data structures rather than having to craft a separate print routine for each data structure.
Simple, easy to write build system
better build system for large projects
Too many ways of doing the same - provide a set of good defaults
I only use dune, and for the most part it's great. It's sometimes hard to find examples for unusual use cases, e.g. running a bash script as part of a test.
Installing opam and dune is always a pain. I also found learning dune difficult. I would consider making the new user experience with these tools better
Benchmarking, refactoring, test coverage are blind spots at the moment that lack useful tooling.
It can be difficult to write your own dune file. Some tooling around that would probably be useful and make it more welcoming to newcomers.
I find it heavy to quickly build small experiments
It is still complex to build ocaml and opam/packages against an other version of the libC (tuning CFLAGS, LDFLAGS, gcc/glibc/...). Lots have been done recently but it is still a fight :) FYI We have to build/link against a very specific version of the libc, not against the system version.
Standard library is absolutely awful. Tooling lacks (language server doesn't work well).
More documentation regarding build tools.
Have a robust, and simpler alternative to Esy (Spago on Purescript is my favorite all-in-one tool so far)
Split Bucklescript and Ocaml into separate languages on the frontend
build tooling should be more unified and the documentation should be easier to follow. Sometimes is hard to figure out how to link the pieces, as they are addressed too much in separation or with old documentation sometimes.
Better support for Ocaml in better editors
dune files are weird
I wouldn't install a "secondary compiler" to install a build tool
compiler error messages can be arcane, difficult challenge to solve I know!
I wouid unify opam and dune
There are too many moving parts and manual configuration required to build. Compare this with more modern languages like Go and Rust building is simply a matter of running a single command with usually zero configuration. Every time I start a new project I need to look everything up again.
a better consensus on what to choose, and this choice must be in the manual!
Writing ppxes is too difficult. Tighter integration between opam and dune would be good. Opam is a bit lacking/confusing when used to manage dependencies for a privately used executable (where e.g. the maintainer and license fields don't make sense).
Debugger: allow to show abstract types in debug mode
- faster merlin; 2. something like typeclasses (modular implicits?); 3. support for returning multiple source locations in merlin and making this work with xref in emacs
Improve merlin (merlin-destruct is not easy to use, renaming could be improved etc)
better integration into popular IDEs
enable cross-compilation, build the compiler itself with dune, improve testing framework for the compiler itself, other compler infrastructure improvements such as modular use of compiler components via compiler-libs, clearer configuration.
use Ocamlformat in more projects (I'm not being able to use ocp-indent well in VSCode); make a basic tutorial for dune explaining under which dune-file conditions which files of the project get built etc. The dune documentation is great to look up concrete things, but not that good to start understanding dune
Dune is not customizable enough
I'm not an expert on packages in the open source world but with npm packages are installed locally in node_modules which means projects are quite idependent from each other. But with ocaml I often find myself having to recompile the whole of core or async when some dependencies change. I think (?) they are system-wide which makes it a bit annoying.
Create a cargo-like tool that embeded opam, dune, odoc and some test/benchs tools
dune needs more compatibility with tierless programming.
Intro to build tools have to present
Easier installation for e.g. ocaml-lsp
I use opam infrequently and I typically get a bit confused by the command line interface and some of the terminology when restarting using it each time. It would also be nice to support light weight switches so I could easily have them be per-project, though I think this was already being worked on when I last checked.
Focus on web more. Focus on text and video tutorials.
Make ReScript and ReasonML even better!
It would be nice to have something something like cargo where there's a simple, opinionated CLI for setting up and building projects
opam is very difficult to use. I'd rather have something like cargo.
I'd like to use bazel, since I use it with all projects in other languages, but dune is quite good, so no biggie.
The build time could be faster.
Doing float-heavy work in OCaml is a hassle
The setup of these tools is very manual, especially for new or close-to-new programmers. I recall in a college course I took ~2 years ago, I was the only one to have successfully setup Merlin and was the only one who understood the compilation model enough to add new files. This has improved with Dune, but, to my knowledge, is still difficult.
make a ocaml debugger
I'd work on adding a good debugger.
Improve compile time scaling to large projects
I would prefer if reliance on new tools (such as dune) was less mandated and less opinionated. We should have a clear separation between the core language and a diverse set of generic tooling around it. 'It only works with dune' is an incorrect and discouraging ideological shift in my opinion
Add cross compilation support
Better ergonomics around records (less namespacing noise), better solution for ad-hoc polymorphism, nicer type errors
unify the tools under one thing (like go), if possible. utop should be ocamlc repl, e.g.
I'd make it easier to make temporary edits to dependencies (aka a duniverse)
dune + opam would be more integrated, faster, and easier, with better documentation (as inspiration: Haskell's stack, Rust's cargo)
building tools, did not find a convincingly better tool than makefiles
Make dune less opinionated
Better official status for a single build system (OCaml manual points to ocamlbuild, which advises to use dune).
better support for window
faster builds? Maybe we should use dune. Better error messages.
having to use ocamlfind for one-off compiles that don't warrant something heavyweight like dune is very verbose... perhaps integrating ocamlfind into the compiler, so it's not a separate command would help
Warning and error flags are confusing. Dune has made a great job in integrating many of the tools but there are still quite a few concepts to juggle, such as ocamlfind, merlin, ocamlformat and opam.
Not sure if I would change anything.
Dune is nice but feels like it might one day collapse under its own complexity. I'm scared that we're falling into some local optimum w.r.t. build tools.
One command to run that does everything, thoroughly and clearly documented
Simplify bootstrap with the ability to install a minimal system (ocaml, ocaml + build tool, ocaml + build tool + opam, whichever can solve the problem).
Dune language is highly inconsistent and documentation often inaccurate/outdated
There needs to be clear messaging and documentation about which build tools to use and how to use them when coming from things like PHP's Composer and NPM/Yarn.
Improved editor tooling (LSP/merlin)--I know LSP is currently under development. Also, OCaml could benefit from a local-install, version-locking package management system like npm, poetry, etc.--for deterministic + declarative dependencies, instead of the global-by-default, imperative opam way. Finally, odoc is a great tool, but it would be nice to have an official documentation website for packages on OPAM; currently, every package needs to supply its own documentation website, or you're forced to build it yourself with odig/odoc--docs.mirage.io used to have pretty good docs, but that disappeared for some reason.
Dune is really quite good. I honestly wouldn't change a thing about it.
private opam repo is very hard to figure out
dune evolves really quickly, but the docs can sometimes fall out of date. (In general the docs are fairly high quality already though.)
ocaml needs full debugger
Dune solves a lot of problems in the ecosystem of building OCaml projects, but restricts the way that programs can be built and structured in ways that are incompatible with my old development workflow. Overall, it's pretty good, but it's configuration format leaves a lot to be desired, and external shell hacking is required far too often for a good build system.
Dune doesn't support packs correctly, which means we still need to use Makefiles.
start deprecating and removing things
opam on windows
People not adopting standards
Better support for static builds and C bindings generation
Standardized solution for documentation with executable tests as examples in docstrings
Simpler git clone, compile, install story from scratch
Ease building programs written in several languages (Coq + OCaml, Rust + OCaml)
Better IDE support
More tools working on Windows OS
Lockfile-style versioning with minimal opam involvement (as it's too slow). Currently I use either dune vendoring (fast but not mainstream) or opam pins (unacceptably slow)
Better support for gdb. Less churn over the years around the tools! Centralized documentation repo of every versions of every opam packages?
Better documentation and tutorials
Make a consistent language release with a standard library that people actually use and is documented. Make sure popular editors have good and equal support (emacs, vim, vscode) for all parts of the ecosystem. Define what is "idiomatic" use of the langugage and tooling. Most important: don't name executables with the DOS/Windows-extension ".exe" on non DOS/Windows platforms. Why is this so hard to fix? It signals a lot of nonchalance to newcomers. Also, it seems that all tools are single-threaded (opam).
The path to language-specific build tools is a huge mistake, that the Erlang community made with rebar3 and is turning away from. I would much prefer seeing the community adopt rules on top of ninja, that make integration into larger, multi-language projects easier.
Documentation is lacking. I am not sure if Opam (for instance) can deal with git submodules when installing my library so I cannot use it and I am also unsure how to get my project into Opam.
Would be great if there would be a build tool to compile and link in C++ code
Too many (not always working) solutions for building and deploying
Dune has been a big step forward, but it's intimidating for newcomers. The interaction between Dune and OPAM can be confusing for newcomers.
The documentation, and the standardization of the cross-plataform support.
OCaml lacks decent debugging support. OPAM lacks proper binary packages (with reproducible builds) (I know opam-bin might soon be filling that pain point)
Better documentation for corner cases where we need to invoke other tools during the process or break code into separate libraries. Examples will help illustrate. The current documentation seems like it has gaps that I could only fill in by finding a project that used dune the way I wanted to and borrowed their dune files.
dune should support eliom/ocsigen
Make opam and dune easier to use, cargo is a good example
The state of cross compilation and mobile targets is unclear.
dune should be more extensible / modular, not just a behemoth of random things that Jane Street decided needed to be supported
Dune is beautiful, s-expr pretty printing is beautiful, and then you have the language itself.
Sigh The syntax needs help.
Make dune less assumption oriented
Improve OCamlBuild, which is the most simple tool.
More documentation for the standard library.
Waiting for multicore support. I never use the object system, which, from my point of view, could be removed.
Better support for native compilation on Windows
it would be good if it was unified more
More tool/doc to develop/debug ppx extensions
I don't know --- need to try the latest build tools.
Single tool, had problems with dependencies, improved documentation
Not enough special-purpose libraries, yet way too many standard libraries with different APIs!
Intellij IDE support. Mathematica (Worfram Research product) build in OCaml (lets do it!). Keep in touch with great programmers like Leroy and ROBERTO DI COSMO, GIANAS, etc. Be able to have a job using OCaml.
Better debugger support
Better error messages
I wish Windows support was better, because unfortunately most of my PCs run Windows.
make it like Rust's cargo. There's a single tool to create projects, install dependencies, run the build, run tests, etc
Dune is pretty good as it is for my needs. Native FORTRAN support would be nice.
Dune is too prescriptive. Setting up workflows anticipated by the developers of Dune is straightforward, but custom workflows seem to need built-in support and sometimes the building blocks are missing.
See esy. It does a bunch of nice things that opam lacks. But esy is not the default used in the community. Need to converge on the best of esy and opam.
Dune works but is a weird tool. S-exp is uncommon. Needs better tutorial/docs. By not being explicit on how it considers or excludes files. The newcomer will wonder a lot. It took me quite an effort to get it right (I still don't know if I really understand it). Implicit is harder to have a good understanding... maybe I lacked a good explanation. I don't know. But I have struggled with it. Coming from JS world I am biased and in favor of JSON, YAML and now Dhall. But s-expression is weird. It is likely possible to make it friendlier to a wider audience.
I would like ocaml to be as easy to use as Cargo
merlin/language server implementations need to get a lot better.
- More sophisticated build tools, e.g., snapshot like Stackage. - Native Windows support will make it easy to support non-dev users of our applications. - Searching with types like Hoogle
More investment in utop integration in vs code
I'm incredibly happy that the OCaml community has finally settled on a definitive build system with Dune, but I find the documentation of Dune to be very lacking -- I often have to find example dune files to figure out how to do something since the official docs are either out of date or entirely missing the feature I'm searching for.
For tooling: better compiler errors.
Standardize it and make it work as expected
more low level control, unboxed stack allocs, GC scheduling, nicer profiling tools, cross-compilation, unicode strings & characters being first-class (like Go), merge ocamlfind functionality with ocaml toolchain itself for quality of life.
dune's syntax: welcome back to 70's... Cargo (Rust) shows the right direction to the future
The Dune documentation is inadequate, it only gives examples and doesn't explain how it actually works, making it difficult to customize anything.
Officially adopt one of the standard libraries (probably Containers).
The documentation! Documentation in OCaml is almost universally bad, especially for non-experts. It is dense. It assumes knowledge that the reader won't have. It explains complicated things before it has explained simple things. It is absent or not up to date. Very poor documentation is almost a tradition in OCaml.
Some examples of workflow on the official web site, using the different tool sets.
Dune could be a bit more flexible/extensible - for example, I often run into issues when building bytecode binaries specifically because the structure of dune forces me to use specific build rules.
Better orienting tooling for beginners
More doc and more "how to" examples
Beginner friendly documentation. Don't assume I am already an expert.
Just assume Nix is available by default. ;)
It would be good to have a more "automated" installation of a "reasonable" environment for beginners
official build tools but as optional
More statistical libraries
Standardize on one build tool
More documentation and example in various tools