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.
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.
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.
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.
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.
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.
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
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 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
[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.
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!
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.
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...
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...
Perhaps Python devs should consider transpiling to OCaml ;)
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?
