OCaml 5.0 Alpha Release
discuss.ocaml.org
discuss.ocaml.org
F# is an interesting language and yes, I used it at work a couple of times. However finding a programmer who is into that is hard and the HR "partners" will kill you because people like these can't be treated as cheap replaceable resources. So it was F# prototype -> C# production. Attempts to introduce a new language or a tech stack usually failed because the decision makers (managers) were concerned about "how many people can I hire within a month" than anything else - nobody was fired for picking Java, C# or JavaScript (TypeScript) for the next project and staffing accordingly.
Languages like OCaml, Haskell, Lisp (whatever flavour you pick) or Prolog will never become mainstream. Should they even? My favourite is one of them for my general hacking or research projects; not sure I'd like to use it in a corporate job (which I have right now). Small efficient team in a tech start-up? Hell yeah! Mainstream mundane programming? OMG NO! Horses for courses. Hearses are not mainstream vehicles yet all of us will need a ride in one occasionally. Does it mean they should become popular and mainstream? :-D
Regarding Ocaml, the functional aspect of the language is not hard. I have trained several junior programmers to write code in it (ReasonML). It is not a pure functional language. The biggest challenge for most people is dealing with types.
Ocaml's standard library is a huge sore point. It also lacks a lot of proper tooling. The biggest problem with Ocaml/ReasonML is that they are unable to rally everyone to a unifying vision to gain traction.
Nowadays C++ has closures. What will become the FAD of the day in 10 years? Will wee see embedded Prolog in C# 12 or C++31? Who knows? Like OOP has been with us since 1968? and hasn't disappeared anywhere, functional programming features will not disappear from mainstream languages. But the "cool new shiny silver bullet" will be something else. Like Simula-68 and Smalltalk-80 paved way for OOP, Haskell and OCaml (et. al.) have been paving way for functional programming and Prolog and Datalog have been paving way for logical programming. They won't become mainstream when logical programming becomes the FAD of the day.
BTW you mentioned you taught a couple of junior programmers an ML-ish language. That's awesome! We all (programming community) need more legends like you.
By definition, fad is an intense and widely shared enthusiasm for something, especially one that is short-lived; a craze. I don't see OOP enthusiasm to be short lived.
Many are still living in the Kingdom of Nouns, are follow Uncle Bob's preaching with due diligence and judge you harshly if you don't make everything a class and don't use lots of design patterns even if they are not needed.
Without verdict about what else you wrote: What a fitting description, "kingdom of nouns". I'll steal that for my next anti-mainstream-OOP-everything-must-be-a-class-rant, if you do not mind.
I think this is a bit overstated. It's roughly the same size of JavaScript, missing regexes but having some stuff that JS lacks. And in lots of languages with large standard libraries, people tend to use standard library replacements. Considering that htere are also not a lot of people working on OCaml, the core team time is better spent on stuff like multicore rather than HTTP servers and clients.
The standard library is also open to contributions. For example, in OCaml 4.14, 44 functions were added in the module Seq https://v2.ocaml.org/api/Seq.html. String also had a lot of utility functions for integer decoding in 4.13 https://v2.ocaml.org/api/String.html.
Kotlin is a Jetbrains project and it certainly didn't hurt that Google made Kotlin the preferred language over Java for development on Android, and that Kotlin itself has great Java ecosystem compatibility.
For years, Rust was Mozilla's baby, and they did a lot of good work evangelizing Rust for its use case, and other companies adopted it as well, continuing the cycle.
There is nothing I can think of that is comparable for F#, OCaml, Haskell and many other fine languages
Ruby I'm not sure what caused the hype unless it was something like Heroku making deployable Rails easy.
PHP was "easier" Perl. Perl was also ubiquitous at one time because of CGI and the web. PHP was one of the first languages to have the same ease of deployment story as Perl but a much easier syntax to deal with. Again, language space wasn't as crowded then. Certainly both were easier to use than C / C++.
It was easier to gain a foothold in the first round (web 1.0 era if you will) of software and development. There was simply less competition. Java didn't even come out till 1996.
The second era of languages, I think really starting with Go and continuing through to Rust, they faced a bigger uphill battle. There simply isn't the mindshare to capture as easily as there was back then.
Admittedly, I'm still not sure to this day why Ruby took off, other than it offered a great developer first experience as a language, from what I understand. It seems people who use Ruby tend to really like it. It seems it has a stickiness there that other languages don't, maybe? I've always been confused by this one, and I admit that's due to personal bias of not enjoying its syntax at all, however there are clearly lots of people who do. I just prefer one true way of doing things.
[0]: https://www.embarcadero.com/
[1]: https://www.embarcadero.com/products/delphi/object-pascal-ha...
Youtube, Instagram, Pinterest, Reddit etc.
CERN and Fermilab were already playing with Python as administration tool and data analysis during the early 2000's.
PHP became mainstream thanks to being a better Perl for Web applications, and the only option in many ISPs.
Ruby has Rails to thank for its adoption, a product produced by Basecamp.
Now I know correlation does not equal causation. But you have to think it must have some effect when Google is paying its Distinguished Engineers--the likes of Rob Pike, Ken Thompson--plus at least several more engineers, project managers, and others. All to work on Go. Can you imagine what the OCaml ecosystem could do with that kind of money and dedicated engineering talent? Heck, any technology for that matter.
Previously it added a lot of stuff on its own like async, etc. which was cool but also resulted in compatibility issues when c# later added similar features.
Now the f# developers are very concerned with compatibility but it basically means that f# can't get new features until c# already has them. It's also limited by the runtime which is designed around c#.
For example, it doesn't support type classes because (among other reasons) that might end up being incompatible with future c# type-class like features several years down the line.
It's also hard to learn f# unless you already know some ocaml/haskell.
ocaml has failed to catch on that much so far but I think it does have potential, and adding multicore support/effects is pretty promising.
On the other hand the fragmentation with stuff like reason/rescript is pretty dumb.
That's my impression from my last two typescript jobs, anyway. I don't know what, if anything, will come out of this, but I can't see it being bad.
I know the syntax is now incompatible syntax with OCaml so I see the broken eggs but I don't see the omelet.
Reason seems to be pretty dead so now the relationship between ocaml and rescript is kind of like that between haskell and purescript.
This may be good if you only want to run it on the frontend but it's not as good if you're using ocaml on the backend and want to share code, but I guess there's js_of_ocaml
I also don't think the existence of rescript is in itself a bad thing, it's just that the whole confusion around reason/rescript may have harmed development of ocaml for a while.
OCaml is an anchor language for many important projects (e.g. Coq) and companies (INRIA, Janestreet etc). The momentum behind OCaml has grown and I don't think the rescript/reason separation affected it _that_ much.
But I am curious to know if rescript/reason issue harmed rescript. While rescript gained a lot of technical freedom from the breakaway from OCaml it lost some people along the way. Was the breakaway worth it in retrospect?
Personal anecdote: yes, it has.
I was very interested in Reason when it appeared, and it seemed to have immense momentum: exploring arguably better (or more familiar) syntax, tool integrations etc. I know that people ran regular OCaml workflows/projects with it.
And then the whole split happened ... why? "We don't want to be constrained by OCaml" while keeping all of OCaml's syntactic idiosyncrasies among other things doesn't sound like a proper, well, reason.
This is where I stopped being interested (and as I imagine, many people stopped, too). Because a slit in a niche miniature language (which it was at the time) means only one thing: not enough resources to continue with either one.
It doesn't help that the whole split was confusing to everyone. Good description here: https://ersin-akinci.medium.com/confused-about-rescript-resc...
A lot of talent has moved onto other things (or stayed with Reason) with arguably minor gains for Rescript in terms of technical freedom gained.
Typescript is so dominant in this space that it really didn't make sense to split an already small community.
They accepted to place it on the box, but never gave it the same love as VB and C#, or even C++/CLI, and now they could rename the Common Language Runtime into C# Language Runtime, given how little outside they give to anything not C# on newer workloads.
Had F# been given feature parity with C# and VB on Visual Studio tooling and core frameworks, the adoption scenario would be much different.
Idk about that, especially in the past decade. Python seems to be the most popular language that people pick up on their own as their first one.
As for the intro college courses for programming, they mostly seem to be Python or Java, with occasional C (havent seen that one myself yet for an intro class), and one incidence of OCaml (apparently Cornell teach their intro to CS in it).
https://en.wikipedia.org/wiki/Generational_list_of_programmi...
Comparatively, OCaml was initially written with symbolic operations in mind, and thus I personally think it's a great language for writing parsers, compilers, modeling systems etc. The type system makes it easy to avoid certain kinds of common errors in those programs and the tail latency of GC operations is typically not as important for those applications as overall throughput. I don't think that heavy symbolic computations are a mainstream target though. To be clear I think that's absolutely OK for a language not to aim for mainstream use; but if one wishes for mainstream use, then it's important to be clear about the kinds of use-cases within mainstream that will be targeted.
It has been a while since I played with the language though, so maybe things have changed since. Happy to learn more if I'm wrong and OCaml now has a clear mainstream target use case in mind.
Sure, OCaml's heritage is descended from a theorem prover helper language, but that doesn't meant it's forever stuck at that use case. Python was originally an educational teaching language, nowadays it's a data science and glue language. None of that was planned out in advance by the Python folks.
In fact even if you ask the Go team, Go is arguably the most targeted language of the ones you listed, in terms of its use case--and they were surprised that a lot of their userbase came from ex-Python devs who wanted something more reliable and efficient!
OCaml with version 5 is just hitting its stride. With the advances in the language, the multicore support, and tooling, it's going to be competitive with Rust for many use cases. It's worth the wait to see where it goes.
Java was an OO, garbage collected language that supported (sort of...) hot swapping code. Go was a reasonably performant, garbage collected language that compiled to static binaries and has great cross-platform support. Some grad student decided to write Spark in Scala so you had to use it for Spark jobs Rust is a systems programming language with zero-cost abstractions and no GC that allow you to write mostly memory-safe code.
What is the killer feature of OCaml that makes it worth the investment?
Does checking the concurrency box make OCaml an awesome choice for some use case?
You mention Rust for example but that language is sort of built around a zero cost abstraction principle, which is very much not the case of OCaml, so I still think it's going to be viewed as risky for highly performance sensitive work.
For truly performance-sensitive work of course people are going to choose C/C++/Ada/Rust.
Mainstream languages have killer software (Spring, Synfony, Pandas, whatever) which then prompts adoption.
Languages for mainstream programming are less of an issue than the software.
Haskell, CommonLisp, etc, plenty of great languages lack that killer software or clear benefits over other mainstream languages.
Sometimes the language is chosen by luck (e.g. company requires it) but many times a programmer will make an explicit choice to use that language.
Same thing for Spring. Spring came about as an attempt to make J2EE more usable, which is to say, it didn't exist until years after Java was already being widely adopted in the industry.
Checking on Symfony since I'd never heard of it, it was first released in 2005, which was after PHP had already become popular enough to become the archetypal "bad language" in the minds of people who had never used it.
I think what you're seeing is that the ecosystem that develops around languages reflects their popularity and the interests of their users. As a readable, low-complexity glue language, Python became popular with scientists and then (unsurprisingly in retrospect) people started using it for data analysis. Java became popular with big iron enterprise programmers, and so it sprouted enterprise frameworks where half your code was in XML. PHP was popular for small web sites, so it spawned a whole menagerie of web programming frameworks. A language without any ecosystem growing around it is probably a language that doesn't get used much.
For a more contemporary example of language adoption, look at Rust. The appetite for the language existed from the get-go based on its design and stated goals. There was a lot of excitement, even from people who said they couldn't adopt it yet because of the lack of ecosystem around it. As the ecosystem developed, more and more people adopted it the moment it was practical, establishing it as a mainstream, growing language prior to the existence of any killer software. In the future maybe there will be a killer Rust framework that brings in a lot of people with no interest in Rust the language, but Rust is thriving despite that killer app not existing yet.
Is this planned for after 5.0? Anywhere I can learn more?
Getting an effects system with handlers in a (semi)large and mature language is a pretty big step.
The Koka language [1] has a brilliant implementation of algebraic effects. Sadly it's a research language that doesn't see much development.
[1] https://koka-lang.github.io/koka/doc/book.html#why-handlers
The best developed one is "eio", which uses effects (and io_uring on Linux) internally in order to provide a really high performance, direct-style IO library for OCaml. You can walk through some of the code here: https://github.com/ocaml-multicore/eio#getting-started
Also a video talk about our experiences with using effects for writing parsers, from the OCaml Workshop last year. https://watch.ocaml.org/videos/watch/74ece0a8-380f-4e2a-bef5...
Awesome job to all the devs.
I don't know much about the intricacies of unicode but as usual there are some OCaml libraries available. Are they incomplete/insufficient in some way?
1. A statically compiled language with GC-d runtime, which compiles quicker than golang
2. Something that brings algebraic effects to the mainstream and with it an arguably better model for concurrency / parallelism
3. Support value types to take advantage of modern CPU caches
Finally golang finds some real competition (from a very unlikely source though). Hoping ReasonML will become more popular with this release with true parallelism and nice concurrency.
But not everyone agrees with the split and work is being done on Melange to replace Bucklescript : https://github.com/melange-re/melange
Ultimately JsOfOcaml can directly transpile Ocaml to JS.
Apparently it's not. The whole thing is a mess :)
https://ersin-akinci.medium.com/confused-about-rescript-resc...
Maybe finally Rust+tokio projects will have some actual competition!
I think all these "properly typed" languages should aspire to have great interoperability: after all, they have types to help. But I realize there can be big technical difficulties in making it safe, in particular with garbage collection..
The syntax is really cool, it looks like python but it's completely whitespace insensitive.
The module system is neat, and I actually like writing module interfaces (which are basically analogous to header files in C/C++). It makes dependency injection trivial, because you can have a module say "I depend on a module with this interface, but the caller can choose which one", which is more useful than it sounds.
It's also a functional language, so you have very little mutability, and it supports """monads""" with its super innovative "monadic let" syntax. (It's basically like overloading the semicolon, which probably doesn't make any sense, but it's really cool.)
Dune is a very pleasant build system and Esy is a very pleasant package manager. The language server is good. I'd say in this dimension it's competitive with Rust.
There's really quite a lot to like about OCaml. My biggest gripe with it is no typeclasses/traits. But I have hope that modular implicits will land within our lifetimes.
You say it is a package manager. Is it supposed to replace opam ? If so what does it offer that opam doesn't ?
I'm squinting really hard but not seeing the resemblance.
That's compensated by the use of double semicolons :O)
the readme of ocaml-interop says it's "inspired by" ocaml-rs
while ocaml-rs says it "uses ocaml-interop behind the scenes" and "also exports an interop module, which is an alias for ocaml_interop and the two interfaces can be combined if desired"
from a cursory look over ocaml-rs seems possibly the one to use, as the more comprehensive project
I've heard Haskell praise a good amount of times but at the same time many people also said that doing actual work with it has more friction than it should, so I don't know.
"Parallel and Concurrent Programming in Haskell" (2013)
https://www.oreilly.com/library/view/parallel-and-concurrent...
Have Haskell's ergonomics improved?
I feel your snark is unjustified. You might be putting people in two extremes: wise elders and hip kids. There's a huge amount of people in-between however.
(Also, the saying actually is: "You're going to where I am coming back from".)
Find me something like Erlang/Elixir with the speed of Rust and I won't learn another programming language ever again.
No? Then the search continues.
So far Haskell hasn't impressed. In all honesty Rust is quite hard to put in that niche as well since its `async` stuff is extremely annoying and hard to get right but I guess the tries are still ongoing. OCaml is progressing but who knows when will they get there.
https://engineering.fb.com/2015/06/26/security/fighting-spam...
As a guy who went through at least 8 languages and 30+ frameworks, it gets tiring. I want something that ticks most boxes from the get go.
You're describing haskell again.
You haven't articulated why you have disliked haskell in the past.
That could be okay for many but as I get older, I tend to take people/organizations that require big upfront investment less seriously.
Example: one of the things Elixir has won me over with were its bite-sized introductions and practices. You can be a 3/10 Elixir dev and you can be a 8/10 one, and that's mostly depending on how many of the official tutorials you've covered. The road is mostly a straight line to an acceptable level of proficiency at the end of which you can start choosing to specialize.
Rust, OCaml, Haskell -- they all failed that test for me.
I picked Rust mostly because of the no-GC situation and because of `cargo`. Many older programmers handwave away the importance of good tooling and this is where they lose a lot of potential mind share that can rejuvenate their languages / ecosystems.
Example on this: OCaml's tooling. A lot of people in this ecosystem always degrade the importance of a good task runner + builder + project manager. I spent half a weekend learning `esy` once and mostly tamed it by making it imitate mix/cargo but it wasn't trivial. The end result is a build script that does 80% of what mix/cargo do. The exercise made me scratch my head wondering why what I did back then isn't upstreamed and made official and why is everyone happy to pretend that building an OCaml project is a solved problem when it (very!) clearly isn't.
Haskell's cabal didn't fare better last I tried it -- admittedly that was more than a year ago.
If Haskell has good bite-sized lessons that lead to an actual real job productivity (less academic exercises, please!) then I'd be happy to give it a fair try and maybe make it a part of my toolbox.
Your assessment reflects mine entirely. Elixir has that charm in that it leads you to productivity quickly, just as Go does. Someone could argue that's only because of much larger pool of users that's paved the path before.
Picking up Haskell again for fun, and the Effective Haskell book has been a fun learning experience. Not too beginner-ish, and doesn't take too much time to explain concepts.
I'll have to try esy and dune again sometime when OCaml 5's stable. Their commands are just different enough from go/cargo/npm to be annoying.
Specifically, I realized how many problems we solved using OTP that would be much more challenging to get right otherwise. We can use processes to get transactional behavior, spawn workers very simply.
We use event sourcing.
Our state snapshots are just a process that receives events. It was easy to evict snapshots by killing processes idle for too long. Beautiful!
Test coverage becomes mostly wishful thinking. And it's extremely easy to do non-exhaustive pattern-matching which is something that just kills me.
It's absolutely true that Elixir is mega-productive though. And for a ton of projects out there it's good enough and more.
Well, based on your comment, I might reevaluate Haskell. Last time I was severely put off by lack of good tooling (but I did hear cabal was improving) and a fragmented ecosystem. Maybe things have changed.
nix-shell -p 'haskell.packages.ghc{version).ghcWithPackages (pkgs: with pkgs; [any number of packages here])'
But it's not only that. It's a general problem of a high initial learning curve.
Modern tool inventors really have to finally learn that everyone is super busy these days. Make it brain-dead quick to learn or your tool will forever remain a niche curiosity for hobbyists.
The reason I brought up the nix command is that I only use nix, for haskell development, for that specific command: I found it once in a blog post, saved it, then put it under a function into my bashrc, and I use nix quite literally for only that purpose. I've done a lot of development on various functional languages (with a dayjob in F# that lasted 3 years) and being able to quickly experiment with libraries was something that I sorely missed when doing repl experimentation in those languages (I think F# recently got a #nuget directive, but that was after I stopped using it).
Not to be the party pooper: didn't Docker work well for your Haskell use-case?
Let's talk productivity in commercial projects. Or making scripts for your own use (if you're not happy with bash/zsh/fish... which I'm not).
Haskell only exceeds rust+tokio in terms of overall code elegance and succinctness.
When it comes to performance, rust+tokio is going to be much more performant by default as there will be no GC, no hidden traps with laziness, no subtle memory leaks etc.
Sure, a Haskell wizard will be able to reduce the gap further and solve issues but it is going to be difficult to consistently beat rust+tokio. By the time said Haskell wizard makes changes to the code, the famed elegance of Haskell is going suffer as the code will be littered with strange incantations of strictness annotations, possibly some C-ffi and other magic. This will not be the beautiful Haskell that you learn in textbooks. Only very few people know how to make Haskell truly fly. If you're one of them, then you're lucky!
This is nonsense without significant further qualification.
I guarantee the tokio scheduler and async stack model gives you net worse results for many real workloads.
What I meant was in the typical case, you can expect rust+tokio to be faster than Haskell. This is not a surprise as rust is much more low level, does not have a GC and its compiled output maps better to modern processors rather than the pure functional lazy style of Haskell.
Plenty of benchmarks across a variety of workloads and program confirm that Haskell is slower than rust on average. For webserver type use cases (which uses a lot of Async) Rust is faster. Check out tech empower benchmarks for example.
[1] https://github.com/ocaml-multicore/domainslib
[2] See the http server performance graphs at https://tarides.com/blog/2022-03-01-segfault-systems-joins-t...
I've scanned several articles (some made by you) and I very much like what I'm seeing.
Perhaps Python devs should consider transpiling to OCaml ;)