8 ms·

I saw a talk by someone from Google about their experiences using Rust in the Android team. Two points stuck out: they migrated many projects from Python, so pe

I saw a talk by someone from Google about their experiences using Rust in the Android team. Two points stuck out: they migrated many projects from Python, so performance can't have been that much of a concern, and in their surveys the features people liked most were basics like pattern matching and ADTs. My conclusion is that for a lot of tasks the benefit from Rust came from ML cicra 1990, not lifetimes etc. I feel if OCaml had got its act together around about 2010 with multicore and a few other annoyances[1] it could have been Rust. Unfortunately it fell into the gap between what academia could justify working on and what industry was willing to do. [1]: Practically speaking, the 31-bit Ints are annoying if you're trying to do any bit bashing, but aesthetically the double semicolons are an abomination and irk me far more.

unstruktured 1y ago
There is absolutely no reason to use double semicolons in practice. The only place you really should see it is when using the repl.
- sigzero 1y ago
  Yeah, it makes me think he doesn't understand them in OCaml.
  - acjohnson55 1y ago
    I worked in OCaml for a year and I couldn't tell you by memory what the difference was. I remember being very annoyed by OCaml's many language quirks.
garbthetill 1y ago
doesnt rust still have the advantage of having no gc? I dont like writing rust, but the selling point of being able to write performative code with memory safety guarantees has always stuck with me
- noelwelsh 1y ago
  I think "no gc but memory safe" is what originally got people excited about Rust. It's a genuinely new capability in production ready languages. However, I think Rust is used in many contexts where a GC is just fine and working with lifetimes makes many programs more painful to write. I think for many programs the approach taken by Oxidized OCaml[1] or Scala[2] gives 80% of the benefit while being a lot more ergonomic to work with. When I see Rust topping the "most loved language" on Stack Overflow etc. what I think is really happening is that people are using a "modern" language for the first time. I consistently see people gushing about, e.g., pattern matching in Rust. I agree pattern matching is awesome, but it is also not at all novel if you are a PL nerd. It's just that most commercial languages are crap from a PL nerd point of view. So I think "no gc but memory safe" is what got people to look at Rust, but it's 1990s ML (ADTs, pattern matching, etc.) that keeps them there. [1]: https://github.com/oxcaml/oxcaml https://github.com/oxcaml/oxcaml [2]: https://docs.scala-lang.org/scala3/reference/experimental/cc.html https://docs.scala-lang.org/scala3/reference/experimental/cc...
  - GeekyBear 1y ago
    > I think "no gc but memory safe" is what originally got people excited about Rust. I think it was more about "the performance of C, but with memory safety and data race safety".
  - josephg 1y ago
    > So I think "no gc but memory safe" is what got people to look at Rust, but it's 1990s ML (ADTs, pattern matching, etc.) that keeps them there. Yeah; this is my experience. I've been working in C professionally lately after writing rust fulltime for a few years. I don't really miss the borrow checker. But I really miss ADTs (eg Result<>, Option, etc), generic containers (Vec<T>), tuples, match expressions and the tooling (Cargo). You can work around a lot of these problems in C with grit and frustration, but rust just gives you good answers out of the box.
  - voidhorse 1y ago
    Spot on. It's also fascinating to watch people have their minds blown in 2020+ by basic features that have been around since the nineties. It's kind of sad, actually. The industry would be in such a better place than it is today if so many programmers weren't allergic to all things academic and "theoretical" and were more curious and technical than they were conceited. It's baffling that computing, literally a subject area in which the theory quite literally is the practice, is so full of people who refuse to engage with theoretical work and research.
benreesman 1y ago
[flagged]
- simonask 1y ago
  This is one of the wilder conspiracy theories to me, and that says a lot in 2025.
  - benreesman 1y ago
    The RESF is not a conspiracy theory, its a known thing. Especially on HN: https://news.ycombinator.com/item?id=14178950 https://news.ycombinator.com/item?id=14178950
    - the__alchemist 1y ago
      It's real, and as someone who loves rust, it's embarrassing, and difficult to avoid. The OSS embedded rust users in particular are nuts.
      - benreesman 1y ago
        Really appreciate a fairminded Rust person chiming in. It's a disservice to the language (which is cool!), and it makes the community look bad. Rust might gain some adoption among people who are new to high performance software and see a narrative that its the only game in town, but it turns off a lot of older folks like myself who know it isn't and that community matters. gl to you and people like you trying to get it back on track!
        simonask 1y ago
        Can we be clear here: You are accusing people in this thread of "inorganically" bringing up Rust. The implication being that there is some shadowy group or organization coordinating the bombing of random forum threads to talk about Rust, or what are we saying here? Rust is an exciting language. It comes up because many people like it.
nine_k 1y ago
I'd say that Google strives to have a reasonably short list of languages approved for production-touching code. Rust can replace / complement C++, while OCaml cannot (it could replace Go instead... fat chance!). So I suspect that the team picked Rust because it was the only blessed language with ADTs, not because they won't like something with faster compile times. No way OCaml could have stolen the Rust's thunder: we have a number of very decent and performant GC-based languages, from Go to Haskell; we only had one bare-metal-worthy expressive language in 2010, C++, and it was pretty terrible (still is, but before C++11 and C++17 it was even more terrible).
- hardwaregeek 1y ago
  Wouldn’t Kotlin be a more reasonable choice in that case? It has ADTs and a lot of the same niceties of Rust.
  - actionfromafar 1y ago
    Garbage collector in Kotlin makes it a no go for C or C++ displacement.
    - pjmlp 1y ago
      As someone that has left pure C++ applications in 2006, and has mostly written mixed language projects since 1999, usually the displacement is more religious than anything else. In many use cases even if the performance is within the project delivery deadlines there will worthless discussions about performance benchmarks completly irrelevant to the task at hand. And ironically many of the same folks are using Electron based apps for their workflows.
  - Artamus 1y ago
    I'm inclined to think that the Python -> Rust was only for some odds and ends. I know the biggest recipient of Rust trainings was the Android platform team at first, which I think also used a lot of C++. Kotlin is definitely available at Google, but when talking about sym types et al it's not nearly as nice to use as Rust / OCaml.
