[HN Gopher] Oxidizing OCaml: Locality
___________________________________________________________________
Oxidizing OCaml: Locality
Author : amatheus
Score : 173 points
Date : 2023-05-27 13:46 UTC (9 hours ago)
(HTM) web link (blog.janestreet.com)
(TXT) w3m dump (blog.janestreet.com)
| Decabytes wrote:
| Is 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?
| xixixao wrote:
| 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 "call to a with
| functions b and c with unknown arguments". I need to read all
| three (a, b, c) to really get what's going on.
|
| This was my biggest gripe with OCaml as it was used at FB.
|
| (purely syntactically compare this to `a(parent => b(parent),
| child => c(child))`, for some verbosity I get a clearer syntax
| - a is the callee, and I got some information about what b and
| c possible do - this is a contrived example of course).
|
| 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).
| hardwaregeek wrote:
| Yeah I think it's kind of like how pg wrote about how using
| lisp gave him a disproportionate advantage. Sure, when people
| used fewer dependencies and the alternatives were C++, Python
| v1, and Perl, but these days a lot of languages have Lisp
| features and the cost of using a niche language is worse
| dependencies and tooling.
| yawaramin wrote:
| Readability is very subjective and also people get used to
| syntax. Elm is widely considered to be one of the most
| readable syntaxes by its users.
| faitswulff wrote:
| 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
| steveklabnik wrote:
| 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.
| carlmr wrote:
| Rust is its own father? I think the borrow checker will
| make this difficult.
| riwsky wrote:
| Just need support for recursive lifetimes
| steveklabnik wrote:
| Lol, oops: I meant OCaml, if that wasn't obvious.
| cpeterso wrote:
| OCaml is quite literally a parent of Rust since the
| original Rust compiler was written in OCaml. (I know you
| know that; I'm just highlighting how apt the analogy was.
| :)
|
| https://github.com/rust-
| lang/rust/tree/ef75860a0a72f79f97216...
| moonchrome wrote:
| Disclaimer : I didn't try Ocaml (weird numeric operators turned
| me off of it a decade ago) but I did use F# which is supposedly
| similar.
|
| But I don't know what you mean by imperative - for loops and
| stuff ? Most languages these days support functional
| programming concepts. Unless you're coming from C it shouldn't
| be that groundbreaking.
|
| Note that Ocaml isn't lazy by default like Haskell - now that
| makes things... interesting I guess.
| yawaramin wrote:
| You could always try it out and see for yourself :-)
|
| Here's a pretty good article about the transition:
| https://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-re...
| evmar wrote:
| My understanding is that Go does a similar kind of optimization
| (where locals that don't escape don't go on the heap) but it does
| it automatically. This has the positive that you don't need
| annotations but the negative that you can assume some code is
| benefitting from the optimization when it isn't and there's no
| warning about it.
|
| I'm curious whether the authors here considered this. I didn't
| see any discussion of related work in the post.
| georgyo wrote:
| My reading seems to be that the compiler can and will do it
| automatically.
|
| The annotations make enforcement. It's easy to make the
| compiler put something on the heap by accident.
| ianthehenry wrote:
| From the post:
|
| > Even without explicit mode annotations, the compiler can
| statically determine which variables may escape their enclosing
| region. Such variables are assigned the global mode; all others
| are automatically inferred to be local.
|
| There's a little more info about mode inference in the
| proposal:
|
| https://github.com/ocaml-flambda/ocaml-jst/blob/main/jane/do...
|
| So arguments to "public functions" do require explicit
| annotations in order to be local, but otherwise the compiler is
| able to infer locality and this acts as a transparent
| optimization.
| malkia wrote:
| I'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!
| [deleted]
| pjmlp wrote:
| This the best way, productivity of automatic memory management,
| and low level features for when that extra performance actually
| makes a difference.
| hardwaregeek wrote:
| I've been critical of OCaml, but I gotta hand it to them, it does
| feel like the language is going through a renaissance. It'll be
| interesting if 5-10 years down the line it manages to
| significantly improve the usability story while also adding on
| modes and unboxed types. I'm more focused on usability but these
| features are compelling too.
| daxfohl wrote:
| Seems like nim could be a good replacement? GC when you need it
| and explicit control when you need that.
| amelius wrote:
| From the article:
|
| > Ideally, a language could provide a spectrum of allocation
| strategies freely interoperable within a single application.
| With modes, users can write OCaml with all the usual GC
| guarantees--but when performance is paramount, opt into the
| consideration of lifetimes, ownership, and concurrency.
| nerdponx wrote:
| Nim is such a nice language, I would really love to see some
| high-visibility corporate adoption for it.
| dlahoda wrote:
| where it fits? it feels languages are alive as soon as it
| fits somewhere. rust and zig for example. seems roc or bosque
| too. go and ts had fit into some industry slot.
|
| where nim fits? how it can compete with other new fits and
| other old?
| geodel wrote:
| I think it is not getting enough usage because a lot of
| people love that _others_ should adopt it first.
| nerdponx wrote:
| I can sneak it into a few scripts here and there at work,
| and I can write my side projects in it, but there's only so
| much I can do.
| yawaramin wrote:
| Not for Jane Street. They likely have millions of lines written
| in OCaml and rely heavily on its type system safety guarantees.
| [deleted]
| Laaas wrote:
| I believe this is an explanation (part of) of this proposal:
|
| https://github.com/ocaml-flambda/ocaml-jst/blob/main/jane/do...
| ReleaseCandidat wrote:
| 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...
| TheNumbat wrote:
| Yes - upcoming posts will cover the uniqueness and data-race-
| freedom designs.
| yafbum wrote:
| 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?
| lpw25 wrote:
| 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 have
| access to the entire code base where the features are deployed,
| we can even change concrete syntax relatively easily. So by
| developing internally, releasing internally, and then
| upstreaming with experience, we can be more confident that the
| feature design is correct.
|
| 2. We get a faster turnaround between idea conception and
| internal deployment. Working solely with upstream, we would
| develop an idea, go through a long design discussion with
| upstream, implement, merge, wait for release, wait for the rest
| of Jane Street to be ready to upgrade, and upgrade. Now, we can
| implement an idea in parallel with its design, rolling it out
| internally in stages (as appropriate), and then upstream later.
| This is a big win for us, and well worth the extra time spent
| moving changes back and forth.
|
| > Why choose such an obscure word as `exclave`
|
| We discussed a lot of possible choices and eventually decided
| this was the best one. I personally think names should either
| be self-explanatory or memorable -- so that once they have been
| explained they aren't forgotten -- here we went with memorable.
| As a word, exclave also captures what is going on in terms of
| part of the parent region being contained within the child
| region. `return local` was a strong contender, but it implies
| that `exclave` is always about functions -- whereas the actual
| feature is a bit more general than that. It is also a bit
| easier, when adding new keywords, if you pick a word that isn't
| used much, and `return` is used a lot.
| c-cube wrote:
| As someone from the community, I absolutely love this design
| (and blog post). It would be especially great for returning
| options, tuples, results, etc. with no overhead at all.
|
| I suppose it could also be useful to allocate int64, floats,
| and maybe even bigints on the data stack? I suppose it's more
| difficult to put C blocks like bigints or bigarrays in a
| region.
| yawaramin wrote:
| I was reading the post and thinking 'glocal' :-D
| ReleaseCandidat wrote:
| Exclave is also a (PPX - that's a kind of preprocessor for
| generating the actual code) keyword: `[%exclave]`. Using this
| avoids name clashes.
|
| See: https://ocaml.org/docs/metaprogramming
| ReleaseCandidat wrote:
| They always had their own version of the compiler:
| https://github.com/ocaml-flambda/ocaml-jst/tree/main
|
| Many of their changes have been ported to the 'official' OCaml
| compiler.
| HyperSane wrote:
| Using obscure works makes some people feel smart.
| malkia wrote:
| 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...
|
| ;)
| saghm wrote:
| Using simple words in confusing contexts also makes people
| feel smart. Essentially any way of being technically
| correct in confusing ways has this effect; "I'm so much
| smarter that you can't even understand _why_ I'm right" is
| too juicy a flex for some people to avoid.
___________________________________________________________________
(page generated 2023-05-27 23:00 UTC)