Jane Street Blog

Hmmm...I disagree with a number of statements in the post but I think the following two hypotheses will make for more interesting discussion than some nitpicks:

1. A large part of why many people love Rust is that it's the first time they've used an ML family language. One of the innovations of Rust was to create a community that felt like home to Unix hackers who weren't programming language nerds.

2. Rust is the first language to bring non-GC automatic memory management to the mainstream. It won't be the last and it might well be the worst. Other languages in this space include Swift (as in OP's post), OCaml[1], and Scala[2]. These alternatives take the approach that tracking ownership is not the default, which is fine for the majority of programs and far more ergonomic.

There's also a corollary

3. The age of Smalltalk is over. It's now the age of ML. (Amusingly, going backwards in time, from 1983 to 1975). The languages that dominated the 2000s (Ruby, Python, Javscript, PHP) were all more or less derived from Smalltalk (everything is an object! dynamic types! runtime metaprogramming!) The new languages (Rust, Scala, Swift, Kotlin, etc.) are ML family languages. Similarly, back in the day you could learn, say, Ruby, and still be reasonably proficient in Python or JS. Now you can learn, say, Scala, and pick up Rust or Swift reasonably easily.

[1]: https://blog.janestreet.com/oxidizing-ocaml-locality/

[2]: https://dl.acm.org/doi/full/10.1145/3618003

Go’s dependency management story is not just “not pretty” it is a total disaster as recent story with hijacked repo had shown. It does not allow proper versioning, repo management, total garbage. And how is making packages is a problem? You jast add opam file and that is all. You can do versioning, pin any opam or git repo, or even some fs resource.

Yes ocaml compiler is light years ahead Go’s one in terms of optimizations and code analysis (and even correctness [1]). It is still not as great as haskell’s one, but very good, especially with new lambda middle end. Go compiler is straightforward as hell and can’t do much inlining or optimizations that ocaml can.

Windows support was always tier 1 in compiler. Jbuilder also supports windows and even cross-compilation with windows as a target. Opam now compiles on Windows was too.

As for libraries opam now have thousands of these and ocaml libraries’ quality is often much higher than the quality of libs of this other imperative language due to quality of language.

>go standard library

lol no math for ints, no data structures beyond map, but crappy http and Json serialization.

[1] https://blog.janestreet.com/proofs-and-refutations-using-z3

Oh dear. I love F# and would really want to motivate myself to Learn me some Haskell but these sort of articles discourage me enormously.

Please, if there are any people here who have written successfully production code in Haskell that needs to have as low memory footprint as possible and be as performant as possible and have reached something like 1.5 x C level memory consumption, 0.75 x C level performance I would really be grateful for any references. I cannot wait to shed myself from the chains of C++ but stories like these, that follow patterns like these, give me the impression we're not there yet:

1. Awesome language <3 <3 <3
2. Write production code
3. Hit a mysterious performance problem (too much memory, too slow, or both)

Note: My interest is in dense computational kernels that are not I/O bound.

Edit: The language is obviously great for problems akin to syntax translation, I'm just constantly hoping someone would do something industrial strength with it and tell about it. Jane Street are extremely bullish about Ocaml (https://blogs.janestreet.com/). I've yet to face a similar perpetual love letter to Haskell as a language from industrial users.

Fully agreed with your overall position, but I got a small correction in regards to what you said about fintech.

While you are correct in that at a lot of finance companies, devs just act as "support for the real business" (e.g., Goldman Sachs). But there are others where devs and quants pretty much harmoniously run the show.

Look at something like Jane Street and their tech blog[0]. Their annual "what our interns have wrought" blog posts grab my attention like nothing else, and from everything I read coming from them, it seems like engineering there is not just "support for the real business". And there are quite a few companies in fintech like this, they just won't be flashed in the mass media due to their relatively small size, but everyone in the industry (and plenty of people on the outside) knows about them. Out of all things, they are known as one of the largest contributors to OCaml language and its ecosystem.

Jane Street was just a singular example, and there are other fintech firms of a similar engineering-focused culture.

0. https://blog.janestreet.com/

I completely agree with your take on this. If you know what a "map" is in the CS context, "mappable" makes perfect sense. Names are absolutely critical to the synthesis of knowledge, as they provide a simple symbol by which to refer to complex concepts, which gives you greater power in wielding those concepts.

---

Whenever the topic of names comes up, I reread one of my favorite blog posts I've ever come across: "What's in a Name" by Olin Shivers [0]. Here's the thesis statement:

> [My thesis advisor, Allen] Newell [...] explained his understanding of names: “They provide distal access.” That is, a name is a local piece of data that stands for some other piece of data, which is presumably large and remote. You can now use that small, convenient, local datum instead of the large, remote thing for which it stands.

(If, like me prior to reading this, you're unfamiliar with the word "distal", it means "Remote from the point of attachment or origin." [1])

[0] https://blog.janestreet.com/whats-in-a-name/

[1] https://en.wiktionary.org/wiki/distal#Adjective

The biggest change is OPAM, http://opam.ocaml.org/, a top-notch package management system that makes installing OCaml packages much easier.

Shameless plug: there's also a newish O'Reilly book, Real World OCaml http://realworldocaml.org, which I think is a big help in learning the language.

Oh, and there's OCaml Labs, a new lab at Cambridge University that's dedicated to improving the language.

And of course the compiler is constantly making progress. The upcoming 4.02 release is a pretty fun one, which I documented here: https://blogs.janestreet.com/ocaml-4-02-everything-else/ And before that, changes like GADTs and first-class modules landed, which have been quite useful extensions.

Really, it's a very active and fun community these days. The language is getting better quite quickly, but mostly in conservative and tasteful ways. The people in charge of the core language have been doing a great job, and the community infrastructure (things like OPAM) have been making big strides as well.