troupo 1y ago
OCaml also needed the brief but bright ReasonML moment to add/fix/improve some of the syntax IIRC and work on user-friendly error messages. But this should've definitely happened much much earlier than it did.
- Taikonerd 1y ago
  I would say ReasonML also needed more follow-through. It seems like the OCaml community hasn't really rallied behind it.
  - mirekrusin 1y ago
    Maybe it's good it died? Now we have moonbit lang.
    - theLiminator 1y ago
      flix also looks pretty nice
    - troupo 1y ago
      Moonbit the fast, compact and user friendly language for WebAssembly? Or Moonbit the language for industrial usage? Or Moonbit the AI-native general-purpose programming language? (They are the same language) Reason at least was an active collaboration between several projects in the OCaml space with some feedback into OCaml proper (even though there was a lot of initial resistance IIRC).
      - mirekrusin 1y ago
        It's not only for wasm, compiles to native code as well [0]. [0] https://www.moonbitlang.com/blog/llvm-backend https://www.moonbitlang.com/blog/llvm-backend
  - bsder 1y ago
    It doesn't help that the OCaml community also has the problem that a significant minority seem to resent the fact that one company (Jane Street) has written more OCaml than the the rest of the world combined and then some and so de facto controls the ecosystem. Whereas the Go and Rust communities, for example, were just fine with having corporate sponsorship driving things.
the__alchemist 1y ago
I'm with you. I think some of the nicest parts of rust have nothing to do with memory safety; they're ways to structure your program as you mention.
munificent 1y ago
> I feel if OCaml had got its act together around about 2010 with multicore and a few other annoyances[1] it could have been Rust. Arguably, that could have been Scala and for a while it seemed like it would be Scala but then it kind of just... didn't. I suspect some of that was that the programming style of some high profile Scala packages really alienated people by pushing the type system and operator overloading much farther than necessary.
- whimsicalism 1y ago
  Scala was always going to be hamstrung by the fact that it's a JVM language and yes, the crazy stuff people did with the language didn't help.
  - owlstuffing 1y ago
    I agree w that, but I think Scala has deeper problems. It tries to be a better Java and a better OCaml at the same time. This split personality led to Scala’s many dialects, which made it notorious for being difficult to read and reason about, particularly as a mainstream language contender. Above all, Scala is considered a functional language with imperative OOP qualities. And it more or less fits that description. But like it or not primarily functional languages don’t have a strong reputation for building large maintainable enterprise software. That’s the quiet part no one says out loud. It’s like how in academic circles Lisp is considered the most pure and most powerful of programming languages, which may be true. At the same time most real-world decision makers see it as unsuitable as a mainstream language. If it were otherwise, we’d have seen a Lisp contend with imperative langs such as Java, C#, TypeScript, etc. I’ve always attributed this disconnect to the fact that people naturally model the world around them as objects with state — people don’t think functionally.
    - vips7L 1y ago
      To me Scala is first and foremost a research language. It’s even how it’s developed.
    - wink 1y ago
yodsanklai 1y ago
> aesthetically the double semicolons are an abomination and irk me far more. I think they have been optional for like 20 years, except in the top-level interactive environment to force execution. That being said, I still don't get why people are so much upset with the syntax. You'll integrate it after a week writing OCaml code.
- whimsicalism 1y ago
  I spent more than a week writing ocaml and still found the syntax pretty annoying. ReasonML would have been nice if the Ocaml community actually cared, but they are a bit insular.
  - yawaramin 1y ago
    Reason syntax is fully supported by the OCaml ecosystem and has been for many years.
  - deleted 1y ago
    [deleted]
- swiftcoder 1y ago
  Erlang faces a similar uphill battle when it comes to syntax - there are three different punctuation marks used as terminators depending on context, and you have to keep in your head the rules for all 3. As someone who has written quite a bit of Erlang, but infrequently, it's always a battle. And I think a big part of the reason that Elixir has done so well (Elixir pretty much starting out as Erlang-but-with-Ruby-syntax)
gerdesj 1y ago
"I feel if OCaml had got its act together ..." The great thing is we have choice. We have a huge number of ways to express ideas and ... do them! I might draw a parallel with the number of spoken languages extent in the UK (only ~65M people). You are probably familiar with English. There are rather a lot more languages here. Irish, Scottish, Welsh - these are the thriving Brythonic languages (and they probably have some sub-types). Cornish formally died out in the sixties (the last two sisters that spoke it natively, passed away) but it has been revived by some locals and given that living people who could communicate with relos with first hand experience, I think we can count that a language that is largely saved. Cumbric ... counting still used by shepherds - something like: yan, tan, tithera toe. I am looking at OCAML because I'm the next generation to worry about genealogy in my family and my uncle has picked Geneweb to store the data, taking over from TMG - a Windows app. His database contains roughly 140,000 individuals. Geneweb is programmed in OCAML. If you think that programming languages are complicated ... have a go at genealogy. You will soon discover something called GEDCOM and then you will weep!
- DrewADesign 1y ago
  For personal projects? Sure. In nearly any development organization larger than one person, unilaterally deciding to use OCAML instead of what everybody else uses would go over about as well as unilaterally deciding to use Aramaic at meetings.
- beezlewax 1y ago
  It's weird to see someone from the UK champion the Irish language as a choice as if they didn't try to systematically wipe it from the face of the earth for quite a long period of time. Choice is good of course so do keep up the good work.
  - gerdesj 1y ago
    My grandad's family on my dad's side was driven out of Dublin by some folks who went on to set their house on fire, back in the day. They were warned off by a maid and legged it to England. A few generations earlier, on the same line, my ancestors were German immigrants to London. I will upvote your comment nonetheless. I see it has been DVd which I don't like to see - we all have our views.
