Similar to the Rust #2020 campaign I want to ask - what you do you expect from 2020 to bring for the OCaml community?
6 Likes
The biggest thing I wish for is more stability, in several ways (which afaik are realistic):
- a stable
ppxinterface with an AST that isn’t dependent on OCaml’s version - dune continuing being amazing and staying at 2.0
- a new release of opam2 with native support for lockfiles (something like that seems to have been merged in march 19, but there hasn’t been a new release yet — I’d be happy to hear more about that from knowledgeable people)
- a commitment of the ecosystem to adopting a thoughtful approach to dependencies and stability as well.
More uniform and integrated tooling is also an exciting development: ocaml-lsp will improve beginner experience and make it possible for languages implemented in OCaml to provide decent tooling; the proposed library linking API is quite exciting; opam-ci is getting more checks thanks to @kit-ty-kate and others.
Lastly, I think we’re about to get better tools for building UIs, be it in terminals or graphical interface form.
On a more personal side, I’d like to release containers 3.0 some time this year 
and continue working on making Imandra awesome!
19 Likes
Some things that I’d like to see are:
-
A consolidation from the community around the tools that seem to work: dune, odoc, mdx, ocamlformat, lsp, merlin. A deprecation of tools that can no longer be recommended is sorely needed as well. I’d rather the community to focus our efforts on here.
-
On the other hand, I would like to see more experimentation around package management. As good as opam is, it fails me in a few key ways: project local sandboxing, reproducible builds. Additionally, a decentralized packaging workflow seems like something much more important to me than it seemed before. It’s too often the case that the world seems to be blocked by some PR in opam-repository. The current tools make it too hard to make progress on your own work and require one to always wait for someone’s approval.
-
I’d like us to put more effort into writing portable software. It’s so much easier now with dune and libraries like base & async don’t really have an excuse to at least work on Windows. One thing that’s still lacking here is package management and CI. Hopefully 2020 will be the tipping the point.
16 Likes
Interesting … does async work under Windows and BSD? Would be nice if true.
Async doesn’t work on windows yet. Relevant pieces from Async_kernel’s repository
Async_kernelcontainsAsync's core data structures, likeDeferred.Async_kernelis portable, and so can be used in JavaScript using Async_js. In principle it could also be used on Windows, but no scheduler has been written for Async on Windows as of yet.
What about BSD, i.e. openbsd? Is this supported?
I haven’t tried openbsd, but async worked fine for me on freebsd. I tried the v0.13 version on Freebsd 12.1
1 Like
It works in general on various UNIX flavors. I use it routinely on mac, for example.
y
Maybe the finish of the “Real World OCaml” 
1 Like
Very interested to hear more about this!
i don’t expect it in 2020, but i would dearly wish to be able to cross-compile lablgtk apps into windows and macos binaries from within linux. i tried opam-cross-windows some months ago but it was fiddly and i didn’t have much luck getting it working (i didn’t try especially hard, but i definitely spent a few hours on it).
I usually “cross-compile” my OCaml apps for Windows by the awesome OCaml for Windows distro, which is based on Cygwin (but compiles to “native” Windows). I also managed to build some (very basic) UI apps with lablgtk. Cross-compiling from Linux would be cool, especially when using WSL (“Bash for Windows”).
1 Like
The beta of opam 2.1 should come around February and lockfiles will of course be a part of it. Happy to know it made it to your wishlist (it’s on mine too).
4 Likes
I hope the RISC-V and MIPS ports will be merged one day:
1 Like
The greatest thing would be ocaml_odbc lib under cygwin on windows.
I wish for
- Good resources for beginners/intermediates
- Solid backend framework for writing APIs and GraphQL endpoints.
I am working on my OCaml skills lately and the language is really nice. I also hope to start seeing job ads for OCaml, right now they are almost non-existent.
4 Likes
Hello, regarding the RISC-V port, this was discussed in the last developer’s meeting and it was agreed to upstream it. The only thing missing to get the process started is to plug a RISC-V board into the CI infrastructure so that testing can take place. Once that is done (hopefully in the next few weeks), a PR with the backend will be submitted to the upstream repository.
3 Likes
especially about “reproducible builds”, I’m curious what you mean – how does opam “fail” in this respect?
I still think it is a feature to not accept any package which may not even compile (see python / npm / …), but have a CI, linting, and human eyes to look at the submission (thinking about typo-squatting and similar threats).
4 Likes
I can relate my experiences here: Opam local switches seem pretty heavy-weight
In fact since then I’ve been using Esy quite a lot and, it really shines at allowing fast iteration and experimentation. E.g., tonight I switched between different branches of a project locally and tried out different different sets of dependencies to try to track down a bug. Esy cached the builds of all these dependencies, with different versions, and let me switch back and forth and run them instantly.
As far as I can tell opam local switches are per-directory (please correct me if I’m wrong here) so switching branches like this would, first of all, require remembering to also use the correct opam switch, and then trigger a re-download and rebuild of all deps each time. Although I suppose I could start up a new clone or git worktree for the experiment branch. Point is there would be added friction here.
About typo-squatting, I really like npm’s approach (now adopted by Clojure officially I believe) of having a ‘scope’ namespace, with user or organization name being the scope. So under this system even if someone is typo-squatting a name you like, it would still be scoped to their username, and you could use the same project name under your username, and users would tell them apart based on the username/org name.
1 Like