[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.
[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.
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).
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.
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.
I definitely find it (and jetpack compose) make developing android apps a much better experience than it used to be.
What I like a lot about Kotlin are its well written documentation and the trailing lambdas feature. That is definitely directly OCaml inspired (though I also recently saw it in a newer language, the "use" feature in Gleam). But in Kotlin it looks nicer imo. Allows declarative code to look pretty much like json which makes it more beginner friendly than the use syntax.
But Kotlin doesn't really significantly stand out among Java, C#, Swift, Go, etc. And so it is kind of doomed to be a somewhat domain specific language imo.
If that wasn't the case, Google would support Java latest with all features, alongside Kotlin, and let the best win.
See how much market update Kotlin has outside Android, when it isn't being pushed and needs to compete against Java vLatest on equal terms.
Android is Google's J++, which Sun sued and won.
Kotlin is Google's C#.
Plus everyone keeps forgetting Kotlin is a JVM based language, Android Studio and Gradle are implemented in JVM languages, JVM are implemented in a mix of C, C++ and Java (zero Kotlin), Android still uses Java, only that Google only takes out of OpenJDK what they feel like, and currentl that is Java 17 LTS, most of the work on OpenJDK was done by Oracle employees.
I think it will be very hard for us to find anything in common to agree on then.
Anyway, it’s pretty clear Google is pushing Kotlin because they don’t want to have anything to do with Oracle which has not been cleared by the verdict of their last trial. The situation has nothing to do with anything technical.
Blaming them for pushing Kotlin when the alternative you offer is them using a language they have already been sued for their use of seems extremely misguided to me.
I call them dishonest by comparing outdated Java 7 subset with Kotlin, when back in 2017 the latest version was Java 9, and in 2025 it is Java 24, and yet the documentation keeps using Java 8 for most examples on Java versus Kotlin.
How come Google doesn't want to have anything with Oracle, when it is impossible to build an Android distribution without a JVM, again people like yourself keep forgeting OpenJDK is mostly a product from Oracle employees (about 80%) with remaing efforts distributed across Red-Hat(IBM), IBM, Azul, Microsoft and JetBrains (I wonder what those do on Android), Kotlin doesn't build for Android without a JVM implementation, Gradle requires a JVM implementation, Android Studio requires a JVM implementation, Maven Central has JVM libraries,....
If Google doesn't want anything to do with Oracle why aren't they using Dart, created by themselves, instead of a language that is fully dependent on Oracle's kigdom for its own very existence?
They clearly don’t want to add anything which couldn’t be reasonably covered by the result of the previous trial.
The list you give was all already there then. Moving to a more recent version of Java wouldn’t be.
> OpenJDK is mostly a product from Oracle employees (about 80%)
Sun employees, not Oracle employees. Using Sun technology was fine, using Oracle technology is something else entirely.
Can start here, https://dev.java/contribute/openjdk/
"Once you have contributed several changes (usually two) you can become an Author. An author has the right to create patches but cannot push them. To push a patch, you need a Sponsor. Gaining a sponsorship is usually achieved through the discussions you had on the mailing lists.
In order to become an Author, you also need to sign the Oracle Contribution Agreement (OCA)."
The go into https://openjdk.org/bylaws
"The OpenJDK Lead is an OpenJDK Member, appointed by Oracle, who directs the major efforts of the Community, which are new implementations of the Java SE Platform known as JDK Release Projects."
And this nice contribution overview from Java 22,
https://blogs.oracle.com/java/post/the-arrival-of-java-22
"Of the 26,447 JIRA issues marked as fixed in Java 11 through Java 22 at the time of their GA, 18,842 were completed by Oracle employees while 7,605 were contributed by individual developers and developers working for other organizations. Going through the issues and collating the organization data from assignees results in the following chart of organizations sponsoring the development of contributions in Java:"
To spare you the math, 77% were done by Oracle employees.
Now please show us how Kotlin compiles for Android without using Java.
Doesn't look like Google got rid of Oracle to me, more like they didn't even considered Dart, nor Go could stand a chance against the Java ecosystem among Android developers.
Your link doesn’t change any of that nor your clearly condescending comment before. You are perfectly aware of the fact by the way and you know exactly what I meant so I don’t really understand the game you are playing.
Oracle can claim Sun contribution as their own as much as they want. It doesn’t change the fact that you would have to be insane to touch anything they do now that it’s Oracle property.
I wonder what magic pixie dust has been writing Java code since 2013, those Sun employees have been working really hard on their ghost offices, surrounded by Oracle daemons, down in the dungeons.
I am playing the FACTS game.
You are free to pretend that Oracle is a great steward of the Java ecosystem if you want or that they had a point in the trial they so brilliantly lost.
I’m free to say I vehemently disagree and perfectly understand why Google would rather stay far away.
I would rather prefer you didn’t insult me however but you do you.
Kotlin has a very similar syntax to Groovy, which already had that feature (it looks identical in Groovy and Kotlin)... and I believe Groovy itself took that from Ruby, I believe (Groovy tried to add most convenient features from Python and Ruby). Perhaps that is what came from OCaml?? No idea, but I'd say the chance Kotlin copied Groovy is much higher as JB was using Java and Groovy before Kotlin existed.
People agree to go to great lengths to use a tool that has some kind of superpower, despite syntactic weirdness or tooling deficiencies. People study and use LISP descendants like Clojure, APL descendants like K, "academic" languages like Haskell and OCaml, they write hobby projects in niche languages like Nim or Odin, they even use even C++ templates.
Why is Ada so under-represented? It must have a very mature ecosystem. I suspect that it's just closed-source mostly, and the parties involved don't see much value in opening up. If so, Ada is never going to make it big, and will slowly retreat under the pressure of better-known open alternatives, even in entrenched areas like aerospace.
https://www.ghs.com/products/ada_optimizing_compilers.html
https://www.ptc.com/en/products/developer-tools/apexada
https://www.ddci.com/products_score/
http://www.irvine.com/tech.html
http://www.ocsystems.com/w/index.php/OCS:PowerAda
http://www.rrsoftware.com/html/prodinf/janus95/j-ada95.htm
Ada was too hardware demanding for the kind of computers people could afford at home, we could already do our Ada-like programming with Modula-2 and Object Pascal dialect hence how Ada lost home computing, and FreePascal/Delphi would be much more used today, had it not been for Borland getting too gready.
On big iron systems, espcially among UNIX vendors they always wanted extra bucks for Ada.
When Sun started the trend of UNIX vendors to charge for the developer tools as an additional SKU, Ada wasn't part of the package, rather an additional license on top, so when you already pay for C and C++ compilers, why would someone pay a few thousand (select currency) more if not required to do so, only because of feeling good writing safer software, back in the days no one cared about development cost of fixing security bugs.
I have a pet theory that it shares the same thing as any heavily typed language; it's difficult. And people aren't willing to accept that when you get it to compile at all, it'll probably work fine.
So many developers (and many more middle management) are not willing to trade the longer term stability/lack of runtime errors for the quick-to-production ability of other languages.
The GNAT Ada compiler, always open source and quite good, has been freely available since the 1990's. It has been part of GCC since about 2003.
There are plenty of open source Ada projects on GitHub and other places although not nearly as many as some other languages.
The Ada ecosystem is mature and complete, particularly the GNAT related tools supported by directly or indirectly AdaCore (https://github.com/AdaCore and https://alire.ada.dev/).
The language evolution has been stable and is still on-going. I have worked primarily with Ada for 30 years. I still work on new Ada projects on a mid-sized team. Most of us just don't participate in forums like this.
The immediate response I heard anytime Ada was mentioned was that it was a designed-by-committee language[1] that couldn't even be fully implemented due to a theoretically impossible specification[2]. It was made by a bunch of bureaucratic stiffs and was all about constraining the developer with stupid rules and bogging them down with verbosity. It was contrary to the freewheeling nature of the PC developer culture that sprung up in the 70's and continued through the 80's, and then evolved into the dot-com developers of the 90's and 00's.
It took decades of wandering through the deserts of "Real Developers don't write buffer overflows" on one end, and "Performance doesn't matter, and a sufficiently smart compiler will provide it anyway" on the other to get to the point where mainstream developers wanted a language that combined the safety of high-level languages with the control of low-level languages.
[1] This is false, it was selected in a contest with each entry developed independently.
[2] True but overrated
IIRC, in response, DARPA (et al) did invest in compiler research.
> adoption has never really recovered
Ya. Timing. There's a brief window of opportunity for new languages (ideas) to catch on before the horde of "worse is better" solutions overwhelm the field.
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.
Not to mention Linux I guess
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.
* 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.
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).
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_e...
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.
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.
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!
Choice is good of course so do keep up the good work.
I will upvote your comment nonetheless. I see it has been DVd which I don't like to see - we all have our views.
Genealogy is really hard but it is important to not get too bogged down with formality and get the data stashed in one form or another. Genealogy "facts" decay with a horribly short half life. It is also important to accept all "facts" as is and not try to interpret them too much - that's something else.
I'm 55 years old and have memories dealing with my grandad on my mother's side who was born in 1901. So, within reason, I can record some second hand facts going back to very early C20. My parents were born 1942/3. etc etc. However, the gold standard is written evidence of a fact.
I think that genealogy really needs to discover systems like Elastic/Open Search and not try to coerce the data to a fixed schema.
Everyone thinks their family tree is a tree. No it really isn't - it's a thicket!
I have a relative that my uncle found from Padstow in Cornwall in C16 - her first born was probably a bastard fathered by the local squire's son. There's a soldier from WWI whom the family "knowledge" from around two generations ago was convinced he was a deserter. It turns out he was honorably discharged and emigrated to Canada. On of my G^5 dad died from septicemia after punching a window in a drunken pub brawl.
All of the above has documentary evidence, expect for the desertion thing, which turned out to be bollocks. Oh there is a good chance of a mass-murderer back in C18 near Devizes, Wiltshire!
This is where IT gets really interesting. How on earth do you go about genealogy data? You are sure to piss off someone(s) who want to wear the rose tinted specs and if you think modern politics are a bit challenging, why not try to deal with politics across centuries and the random weirdness that is your own family 8)
My extremely naive approach would a scheme where you have a header containing a list of used types of information fields, then a list of entries for people, then relationships (genealogical descendants, familial relationships with a start and end date (optional, YMD format, that you only fill in with as far as you know, so if you only know the year, you just set that.)) then a list of various events, then a list of supporting documents with a confidence value, where each document has a list of people and a list of events they are relevant to. then a list of basically freeform fields, that can link to events, documents, people, etc. where the types are defined in the header.
typing this out at 2 in the morning, so sorry for the incoherence.
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.
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.
I mean, that was my beginner impression and at least half of the Scala developers I asked about this agreed. Also I just never found the improvement over Java good enough, that wasn't worth all the downsides. This is even more true with modern Java or Kotlin. Same benefits but it's easier to read, not harder.
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.
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)
(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).
Whereas the Go and Rust communities, for example, were just fine with having corporate sponsorship driving things.
They really don't, less than 5% of opam packages depend on Base and that's their bottom controversial dependency I'd say. Barely anyone's complaining about their work on the OCaml platform or less opinionated libraries. I admit the feeling that they do lingers, but having used OCaml in anger for a few years I think it's a non-issue.
What they do seem to control is the learning pipeline, as a newcomer you find yourself somewhat funneled to Base, Core, etc. I tried them for a while, but eventually understood I don't really need them.
But going way back while yeah the team at Google controlled the direction, there were some pretty significant contributions from outside to channels, garbage collection, and goroutines and scheduling..
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.
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
[2]: https://docs.scala-lang.org/scala3/reference/experimental/cc...
I think it was more about "the performance of C, but with memory safety and data race safety".
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.
A lot of effort went into making it efficient thanks to the web, while python sorta has its hands tied back due to exposing internals that can be readily used from C.
OCaml's GC design is a pretty simple one: two heaps, one for short-lived objects and another one for the long-lived objects, and it is a generational and mostly non-moving design. Another thing that helps tremendously is the fact that OCaml is a functional programming language[1], which means that, since values are never mutated, most GC objects are short or very short-lived and never hit the other heap reserved for the long-lived objects, and the short-lived objects perish often and do so quickly.
So, to recap, OCaml’s GC is tuned for simplicity, predictable short pauses, and easy interoperability, whereas Java’s GC is tuned for maximum throughput and large-scale heap management with sophisticated concurrency and compaction.
[0] Maybe it still is – I am not sure.
[1] It is actually a multiparadigm design, although most code written in OCaml is functional in its style.
That surely has a performance cost.
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)
Just Arc, clone and panic your way to success! :)
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.
> 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
Maybe I got lucky being in one of the most relevant universities in Portugal, however I can tell that others in the country strive for similar quality for their graduates, even almost 40 years later.
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.
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 "
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.
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).
>> 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.