deleted 1y ago
[deleted]
77pt77 1y ago
> I feel if OCaml had got its act together around about 2010 with multicore and a few other annoyances[1] it could have been Rust That's about the time-frame where I got into OCaml so I followed this up close. The biggest hindrance in my opinion is/was boxed types. Too much overhead for low level stuff, although there was a guy from oxbridge doing GL stuff with it.
- debugnik 1y ago
  That's still the biggest hindrance in my opinion, at least for my use cases. OxCaml, Jane Street's fork, has some features for unboxed types and stack-based allocation of boxed types; hopefully it goes upstream.
lmm 1y ago
> I feel if OCaml had got its act together around about 2010 with multicore and a few other annoyances[1] it could have been Rust. No, that wouldn't have made the difference. No-one didn't pick up OCaml because it didn't have multicore or they were annoyed by the semicolons. People don't switch languages because the new language is "old language but better". They switch languages because a) new language does some unique thing that the old language didn't do, even if the unique thing is useless and irrelevant, b) new language has a bigger number than old language on benchmarks, even if the benchmark is irrelevant to your use case, or c) new language claims to have great interop with old language, even if this is a lie. There is no way OCaml could have succeeded in the pop culture that is programming language popularity. Yes, all of the actual reasons to use Rust apply just as much to OCaml and if our industry operated on technical merit we would have migrated to OCaml decades ago. But it doesn't so we didn't.
- brabel 1y ago
  I appreciate both OCaml and Rust, but your view seems to be entirely wrong to me, sorry to be blunt. People wouldn't care much for Rust at all if it didn't offer two things that are an absolute killer feature (that OCaml does not have): * no GC, while being memory safe. * high performance on par with C while offering no-cost high level conveniences. There's no other language to this day that offers anything like that. Rust really is unique in this area, as far as I know. The fact that it also has a very good package manager and was initially backed by a big, trusted company, Mozzila, while OCaml comes from a Research Lab, also makes this particular race a no-brainer unless you're into Functional Programming (which has never been very popular, no matter the language).
  - lmm 1y ago
    >> a) new language does some unique thing that the old language didn't do, even if the unique thing is useless and irrelevant >> b) new language has a bigger number than old language on benchmarks, even if the benchmark is irrelevant to your use case > * no GC, while being memory safe. > * high performance on par with C while offering no-cost high level conveniences. My point exactly! > was initially backed by a big, trusted company, Mozzila, while OCaml comes from a Research Lab Mozilla is not large and trustworthy, as you can see by the fact they haven't kept funding Rust development (because they can't afford to)! People weren't picking Rust because it had better backing or a bigger ecosystem, not in the early stages that made the difference - it didn't.
shpongled 1y ago
As someone who loves SML/OCaml and has written primarily Rust over the past ~10 years, I totally agree - I use it as a modern and ergonomic ML with best-in-class tooling, libraries, and performance. Lifetimes are cool, and I use them when needed, but they aren't the reason I use Rust at all. I would use Rust with a GC instead of lifetimes too.
- hawk_ 1y ago
  How do you use Rust without lifetimes?
  - legobmw99 1y ago
    Either a lot of clones or a lot of reference counted pointers. Especially if your point of comparison is a GC language, this is much less of a crime than some people think
  - shpongled 1y ago
    When I mean "use" them, I mean make heavy use of them, e.g. structs or functions annotated with multiple lifetimes, data flows designed to borrow data, e.g. You can often get by just with `clone` and lifetime elision, and if you don't need to eke out that last bit of performance, it's fine.
rtpg 1y ago
I think people like ADTs and pattern matching that Rust gives, but really the way that Rust becomes even more pleasant is that you have _so many_ trait methods on standard library objects that offer succinct answers to common patterns. Haskell of course has some of this, but immutability means that Haskell doesn't have to have answers for lots of things. And you want pattern matching as your basic building block, but at the end of the day most of your code won't have pattern matching and will instead rely on higher level patterns (that can build off of ADTs providing some degree of certainty on totality etc)
sanderjd 1y ago
Yeah I was initially drawn to rust because I loved ocaml but wished it were more practical.
omcnoe 1y ago
The issue regarding academia is that functional programming is treated as an afterthought/sideshow that is mainly of interest for research. Almost no-one is teaching FP concepts to undergrads.
- uncircle 1y ago
  Before 2010-something, the very popular meme in software engineering was that functional programming is really hard to understand, and really not suited for anything outside of academia. [1] Now that I've been programming in an immutable functional language for almost a decade (Elixir), I'm certain the meme was mostly born out of unfamiliarity [2] than actual complexity; it's really not that much different than imperative, just requires a different approach and understanding of the trade-offs. Writing a distributed system (say, a web app backend) in an imperative, mutable language in this day and age is increasingly a laughable proposition in my view. Use the right tool for the problem at hand. Many academically-trained developers never got exposed to FP in school, and to this day you can still hear, albeit in much lesser numbers thanks to the popularity of Elixir/Clojure/etc., the meme of FP being "hard" perpetuated. --- 1: I would go so far as to blame Haskell for the misplaced belief that FP means overcomplicated type theory when all you want is a for loop and a mutable data-structure. 2: I played with OCaml 10+ years ago, and couldn't make head or tails of it. I tried again recently, and it just felt familiar and quite obvious.
  - mrkeen 1y ago
    > the very popular meme in software engineering was that functional programming is really hard > I'm certain the meme was mostly born out of unfamiliarity > I would go so far as to blame Haskell for the misplaced belief that FP means overcomplicated type theory
    - uncircle 1y ago
      Am I supposed to hallucinate a reply from my own words? Say what you mean.
- pjmlp 1y ago
pjmlp 1y ago
That is why if I feel like doing ML style programing I rather reach out for Kotlin, Scala or F# than Rust, and even then Java and C# have gotten enough inspiration that I can also feel at home while using them. I am no strage to ML type systems, my first one was Caml Light, OCaml was still known as Objective Caml, and Mirada was still something being discussed on programming language lectures on my university. From what I see, I also kind of find the same, too many people rush out for Rust thinking that ML type systems is something new introduced by Rust, without having the background where all comes from.
- michaelcampbell 1y ago
  > too many people rush out for Rust Yes > thinking that ML type systems is something new introduced by Rust This feels off to me. Of the hype-train that Rust has been for a while now, a _type_ of type system it has hasn't been any of the cars, as it were. At least in my readings; I'm sure we travel in different circles, but even the few academic oriented things have been other language features and memory safety through and through.
fulafel 1y ago
Anyone have a link to the Android talk? I wonder if it was backend code or on-device code. On device you could probably justify the compromises of a no-GC language better.
- noelwelsh 1y ago
  I tracked it down: https://www.youtube.com/watch?v=QrrH2lcl9ew https://www.youtube.com/watch?v=QrrH2lcl9ew I don't think it was on-device code, as they talked about porting Python projects. But you can watch the talk to see if I'm misremembering.
  - fulafel 1y ago
    Thanks! In the transcript I found more talk about porting C++ and Go to Rust, without Python rewrite references... still interesting tidbits, like "when we've rewritten systems from go into rust we've found that it takes about the same size team about the same amount of time to build it that is there's no loss in productivity when moving from go to rust "
ubercore 1y ago
I've only forayed into rust a bit, but I agree. I would happily take a language like Rust that sacrifices some speed for simpler semantics around ownership/lifetimes. Just Arc, clone and panic your way to success! :)
IshKebab 1y ago
I agree. If OCaml had solved some of its bigger paper cuts it could have been a real player. Compilation time is much better than Rust too: * OPAM is quite buggy and extremely confusing. * Windows support is very bad. If you ever tried to use Perl on Windows back in the day... it's worse than that. * Documentation is terse to the point of uselessness. * The syntax style is quite hard to mentally parse and also not very recoverable. If you miss some word or character the error can be "the second half of the file has a syntax error". Not very fun. Rust's more traditional syntax is much easier to deal with. Rust basically has none of those issues. Really the only advantage I can see with OCaml today is compile time, which is important, but it's definitely not important enough to make me want to use OCaml.
- jll29 1y ago
  I'd say the Modula-2 inspired module system is a very valuable asset compared to today's Rust. The only contact with OCaml I had was that I wrote a bug report to a university professor because I wanted his tool to process one of my files, but the file was larger than OCaml's int type could handle. That itself wasn't the problem - he wrote it wasn't straight forward to fix it. (This is a bug of the type "couldn't have happened in Common LISP". But I guess even in C one could replace int by FILE_SIYE_TYPE and #define it as unsigned size_t, for instance).
  - pjmlp 1y ago
    It is more the other way around ML predates Modula-2, and the module system like ideas were already present in Mesa and UCSD Pascal. :)
    - jll29 1y ago
      It's been a while since I used UCSD Pascal (in high school, on Apple II boxes with an extra hardware card), so I don't recall the details of the module system there but I'm pretty sure it did not back then permit separate compilation of definitions and implementation files as Modula-2 did (.def and .mod in Modula-2, respectively). I also saw some ML/SML at uni in the early 1990s but no mention of modules then (this is not to say you are wrong, but I question how visible any work in that space was that may have existed). Now Mesa I never got my hands on, nor do I know anyone that did. Modula-2 was popular e.g. on the Atari ST 520 series, I still have the handbook on my bookshelf next to me (the vendor of the compiler I had was called "Application Systems Heidelberg", founded in Germany in 1985 they now seem to have gone into gaming). This was a decent 32-bit compiler, and with 1 MB RAM you could write great applications when C compilers at the time were still insufficient in their ability to provide proper type checking support (pre-ANSI/ISO standardization). Reddit has a discussion on Modula-2 and its family tree here: https://www.reddit.com/r/programming/comments/1cuam2p/what_ever_happened_to_modula2/ https://www.reddit.com/r/programming/comments/1cuam2p/what_e...
