[oriolid]

> Funny, given that the word diplomacy is a French word

This is true. But it only tells about the cultural dominance that France had at the time the convention started. If history had happened differently, Chinese, Hindi or something else could be in similar position.

> But if someone is not proficient in Rust it will only slow them down and they'll end up fighting the language and the compiler instead of using the language.

This is indeed the choice. Make it difficult to write code but more likely that the result is correct, easy to achieve high performance but risky (C++ and similar) or just accept the overhead of checking everything over at run time (JVM and CLR languages, etc). I would say there is a niche for the first.

> Why nobody ever recommend Haskell or Smalltalk?

I think at this point it's well known that the pure functional lazy evaluation model rules out too many useful data structures and makes it easy to introduce accidental complexity. As for Smalltalk, it seems (I've never actually used it) to me that most of its once unique ideas have been copied to current mainstream languages. It also seems to have a huge number of fragmented implementations and most of them seem to have a heavy runtime virtual machine.

[peoplefromibiza]

> This is true. But it only tells about the cultural dominance that France

French is still very much relevant, but it took centuries to make it less relevant than before to the point where we are now.

Rust in comparison is minutes old and there's no evidence it will dominate the field of system programming in the future. See: Ruby on Rails for web development.

> This is indeed the choice. Make it difficult to write code but more likely that the result is correct

I don't buy it.

Making it hard to write code it's nobody's choice, it's accidental complexity, that any sane language designer would avoid if possible, because it severely hinders the language adoption.

The opposite is also true: code easy to write will also be more easily correct.

Elixir is easy to write and will almost automatically be correct in complex scenarios such as distributed systems.

> pure functional lazy evaluation model rules out too many useful data structures

Rust is Haskell with a different syntax though and makes it very hard to write simple linked lists.

> most of its once unique ideas have been copied to current mainstream languages

same happened to FP, ROR and it's happening with Rust

Even Java is more functional than ever, because it's a good paradigm, not because it's a fad.

Again: this seems to me more promoting Rust than a discussion about memory safety and I am really not interested in that. So I'll see myself out.

[oriolid]

> Rust in comparison is minutes old and there's no evidence it will dominate the field of system programming in the future.

This is true (for some values of minute). It is also why I was suggesting that C calling convention, HTTP etc, not Rust, would be the computing lingua franca. Now that I think of it, a few years ago TCP/IP would have been on the list but now with HTTP/3 it's not that certain any more.

> Rust is Haskell with a different syntax though...

This is quite bold claim, but if you have a rigorous proof beyond "all Turing complete languages are the same" I would be interested in seeing it. It's a pity you left.

> ...makes it very hard to write simple linked lists.

This is interesting in the light of the beginning of the sentence, because in Haskell linked list is the easiest data structure. Simple linked lists aren't always that simple though. There is a reason why they used to be a recurring technical interview question.

> Again: this seems to me more promoting Rust than a discussion about memory safety

Funny, to me this seems more about promoting JIT and garbage collection. Nothing wrong with that, as long as you admit that there are niches where those are a problem but memory safety is still useful. And so far there haven't been other serious language candidates for that niche.