Live data from Hacker News

Oxidizing OCaml: Locality

blog.janestreet.com

61–70 of 72 posts

Re: Oxidizing OCaml: Locality

#61
Interesting read.

What I would like to know is why they didn't take more direct inspiration form the "ML with Python syntax", namely Scala 3, and its "capture checking"[1].

Those OCaml "modi" look just like special cases of capture checking to me. Was that more general approach considered? And if, why was it dismissed?

[1] https://docs.scala-lang.org/scala3/reference/experimental/cc...

Re: Oxidizing OCaml: Locality

#62

Can someone explain to me why Jane Street - a trading firm - is so all in on OCaml? There's lots of other choices that would be easier to recruit for, with wider community and industry support. Where does the Jane Street commitment to Ocaml come from?

I think it started off because they needed more speed than the higher level languages like ruby and python could give them (at the time), but couldn't justify writing in a low-ish level like C/C++. I suppose they might have landed on something like Pascal or Fortran, maybe even a lisp, if they'd hired a different developer who had to make the search.

Re: Oxidizing OCaml: Locality

#64

Earlier quoted context omitted.

I think it was Steve Klabnik who said that it's basically the version of Rust with a garbage collector that people ask for. Might have been this episode of Oxide and Friends: https://oxide.computer/podcasts/oxide-and-friends/1208089

Rust was originally described to me as “Rust and C have a baby,” so yeah I’ve been a fan of this kind of thinking for a long time.

[deleted]

Re: Oxidizing OCaml: Locality

#66
post #15

Earlier quoted context omitted.

Explain std::launder then - https://en.cppreference.com/w/cpp/utility/launder - it's simple word, mostly used when talking about dirty money ;) - but hey - I've still no idea how/when/why to use it... ;)

Actually the word "launder" seems to be quite to the point given what this does. I'm not a C/C++ developer and I have to admit: For me reading anything about those languages is every time just mind-bending! (And I have a hard time not to use any curse words right now in addition). It took me over 20 minutes to understand (more or less) what this `std::launder()` does. The spec is just gibberish! So I've tried a BS ge…

Holy - the explanation you provided clicked for me! Thank you!

And I should use now `phind.com` - awesome!

Re: Oxidizing OCaml: Locality

#67

Earlier quoted context omitted.

What do you mean by “that,” specifically? A bit hard to know what exactly you’re asking.

Recursive lifetimes. The idea of the gp.

Oh gosh, so I had seen your comment on mobile, and couldn't tell who you were replying to. I thought you were asking about "OCaml and C had a baby."

I have no idea, maybe your original parent will elaborate :)

Re: Oxidizing OCaml: Locality

#68
post #19
post #7

This is a great idea, but I have questions * Is there a process for upstreaming this into the mainline language, or is this essentially JaneStML now? * Why choose such an obscure word as `exclave` to indicate return-value optimization? How about `return local` or something similarly approachable?

Our long term aim is to upstream all of our work from our branch of the OCaml compiler. Of course, that is contingent on the ideas we’re developing there being accepted by the community. There are two main reasons we work on our own branch: 1. Language design is hard. At Jane Street we have a great opportunity to design new features, test them extensively in a realistic environment, and then change them. Because we h…

> should either be self-explanatory or memorable -- so that once they have been explained they aren't forgotten

For years I've had a pet, personal theory on the hierarchy of naming; and these were my first 2 "levels". I never heard anyone else ever blurt it out in these terms. (My thought was that I was weird, or it was just so obvious that no one ever needed to.)

Re: Oxidizing OCaml: Locality

#69
post #22

Earlier quoted context omitted.

Nowadays my primary concern is readability and understandability. Thrown into a codebase, can I understand what's going on? OCaml (which at FB was used to write the Flow typechecker and Hack compiler afair) favored higher order functions. I enjoyed playing with these in my Haskel-based introduction course at university, and I even wrote a similar language that favored them. But I now heavily dislike if `a b c` means…

I'm not sure your example makes sense. `a b c` means `a(b, c)`. MLs just leaves out the parens. You can't know just form looking at `a b c` what `b` and `c` are. They may be functions of course. But also any other value. This would be exactly the same in for example JS. Nobody in JS ever complained that you can pass functions as arguments to functions and "don't see the arguments". (If you would write arguments you w…

I agree with you on TS being unsound. Flow on the other hand strove for soundness, as does Hack. Unfortunately TS dominated thanks to good strategy and some better ergonomics for open source (which were not a focus for FB).

Rust is more ML than Flow or Hack because of traits (type classes? Not sure what ML calls them or if it even has them, Haskell does). But it’s a vastly different language otherwise, so I think the “other languages have learned from ML” is more accurate description of what’s happened.

Some people write JS/TS in the ML style (point-free), but it’s not by far the most popular way. TC-39 came around to Hack-style pipelines for the same reason. For me the stylistic difference is a crucial indicator of preferences and priorities. Haskell’s operator “overuse” lives in a similar world.

Re: Oxidizing OCaml: Locality

#70

Earlier quoted context omitted.

Recursive lifetimes. The idea of the gp.

Oh gosh, so I had seen your comment on mobile, and couldn't tell who you were replying to. I thought you were asking about "OCaml and C had a baby." I have no idea, maybe your original parent will elaborate :)

I don’t understand the confusion. It’s all right there, on page 404 of the rust spec:

> Parameters with a recursive lifetime can only be used in a tail-call position within a function. If a function with only recursive params compiles successfully, it is guaranteed not to grow the stack.

For the self-recursive case, people are likely better off just writing the imperative version. But using these with mutual recursive calls lets you build safely build state machines that compile down to the same performant code a classic goto-based implementation would in C.

Post reply on HN