StopDisinfo910 1y ago
> I feel if OCaml had got its act together around about 2010 with multicore and a few other annoyances[1] OCaml had its act together. It was significantly nicer than Python when I used it professionally in 2010. Just look at what JaneStreet achieved with it. The main impediment to OCaml was always that it was not American nor mainly developed from the US. People like to believe there is some technical merit to language popularity but the reality it’s all fashion based. Rust is popular because they did a ton of outreach. They used to pay someone full time to mostly toot their horn.
- jvican 1y ago
  Hear, hear. This theory also explains why other languages such as Scala were never really mainstream despite allowing Java- and Kotlin- style programming and having a much broader follower base in Europe. Lack of outreach, concerted marketing, and advocacy from American companies that have always dominated the narrative.
- nothrabannosir 1y ago
  Python, PHP, Ruby: all not American though, right? Do you mean those only got hockey stick growth when they happened to get picked up by the USA ? But then couldn’t the same have happened for ocaml? And if so: why didn’t it, as it supposedly did for the others Not to mention Linux I guess
  - StopDisinfo910 1y ago
    Von Rossum moved to the US and Python actually got US government funding pretty early. Lerdorf did PHP in Canada so America. Ruby is kind of the exception being Japanese but it’s pretty niche - nearly as much as Ocaml - and is mostly popular for Rails which was started from Denmark but by someone working for, you guessed it, a US company. Torvald announced Linux on a US usenet list and moved to California soon after. Ocaml difference is that the core development is done by INRIA, a French public institution and the people in charge had zero interest in moving to the US or chasing the US market. It’s funny because Ocaml became a bit more popular when people from the UK (Cambridge, JaneStreet) started doing more outreach.
