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.