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?
Oxidizing OCaml: Locality
51–60 of 72 posts
Re: Oxidizing OCaml: Locality
#52Earlier quoted context omitted.
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…
This process seems to intentionally cut off upstream from having input into the design of the features during development when there's still a chance to change it. What happens when you implement something that you like, release it internally, but then it turns out upstream doesn't like it or wants it a different way? Will you maintain your feature on your fork forever (thus JaneStML), or will you abandon your featur…
Another possibility is to change the design based on upstream feedback and adjust the internal codebase to it.
By parent’s description, those codebase adjustments are done during the iterative process of feature development too. Upstreaming would just be the last iteration.
Re: Oxidizing OCaml: Locality
#53I've been listening to Signals and Threads podcast, and I remember listening to this episode - https://signalsandthreads.com/memory-management/ (I don't know neither Ocaml, nor Haskell, or any ML language), but the podcast is always fun to listen to (not only programming also) Now would relisten this, and may actually understand it!
I'm curious, which episodes are describable as "not only programming"? I ask since I can't think of one.
There was a good one about NTP and microsecond precision that had programming but was more a discussion of how hard time is to get right at great precision.
Re: Oxidizing OCaml: Locality
#54Can 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?
It lets them hire the types of people excited by Ocaml.
Re: Oxidizing OCaml: Locality
#55I've been listening to Signals and Threads podcast, and I remember listening to this episode - https://signalsandthreads.com/memory-management/ (I don't know neither Ocaml, nor Haskell, or any ML language), but the podcast is always fun to listen to (not only programming also) Now would relisten this, and may actually understand it!
I'm curious, which episodes are describable as "not only programming"? I ask since I can't think of one.
I have not been listening to them in the past but stumbled upon this episode "Multicast and the Markets" and I feel this has a lot of stuff about hardware and network than the software. Highly recommend to check it out.
Re: Oxidizing OCaml: Locality
#56Re: Oxidizing OCaml: Locality
#57Earlier quoted context omitted.
Using obscure works makes some people feel smart.
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 generator a.k.a "AI" than[1]. Together with a Stackoverflow entry[2] it finally made click.
This function "launders" pointers from compiler assumptions. It will give you a "clean", pristine pointer back, without for example the information about the concrete object attached to it previously (because for example casting an object to its base class won't give you a proper pointer to the base class; at least that's what as SO comments says… Sounds quite ill, but so is C++). It will also for example "launder" away compiler assumptions about the `const` property of an object pointer. It's needed for example when you do "in-place replacement of an object" (replacing directly the bytes in some memory area of another object). Just casting won't make the compiler "forget" where this memory came from / to which object it was once attached. So you need to launder the pointer to the new object so the compiler forgets what it assumed previously about that memory area.
But let's not talk about what it actually means when a language needs some mechanism like that… My "WTF per Minute" output just reached a new all time high, I guess.
[1] https://www.phind.com/search?cache=91e3f5ce-dde2-422e-a3eb-6... [2] https://stackoverflow.com/questions/66176720/why-introduce-s...
Re: Oxidizing OCaml: Locality
#58I believe this is an explanation (part of) of this proposal: https://github.com/ocaml-flambda/ocaml-jst/blob/main/jane/do...
It's this proposal: https://github.com/ocaml-flambda/ocaml-jst/blob/main/jane/do... and these problems: https://github.com/ocaml-flambda/ocaml-jst/blob/main/jane/do...
OT: Funny, I start to see here more and more Heise expats. Welcome @ReleaseCandidat! :-D
Re: Oxidizing OCaml: Locality
#59Re: Oxidizing OCaml: Locality
#60Is Ocaml actually good or is it a meme that people use it and become obsessed with it. How is the transition if you mostly code imperatively? Are there things that are not ergonomic for it to do like GUIs or games?
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 would actually call the function, and not pass it as a value.)
But in OCaml you have a static type-system that can tell you at any point what `a`, `b`, or `c` are! Just hover the symbol.
> I think the strength of ML and Haskell got eroded as more "mainstream"y languages got decent type systems (TS/Flow, Hack, Kotlin, even Rust, Python is getting there).
I don't think so. Especially given those examples.
TS/Flow doesn't have a sound type system. It may "type-check" fine and than explode at runtime. That's imho worse than dynamic typing as with dynamic typing you know at least that such fuck-up will happen. But TS delivers a false feeling of security about type safety where there is none.
Hack is "gradually typed" which is just another word for dynamically typed with some static checks. So not even close to MLs.
Python is also still dynamically typed, and that won't change. The bolted on type-checkers are unsound. So same situation as with TS.
Nothing can be said about Kotlin afaik, as there was no formal work on its type-system.
And Rust? Rust is a ML (with ugly C syntax)! So Rust is a prime example of how MLs are still one of the most modern and influential language designs to this day on.
With Rust and Scala you have even two MLs in the Top20 languages. If something than ML is slowly but finally approaching mainstream. Maybe not in its original form but still the tradition lives on.