le-mark 1y ago
The way ocaml mashes the object syntax into sml was always most annoying to me. It was also pretty weak on the systems programming side (threads, sockets, signals, fork) 20-30 years ago iirc. That’s probably changed by now. Multi core; not many runtimes handle this today so that’s not much of a hindrance IME.
ezst 1y ago
I feel that whatever "OCaml - the good parts" might be, it lives through Scala today. It's syntactically familiar/pleasing, it deals equally well with your high throughput (JVM), low-footprint (scala-native), web (scala-js/scala-wasm), small script to large monolith needs equally well, and its tooling/community support is orders of magnitude better than the other functional-first "popular" languages (OCaml, Haskell, Clojure, …).

unstruktured 1y ago

There is absolutely no reason to use double semicolons in practice. The only place you really should see it is when using the repl.

sigzero 1y ago
Yeah, it makes me think he doesn't understand them in OCaml.
- acjohnson55 1y ago
  I worked in OCaml for a year and I couldn't tell you by memory what the difference was. I remember being very annoyed by OCaml's many language quirks.

garbthetill 1y ago

doesnt rust still have the advantage of having no gc? I dont like writing rust, but the selling point of being able to write performative code with memory safety guarantees has always stuck with me

noelwelsh 1y ago
I think "no gc but memory safe" is what originally got people excited about Rust. It's a genuinely new capability in production ready languages. However, I think Rust is used in many contexts where a GC is just fine and working with lifetimes makes many programs more painful to write. I think for many programs the approach taken by Oxidized OCaml[1] or Scala[2] gives 80% of the benefit while being a lot more ergonomic to work with. When I see Rust topping the "most loved language" on Stack Overflow etc. what I think is really happening is that people are using a "modern" language for the first time. I consistently see people gushing about, e.g., pattern matching in Rust. I agree pattern matching is awesome, but it is also not at all novel if you are a PL nerd. It's just that most commercial languages are crap from a PL nerd point of view. So I think "no gc but memory safe" is what got people to look at Rust, but it's 1990s ML (ADTs, pattern matching, etc.) that keeps them there. [1]: https://github.com/oxcaml/oxcaml https://github.com/oxcaml/oxcaml [2]: https://docs.scala-lang.org/scala3/reference/experimental/cc.html https://docs.scala-lang.org/scala3/reference/experimental/cc...
- GeekyBear 1y ago
  > I think "no gc but memory safe" is what originally got people excited about Rust. I think it was more about "the performance of C, but with memory safety and data race safety".
- josephg 1y ago
  > So I think "no gc but memory safe" is what got people to look at Rust, but it's 1990s ML (ADTs, pattern matching, etc.) that keeps them there. Yeah; this is my experience. I've been working in C professionally lately after writing rust fulltime for a few years. I don't really miss the borrow checker. But I really miss ADTs (eg Result<>, Option, etc), generic containers (Vec<T>), tuples, match expressions and the tooling (Cargo). You can work around a lot of these problems in C with grit and frustration, but rust just gives you good answers out of the box.
- voidhorse 1y ago
  Spot on. It's also fascinating to watch people have their minds blown in 2020+ by basic features that have been around since the nineties. It's kind of sad, actually. The industry would be in such a better place than it is today if so many programmers weren't allergic to all things academic and "theoretical" and were more curious and technical than they were conceited. It's baffling that computing, literally a subject area in which the theory quite literally is the practice, is so full of people who refuse to engage with theoretical work and research.

benreesman 1y ago

[flagged]

simonask 1y ago
This is one of the wilder conspiracy theories to me, and that says a lot in 2025.
- benreesman 1y ago
  The RESF is not a conspiracy theory, its a known thing. Especially on HN: https://news.ycombinator.com/item?id=14178950 https://news.ycombinator.com/item?id=14178950
  - the__alchemist 1y ago
    It's real, and as someone who loves rust, it's embarrassing, and difficult to avoid. The OSS embedded rust users in particular are nuts.
    - benreesman 1y ago
      Really appreciate a fairminded Rust person chiming in. It's a disservice to the language (which is cool!), and it makes the community look bad. Rust might gain some adoption among people who are new to high performance software and see a narrative that its the only game in town, but it turns off a lot of older folks like myself who know it isn't and that community matters. gl to you and people like you trying to get it back on track!
      - simonask 1y ago
        Can we be clear here: You are accusing people in this thread of "inorganically" bringing up Rust. The implication being that there is some shadowy group or organization coordinating the bombing of random forum threads to talk about Rust, or what are we saying here? Rust is an exciting language. It comes up because many people like it.

nine_k 1y ago

I'd say that Google strives to have a reasonably short list of languages approved for production-touching code. Rust can replace / complement C++, while OCaml cannot (it could replace Go instead... fat chance!). So I suspect that the team picked Rust because it was the only blessed language with ADTs, not because they won't like something with faster compile times. No way OCaml could have stolen the Rust's thunder: we have a number of very decent and performant GC-based languages, from Go to Haskell; we only had one bare-metal-worthy expressive language in 2010, C++, and it was pretty terrible (still is, but before C++11 and C++17 it was even more terrible).

hardwaregeek 1y ago
Wouldn’t Kotlin be a more reasonable choice in that case? It has ADTs and a lot of the same niceties of Rust.
- actionfromafar 1y ago
  Garbage collector in Kotlin makes it a no go for C or C++ displacement.
  - pjmlp 1y ago
    As someone that has left pure C++ applications in 2006, and has mostly written mixed language projects since 1999, usually the displacement is more religious than anything else. In many use cases even if the performance is within the project delivery deadlines there will worthless discussions about performance benchmarks completly irrelevant to the task at hand. And ironically many of the same folks are using Electron based apps for their workflows.
- Artamus 1y ago
  I'm inclined to think that the Python -> Rust was only for some odds and ends. I know the biggest recipient of Rust trainings was the Android platform team at first, which I think also used a lot of C++. Kotlin is definitely available at Google, but when talking about sym types et al it's not nearly as nice to use as Rust / OCaml.

troupo 1y ago

OCaml also needed the brief but bright ReasonML moment to add/fix/improve some of the syntax IIRC and work on user-friendly error messages. But this should've definitely happened much much earlier than it did.

