If this were really true though, then wouldn't F# be bigger than it is?
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.
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.
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.
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...