Live data from Hacker News

A better build system for OCaml

blog.janestreet.com

161–170 of 219 posts

Re: A better build system for OCaml

#161
post #70

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 …

1-based arrays are fully optional in Lua. You can use -2-indexed arrays instead, should you wish to.

Re: A better build system for OCaml

#162
post #160

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

This doesn't prove anything at all. Of course the toolchain has to be built somehow. Some toolchains use make to do that, rather than depending on the previous version of the toolchain's build system. Some toolchains are written in a language completely separate from their downstream language, so they obviously wouldn't be compatible with their own toolchain.

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

#163
post #146
post #119

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

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

Re: A better build system for OCaml

#165
post #121

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

Oh, what's the new job?

Re: A better build system for OCaml

#166

Dune'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.

I feel like I just got initiated into something

Re: A better build system for OCaml

#167

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

Yeah I sent an application on a whim because I've spent a lot of time in FP land professionally and otherwise, I figured "what the heck, maybe they'll see value in that," and I was surprised to actually get a response but it was dismissive and borderline insulting..."there's nothing relevant here" talking about my resume is the thing I remember the most.

It was probably the first and only time I would have rather have been ghosted lol

Re: A better build system for OCaml

#168

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

ODASE uses it: https://www.mercurylang.org/documentation/papers/mc_swese_20...

https://www.odase.io/

Re: A better build system for OCaml

#169
post #70

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 …

I kind of agree, but it's still far better than CMake's custom language IMO.

Re: A better build system for OCaml

#170
post #163
post #146

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

[dead]
Post reply on HN