Taikonerd 1y ago
I would say ReasonML also needed more follow-through. It seems like the OCaml community hasn't really rallied behind it.
- mirekrusin 1y ago
  Maybe it's good it died? Now we have moonbit lang.
  - theLiminator 1y ago
    flix also looks pretty nice
  - troupo 1y ago
    Moonbit the fast, compact and user friendly language for WebAssembly? Or Moonbit the language for industrial usage? Or Moonbit the AI-native general-purpose programming language? (They are the same language) Reason at least was an active collaboration between several projects in the OCaml space with some feedback into OCaml proper (even though there was a lot of initial resistance IIRC).
    - mirekrusin 1y ago
      It's not only for wasm, compiles to native code as well [0]. [0] https://www.moonbitlang.com/blog/llvm-backend https://www.moonbitlang.com/blog/llvm-backend
- bsder 1y ago
  It doesn't help that the OCaml community also has the problem that a significant minority seem to resent the fact that one company (Jane Street) has written more OCaml than the the rest of the world combined and then some and so de facto controls the ecosystem. Whereas the Go and Rust communities, for example, were just fine with having corporate sponsorship driving things.

the__alchemist 1y ago

I'm with you. I think some of the nicest parts of rust have nothing to do with memory safety; they're ways to structure your program as you mention.

munificent 1y ago

> I feel if OCaml had got its act together around about 2010 with multicore and a few other annoyances[1] it could have been Rust. Arguably, that could have been Scala and for a while it seemed like it would be Scala but then it kind of just... didn't. I suspect some of that was that the programming style of some high profile Scala packages really alienated people by pushing the type system and operator overloading much farther than necessary.

whimsicalism 1y ago
Scala was always going to be hamstrung by the fact that it's a JVM language and yes, the crazy stuff people did with the language didn't help.
- owlstuffing 1y ago
  I agree w that, but I think Scala has deeper problems. It tries to be a better Java and a better OCaml at the same time. This split personality led to Scala’s many dialects, which made it notorious for being difficult to read and reason about, particularly as a mainstream language contender. Above all, Scala is considered a functional language with imperative OOP qualities. And it more or less fits that description. But like it or not primarily functional languages don’t have a strong reputation for building large maintainable enterprise software. That’s the quiet part no one says out loud. It’s like how in academic circles Lisp is considered the most pure and most powerful of programming languages, which may be true. At the same time most real-world decision makers see it as unsuitable as a mainstream language. If it were otherwise, we’d have seen a Lisp contend with imperative langs such as Java, C#, TypeScript, etc. I’ve always attributed this disconnect to the fact that people naturally model the world around them as objects with state — people don’t think functionally.
  - vips7L 1y ago
    To me Scala is first and foremost a research language. It’s even how it’s developed.
  - wink 1y ago

yodsanklai 1y ago

> aesthetically the double semicolons are an abomination and irk me far more. I think they have been optional for like 20 years, except in the top-level interactive environment to force execution. That being said, I still don't get why people are so much upset with the syntax. You'll integrate it after a week writing OCaml code.

whimsicalism 1y ago
I spent more than a week writing ocaml and still found the syntax pretty annoying. ReasonML would have been nice if the Ocaml community actually cared, but they are a bit insular.
- yawaramin 1y ago
  Reason syntax is fully supported by the OCaml ecosystem and has been for many years.
- deleted 1y ago
  [deleted]
swiftcoder 1y ago
Erlang faces a similar uphill battle when it comes to syntax - there are three different punctuation marks used as terminators depending on context, and you have to keep in your head the rules for all 3. As someone who has written quite a bit of Erlang, but infrequently, it's always a battle. And I think a big part of the reason that Elixir has done so well (Elixir pretty much starting out as Erlang-but-with-Ruby-syntax)

gerdesj 1y ago

"I feel if OCaml had got its act together ..." The great thing is we have choice. We have a huge number of ways to express ideas and ... do them! I might draw a parallel with the number of spoken languages extent in the UK (only ~65M people). You are probably familiar with English. There are rather a lot more languages here. Irish, Scottish, Welsh - these are the thriving Brythonic languages (and they probably have some sub-types). Cornish formally died out in the sixties (the last two sisters that spoke it natively, passed away) but it has been revived by some locals and given that living people who could communicate with relos with first hand experience, I think we can count that a language that is largely saved. Cumbric ... counting still used by shepherds - something like: yan, tan, tithera toe. I am looking at OCAML because I'm the next generation to worry about genealogy in my family and my uncle has picked Geneweb to store the data, taking over from TMG - a Windows app. His database contains roughly 140,000 individuals. Geneweb is programmed in OCAML. If you think that programming languages are complicated ... have a go at genealogy. You will soon discover something called GEDCOM and then you will weep!

DrewADesign 1y ago
For personal projects? Sure. In nearly any development organization larger than one person, unilaterally deciding to use OCAML instead of what everybody else uses would go over about as well as unilaterally deciding to use Aramaic at meetings.
beezlewax 1y ago
It's weird to see someone from the UK champion the Irish language as a choice as if they didn't try to systematically wipe it from the face of the earth for quite a long period of time. Choice is good of course so do keep up the good work.
- gerdesj 1y ago
  My grandad's family on my dad's side was driven out of Dublin by some folks who went on to set their house on fire, back in the day. They were warned off by a maid and legged it to England. A few generations earlier, on the same line, my ancestors were German immigrants to London. I will upvote your comment nonetheless. I see it has been DVd which I don't like to see - we all have our views.

deleted 1y ago

[deleted]

77pt77 1y ago

> I feel if OCaml had got its act together around about 2010 with multicore and a few other annoyances[1] it could have been Rust That's about the time-frame where I got into OCaml so I followed this up close. The biggest hindrance in my opinion is/was boxed types. Too much overhead for low level stuff, although there was a guy from oxbridge doing GL stuff with it.

