Earlier quoted context omitted.
Xmake uses lua if you want to give it a try.
He did write ‘awful,’ which is a fair description of the experience of writing Lua. I don’t mean that as an insult to Lua’s creators. They seem like really smart fellows. It’s just that the language is (to my eyes, with my background) viciously ugly. And 1-based arrays, of course, are evil. It has some neat ideas, though, and it is supposed to be very easy to integrate into a project. But man, that syntax …
A better build system for OCaml
161–170 of 219 posts
Re: A better build system for OCaml
#162Earlier quoted context omitted.
Make is primarily used with C and C++. It is not commonly used in Java, Rust, Go, NodeJS, or hardly anything besides C and C++. Make is not "generally used with other languages".
Java https://github.com/openjdk/jdk/blob/master/Makefile Rust https://github.com/rust-lang/rust/blob/master/tests/run-make... Go https://github.com/golang/go/blob/master/src/runtime/Makefil... NodeJS https://github.com/nodejs/node/blob/main/Makefile OCaml https://github.com/ocaml/ocaml/blob/trunk/Makefile Python https://github.com/python/cpython/blob/main/Makefile.pre.in Haskell https://github.com/ghc/ghc/blob/master…
Downstream projects in these languages do not typically use Make.
More to the point, I clicked on the Go one, and it's just including this tiny "Make.dist" file that does nothing except invoke "go tool": https://github.com/golang/go/blob/master/src/Make.dist
Wow. So useful.
I clicked on the Rust one, and not only did it seem to be specific to some old testing infrastructure, but I found this note:
> There are two kinds of run-make tests:
> The new rmake.rs version: this allows run-make tests to be written in Rust (with rmake.rs as the main test file).
> The legacy Makefile version: this is what run-make tests were written with before support for rmake.rs was introduced.
So, it's an obsolete system that is being migrated away from.
But, again, the main point is that what the toolchain does with its free time has little to do with how end user applications are developed, and the complaints in this thread were strictly about building applications in distros, not about building toolchains.
If an application in one of these languages uses make, it is typically just a little syntax sugar around the toolchain commands, which does absolutely nothing to absolve the project of the complaints Linux distro maintainers have about how dependencies are managed.
Re: A better build system for OCaml
#163Earlier quoted context omitted.
We used them at Bloomberg.
Could you comment on -- How is the design of the APIs? How stable are they? Does Jane Street respond to bug reports/pull requests (if any) quickly?
I worked on Bloomberg DLIB which is basically an implementation of https://www.cs.tufts.edu/~nr/cs257/archive/simon-peyton-jone...
Re: A better build system for OCaml
#164Dune is the single best name of a build system out there, nothing even comes close to.
Re: A better build system for OCaml
#165Earlier quoted context omitted.
The whitespace is the visual cue. But in any case, you can use curly braces and semicolons in Haskell just fine. You can also write your Haskell like Lisp, and add lots of parens everywhere, and use all operators in prefix-form.
Well there's apparently a not insignificant amount of Haskell at the new job I'm starting in a week, so I guess I'll see how I fare with it.
Re: A better build system for OCaml
#166Dune's crash message: > I must not segfault. Uncertainty is the mind-killer. Exceptions are the little-death that brings total obliteration. I will fully express my cases. Execution will pass over me and through me. And when it has gone past, I will unwind the stack along its path. Where the cases are handled there will be nothing. Only I will remain.
Re: A better build system for OCaml
#167Whenever I see posts from Janestreet blog I laugh inside thinking how working on the financial industry at Jane is probably more fun and rewarding than some 90% of the jobs in the so-called tech industry.
Anecdote which doesn't prove anything but I have a colleague who left JS to work in FAANG after 6 months because working there was just too boring in his opinion (despite a higher salary). Also, it's apparently significantly harder to land a position at JS than at a Google/Meta. Actually, I applied there a while ago, the interviewer was actually pretty unpleasant, which hasn't happened to me at big tech. Didn't leave…
It was probably the first and only time I would have rather have been ghosted lol
Re: A better build system for OCaml
#168Earlier quoted context omitted.
Too bad they didn't use their namesake: https://mercurylang.org/ Would honestly be a lot more interesting than Haskell.
Anyone coding Mercury out there?
Re: A better build system for OCaml
#169Earlier quoted context omitted.
Xmake uses lua if you want to give it a try.
He did write ‘awful,’ which is a fair description of the experience of writing Lua. I don’t mean that as an insult to Lua’s creators. They seem like really smart fellows. It’s just that the language is (to my eyes, with my background) viciously ugly. And 1-based arrays, of course, are evil. It has some neat ideas, though, and it is supposed to be very easy to integrate into a project. But man, that syntax …
Re: A better build system for OCaml
#170Earlier quoted context omitted.
Could you comment on -- How is the design of the APIs? How stable are they? Does Jane Street respond to bug reports/pull requests (if any) quickly?
Alas, I last worked there in late 2017 (or 2016 or so?). I don't recall these details. I worked on Bloomberg DLIB which is basically an implementation of https://www.cs.tufts.edu/~nr/cs257/archive/simon-peyton-jone...