Frustrations with the OCaml ecosystem while developing a synthesizer library
1–10 of 28 posts
Re: Frustrations with the OCaml ecosystem while developing a synthesizer library
#2Sounds very relatable coming from c++. Managing dependencies is generally not too fun, it's very easy to waste a whole day (or more) fighting with the build system/package manager/linker. I like to think it's the tools but then you see a really smart c++ developer and that excuse starts to sound a little weak. It seems c and c++ attract a relatively high average percentage of developers who are willing to go learn the ins and outs of build systems and how compilers and libraries all interact.
I'm curious about the happy path of ocaml vs c++, I'm not sure how much of a happy path there even is in c++. I guess if every dependency uses the same build system as the main project, maybe that's a happy path? Hard to call cmake a happy path though, more so just a tolerable path. Conan sounds nice in theory but my experiences do not match the hopes I had. I remember golang dependencies not being too bad when I tried it, really need to mess around with rust a bit to see what that's like too since I hear so much good about it.
Re: Frustrations with the OCaml ecosystem while developing a synthesizer library
#3Sounds very relatable coming from c++. Managing dependencies is generally not too fun, it's very easy to waste a whole day (or more) fighting with the build system/package manager/linker. I like to think it's the tools but then you see a really smart c++ developer and that excuse starts to sound a little weak. It seems c and c++ attract a relatively high average percentage of developers who are willing to go learn th…
The article mentions this a bit, but the Happy Path in OCaml is pretty nice. I typically don't run into any of these issues because I'm not trying to use C/C++/Rust libraries in esoteric ways. I've successfully used binding libraries for OpenSSL, libcurl, SQLite, and Postgres. It's fairly simple to get run-of-the-mill C libraries working in OCaml.
Re: Frustrations with the OCaml ecosystem while developing a synthesizer library
#4Not really with OCaml so much as with using native libraries from OCaml. Which is an awkward thing in many languages, especially if you want it to be cross-platform as this author does.
Re: Frustrations with the OCaml ecosystem while developing a synthesizer library
#5Sounds very relatable coming from c++. Managing dependencies is generally not too fun, it's very easy to waste a whole day (or more) fighting with the build system/package manager/linker. I like to think it's the tools but then you see a really smart c++ developer and that excuse starts to sound a little weak. It seems c and c++ attract a relatively high average percentage of developers who are willing to go learn th…
The biggest problem in C++ always comes from the fact that the there's no underlying stable ABI to take care of everything (and there cannot be due to performance reasons), and that build options are so important and affect the ABI. Most C++ projects are inherently multi-language system and bring the complexity of all languages to their build systems.
Re: Frustrations with the OCaml ecosystem while developing a synthesizer library
#6Sounds very relatable coming from F#.
Re: Frustrations with the OCaml ecosystem while developing a synthesizer library
#7I think the author's problem was using dune at all. It's a very weird and obscure tool, and not necessary, you can just run ocamlopt commands from existing build systems (like autotools, meson etc).
I've used OCaml in production for 2 decades without ever needing to use dune, opam etc.
Re: Frustrations with the OCaml ecosystem while developing a synthesizer library
#8I think the author's problem was using dune at all. It's a very weird and obscure tool, and not necessary, you can just run ocamlopt commands from existing build systems (like autotools, meson etc). I've used OCaml in production for 2 decades without ever needing to use dune, opam etc.
Whenever I ran into trouble (up until ~2019) with dune I would first get it to work with (ocamlfind) ocamlopt, look what the lowest level needed to look like, and then reverse engineer to make dune spit out the same thing. I would hope things have improved since
Re: Frustrations with the OCaml ecosystem while developing a synthesizer library
#9OCaml itself is built with Makefiles, which just works.
Coq has used various new tools over the years and at times has been more difficult to build than 15 years ago. With OCaml-5 the situation seems to have gotten better: At least the infamous caml4p problem was solved, and I "only" had to fix a wrong ocamlfind config file that was installed by default.
ocamlbuild is generally good, but Dune and Opam are a black box that is simply often broken. I wish more mature projects switched to Makefiles, which despite all the hate for them are always the most reliable build way.
But OCaml-5 is so great that all of this is minor bickering! It is confusing for beginners though.
Re: Frustrations with the OCaml ecosystem while developing a synthesizer library
#10I think the author's problem was using dune at all. It's a very weird and obscure tool, and not necessary, you can just run ocamlopt commands from existing build systems (like autotools, meson etc). I've used OCaml in production for 2 decades without ever needing to use dune, opam etc.
I cordially disagree. I do not find dune weird or obscure. It’s formally part of the OCaml platform: https://ocaml.org/platform, which I think negates at least the obscure bit. It was “new” to me for a hot moment, and it’s certainly a less common format for config files (s (expressions)). However, what I see is a tool that solves concrete problems that uses a declarative, structured format (not very weird). It also has pretty great docs!