debugnik 1y ago
That's still the biggest hindrance in my opinion, at least for my use cases. OxCaml, Jane Street's fork, has some features for unboxed types and stack-based allocation of boxed types; hopefully it goes upstream.

lmm 1y ago

> I feel if OCaml had got its act together around about 2010 with multicore and a few other annoyances[1] it could have been Rust. No, that wouldn't have made the difference. No-one didn't pick up OCaml because it didn't have multicore or they were annoyed by the semicolons. People don't switch languages because the new language is "old language but better". They switch languages because a) new language does some unique thing that the old language didn't do, even if the unique thing is useless and irrelevant, b) new language has a bigger number than old language on benchmarks, even if the benchmark is irrelevant to your use case, or c) new language claims to have great interop with old language, even if this is a lie. There is no way OCaml could have succeeded in the pop culture that is programming language popularity. Yes, all of the actual reasons to use Rust apply just as much to OCaml and if our industry operated on technical merit we would have migrated to OCaml decades ago. But it doesn't so we didn't.

brabel 1y ago
I appreciate both OCaml and Rust, but your view seems to be entirely wrong to me, sorry to be blunt. People wouldn't care much for Rust at all if it didn't offer two things that are an absolute killer feature (that OCaml does not have): * no GC, while being memory safe. * high performance on par with C while offering no-cost high level conveniences. There's no other language to this day that offers anything like that. Rust really is unique in this area, as far as I know. The fact that it also has a very good package manager and was initially backed by a big, trusted company, Mozzila, while OCaml comes from a Research Lab, also makes this particular race a no-brainer unless you're into Functional Programming (which has never been very popular, no matter the language).
- lmm 1y ago
  >> a) new language does some unique thing that the old language didn't do, even if the unique thing is useless and irrelevant >> b) new language has a bigger number than old language on benchmarks, even if the benchmark is irrelevant to your use case > * no GC, while being memory safe. > * high performance on par with C while offering no-cost high level conveniences. My point exactly! > was initially backed by a big, trusted company, Mozzila, while OCaml comes from a Research Lab Mozilla is not large and trustworthy, as you can see by the fact they haven't kept funding Rust development (because they can't afford to)! People weren't picking Rust because it had better backing or a bigger ecosystem, not in the early stages that made the difference - it didn't.

shpongled 1y ago

As someone who loves SML/OCaml and has written primarily Rust over the past ~10 years, I totally agree - I use it as a modern and ergonomic ML with best-in-class tooling, libraries, and performance. Lifetimes are cool, and I use them when needed, but they aren't the reason I use Rust at all. I would use Rust with a GC instead of lifetimes too.

hawk_ 1y ago
How do you use Rust without lifetimes?
- legobmw99 1y ago
  Either a lot of clones or a lot of reference counted pointers. Especially if your point of comparison is a GC language, this is much less of a crime than some people think
- shpongled 1y ago
  When I mean "use" them, I mean make heavy use of them, e.g. structs or functions annotated with multiple lifetimes, data flows designed to borrow data, e.g. You can often get by just with `clone` and lifetime elision, and if you don't need to eke out that last bit of performance, it's fine.

rtpg 1y ago

I think people like ADTs and pattern matching that Rust gives, but really the way that Rust becomes even more pleasant is that you have _so many_ trait methods on standard library objects that offer succinct answers to common patterns. Haskell of course has some of this, but immutability means that Haskell doesn't have to have answers for lots of things. And you want pattern matching as your basic building block, but at the end of the day most of your code won't have pattern matching and will instead rely on higher level patterns (that can build off of ADTs providing some degree of certainty on totality etc)

sanderjd 1y ago

Yeah I was initially drawn to rust because I loved ocaml but wished it were more practical.

omcnoe 1y ago

The issue regarding academia is that functional programming is treated as an afterthought/sideshow that is mainly of interest for research. Almost no-one is teaching FP concepts to undergrads.

uncircle 1y ago
Before 2010-something, the very popular meme in software engineering was that functional programming is really hard to understand, and really not suited for anything outside of academia. [1] Now that I've been programming in an immutable functional language for almost a decade (Elixir), I'm certain the meme was mostly born out of unfamiliarity [2] than actual complexity; it's really not that much different than imperative, just requires a different approach and understanding of the trade-offs. Writing a distributed system (say, a web app backend) in an imperative, mutable language in this day and age is increasingly a laughable proposition in my view. Use the right tool for the problem at hand. Many academically-trained developers never got exposed to FP in school, and to this day you can still hear, albeit in much lesser numbers thanks to the popularity of Elixir/Clojure/etc., the meme of FP being "hard" perpetuated. --- 1: I would go so far as to blame Haskell for the misplaced belief that FP means overcomplicated type theory when all you want is a for loop and a mutable data-structure. 2: I played with OCaml 10+ years ago, and couldn't make head or tails of it. I tried again recently, and it just felt familiar and quite obvious.
- mrkeen 1y ago
  > the very popular meme in software engineering was that functional programming is really hard > I'm certain the meme was mostly born out of unfamiliarity > I would go so far as to blame Haskell for the misplaced belief that FP means overcomplicated type theory
  - uncircle 1y ago
    Am I supposed to hallucinate a reply from my own words? Say what you mean.
pjmlp 1y ago

pjmlp 1y ago

That is why if I feel like doing ML style programing I rather reach out for Kotlin, Scala or F# than Rust, and even then Java and C# have gotten enough inspiration that I can also feel at home while using them. I am no strage to ML type systems, my first one was Caml Light, OCaml was still known as Objective Caml, and Mirada was still something being discussed on programming language lectures on my university. From what I see, I also kind of find the same, too many people rush out for Rust thinking that ML type systems is something new introduced by Rust, without having the background where all comes from.

michaelcampbell 1y ago
> too many people rush out for Rust Yes > thinking that ML type systems is something new introduced by Rust This feels off to me. Of the hype-train that Rust has been for a while now, a _type_ of type system it has hasn't been any of the cars, as it were. At least in my readings; I'm sure we travel in different circles, but even the few academic oriented things have been other language features and memory safety through and through.

fulafel 1y ago

Anyone have a link to the Android talk? I wonder if it was backend code or on-device code. On device you could probably justify the compromises of a no-GC language better.

noelwelsh 1y ago
I tracked it down: https://www.youtube.com/watch?v=QrrH2lcl9ew https://www.youtube.com/watch?v=QrrH2lcl9ew I don't think it was on-device code, as they talked about porting Python projects. But you can watch the talk to see if I'm misremembering.
- fulafel 1y ago
  Thanks! In the transcript I found more talk about porting C++ and Go to Rust, without Python rewrite references... still interesting tidbits, like "when we've rewritten systems from go into rust we've found that it takes about the same size team about the same amount of time to build it that is there's no loss in productivity when moving from go to rust "

ubercore 1y ago

I've only forayed into rust a bit, but I agree. I would happily take a language like Rust that sacrifices some speed for simpler semantics around ownership/lifetimes. Just Arc, clone and panic your way to success! :)

IshKebab 1y ago

I agree. If OCaml had solved some of its bigger paper cuts it could have been a real player. Compilation time is much better than Rust too: * OPAM is quite buggy and extremely confusing. * Windows support is very bad. If you ever tried to use Perl on Windows back in the day... it's worse than that. * Documentation is terse to the point of uselessness. * The syntax style is quite hard to mentally parse and also not very recoverable. If you miss some word or character the error can be "the second half of the file has a syntax error". Not very fun. Rust's more traditional syntax is much easier to deal with. Rust basically has none of those issues. Really the only advantage I can see with OCaml today is compile time, which is important, but it's definitely not important enough to make me want to use OCaml.

jll29 1y ago
I'd say the Modula-2 inspired module system is a very valuable asset compared to today's Rust. The only contact with OCaml I had was that I wrote a bug report to a university professor because I wanted his tool to process one of my files, but the file was larger than OCaml's int type could handle. That itself wasn't the problem - he wrote it wasn't straight forward to fix it. (This is a bug of the type "couldn't have happened in Common LISP". But I guess even in C one could replace int by FILE_SIYE_TYPE and #define it as unsigned size_t, for instance).
- pjmlp 1y ago
  It is more the other way around ML predates Modula-2, and the module system like ideas were already present in Mesa and UCSD Pascal. :)
  - jll29 1y ago
    It's been a while since I used UCSD Pascal (in high school, on Apple II boxes with an extra hardware card), so I don't recall the details of the module system there but I'm pretty sure it did not back then permit separate compilation of definitions and implementation files as Modula-2 did (.def and .mod in Modula-2, respectively). I also saw some ML/SML at uni in the early 1990s but no mention of modules then (this is not to say you are wrong, but I question how visible any work in that space was that may have existed). Now Mesa I never got my hands on, nor do I know anyone that did. Modula-2 was popular e.g. on the Atari ST 520 series, I still have the handbook on my bookshelf next to me (the vendor of the compiler I had was called "Application Systems Heidelberg", founded in Germany in 1985 they now seem to have gone into gaming). This was a decent 32-bit compiler, and with 1 MB RAM you could write great applications when C compilers at the time were still insufficient in their ability to provide proper type checking support (pre-ANSI/ISO standardization). Reddit has a discussion on Modula-2 and its family tree here: https://www.reddit.com/r/programming/comments/1cuam2p/what_ever_happened_to_modula2/ https://www.reddit.com/r/programming/comments/1cuam2p/what_e...

