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
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