Doesn't the "O" in OCaml stand for "Object", though? I think you could pick up either F# or OCaml just as easily.

The nuances of OOP in F# can be ignored by beginners, so I really wouldn’t let yourself be intimidated coming from Clojure.

[0] https://ocaml.org/docs/objects

OCaml classes and objects are (ironically) rarely used and generally discouraged. There are some cases where they’re practically required, such as GUI and FFI (js_of_ocaml). But otherwise, most code does encapsulation and abstraction using modules and functor modules (which are more like Haskell and Rust typeclasses than traditional OOP classes).

I don’t know much about F#, but last time I used it most of its standard library was in C# and .NET, so F# code would interact with objects and classes a lot. AFAIK F# also doesn’t have functor modules, so even without the dependence on C# code, you still can’t avoid classes and objects like you can with OCaml (e.g. you can’t write a generic collection module like `List` or `Set` without functors, it would have to be a collection of a specific type or a class).

F# uses .NET's generics, so the statement regarding List/Set is completely incorrect (in fact, all base collections are generic).

I think you misread their claim - they said that generic list/set would have to be classes, not modules (generic modules are a specific thing in OCaml and aren't the same as a module of generic classes).

F# has "generics" just like Python and PHP now "have types".

It's not a yes/no feature.

Give F# a try. It has, and always had, true generics.

https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...

> It's not a yes/no feature.

FTFM: It's not a true/false feature.

Alright. Humor me, what is the issue with F# generics as compared to other languages with generics? Which implementation (that is productively useful) is a "true" one?

> Clojure emphasizes immutability

Is "emphasizes" just another word for second-class support?

C++ emphasizes the importance of memory safety.

Immutability is definitely first class in clojure, but you can work with mutable structures when you need to.

This is sounds like memory safety in C++.

https://www.infoworld.com/article/3714401/c-plus-plus-creato...

This seems like a meaningless criticism when it comes to immutability in Clojure. You can have mutability in Haskell too. That doesn’t make it as unsafe as memory management in C++.

> You can have mutability in Haskell too.

Haskell enforces this via a type system.

What safeguards around mutability does Clojure have?

If I import a method 'foo()', is there any kind of contract, notation ... anything which could suggest whether it mutates or not?

> What safeguards around mutability does Clojure have?

Very nearly the entire language and standard library operate on immutable values only. Immutable values are the default, and you will use them for the vast majority of logic. You must do so, unless you very specifically opt to use dedicated reference types, at which point you’ll still need to produce intermediate immutable values to interact with that vast majority of the standard library.

And…

> is there any kind of contract, notation ... anything which could suggest whether it mutates or not?

Functions which mutate state are almost always suffixed !. They will typically fail if you pass them immutable values; they only operate on reference types, which have to be dereferenced (typically with the prefix @) to access their state.

> Is "emphasizes" just another word for second-class support?

I don't know what's your personal definition of "second-class support" but what it means is that it's explicitly supported by the language.

C++ explicitly supports memory-safe programming. You can choose whether you want to mess around with raw pointer arithmetic.

What safeguards does the language actually put in-place?

> C++ explicitly supports memory-safe programming. You can choose whether you want to mess around with raw pointer arithmetic.

I don't think you know what you're talking about. Managing object ownership through systems like smart pointers is not memory safety. Applications that use smart pointers still suffer from memory issues, and it's possible to adopt object ownership systems that still use raw pointers, such as It's object ownership system.

> I don't think you know what you're talking about.

Right. I sound just like someone talking about how "a language which emphasizes immutability" is an OK replacement for a language with pure functions.

The world is much less black and white than you’d like to see it.

Functions in Haskell including Prelude can throw exceptions which is not reflected in the type signature of the function. That is an effect that makes seemingly pure functions impure.

You can’t judge a language from a list of buzzwords. You need to look at how it is used in practice.

> Functions in Haskell including Prelude can throw exceptions which is not reflected in the type signature of the function. That is an effect that makes seemingly pure functions impure.

No, bottom, or _|_, is an inhabitant of every lifted type. An exception is bottom. So the / function is still pure even though it can throw a divide-by-zero exception.

Does it make it type-safe though? In dynamic languages type errors also result in exceptions.