StopDisinfo910 1y ago

> I feel if OCaml had got its act together around about 2010 with multicore and a few other annoyances[1] OCaml had its act together. It was significantly nicer than Python when I used it professionally in 2010. Just look at what JaneStreet achieved with it. The main impediment to OCaml was always that it was not American nor mainly developed from the US. People like to believe there is some technical merit to language popularity but the reality it’s all fashion based. Rust is popular because they did a ton of outreach. They used to pay someone full time to mostly toot their horn.

jvican 1y ago
Hear, hear. This theory also explains why other languages such as Scala were never really mainstream despite allowing Java- and Kotlin- style programming and having a much broader follower base in Europe. Lack of outreach, concerted marketing, and advocacy from American companies that have always dominated the narrative.
nothrabannosir 1y ago
Python, PHP, Ruby: all not American though, right? Do you mean those only got hockey stick growth when they happened to get picked up by the USA ? But then couldn’t the same have happened for ocaml? And if so: why didn’t it, as it supposedly did for the others Not to mention Linux I guess
- StopDisinfo910 1y ago
  Von Rossum moved to the US and Python actually got US government funding pretty early. Lerdorf did PHP in Canada so America. Ruby is kind of the exception being Japanese but it’s pretty niche - nearly as much as Ocaml - and is mostly popular for Rails which was started from Denmark but by someone working for, you guessed it, a US company. Torvald announced Linux on a US usenet list and moved to California soon after. Ocaml difference is that the core development is done by INRIA, a French public institution and the people in charge had zero interest in moving to the US or chasing the US market. It’s funny because Ocaml became a bit more popular when people from the UK (Cambridge, JaneStreet) started doing more outreach.

le-mark 1y ago

The way ocaml mashes the object syntax into sml was always most annoying to me. It was also pretty weak on the systems programming side (threads, sockets, signals, fork) 20-30 years ago iirc. That’s probably changed by now. Multi core; not many runtimes handle this today so that’s not much of a hindrance IME.

ezst 1y ago

I feel that whatever "OCaml - the good parts" might be, it lives through Scala today. It's syntactically familiar/pleasing, it deals equally well with your high throughput (JVM), low-footprint (scala-native), web (scala-js/scala-wasm), small script to large monolith needs equally well, and its tooling/community support is orders of magnitude better than the other functional-first "popular" languages (OCaml, Haskell, Clojure, …).