Optional typing is not highly desirable. Everyone got all starry-eyed when they talked about how object oriented programming would allow you to have a
container of
objects and you could just put any arbitrary object into the container. Which is a great idea as long as you don't really think about it. Eventually you have to know what kind of object you're holding and you actually to use it to do some real work. The same thing goes for functional programming. Eventually you need to know what kind of data you're operating on, and you actually have to operate on it to do some real work. When the time comes to do some real work, you quickly realize just how much of a mess optional typing makes of your program.
I've looked at a lot of code over the years that pushes the actual work to be done around like a two-year-old pushes peas around a plate. I've gotten to the point where I can read the mind of the programmer through the code he's written. He's thinking "If I push this over here maybe it will magically go away and I won't have to deal with it." Most of the time this is because he doesn't actually understand the business logic behind the code he's writing. He's writing to a series of requirements but he has no understanding of why the requirements exist or how they drive the business. So he tries to keep his code abstract as possible and hopes that no one notices.
Sadly no one has yet written a language that forces you to actually understand the problem domain that you're coding. I'm sure it wouldn't be very popular if anyone ever did. Neither has anyone actually managed to write a language that allows you to write useful code without understanding the problem domain, and no one ever will. Now if someone could write a language that a non-programmer who understands why he needs code written to describe what needs to be done directly to the computer, that might fundamentally change my job description. Given that most of those people obviously can't even express this to another human being (Judging from their requirements docs,) I'm not losing any sleep over it.
What the people who flit from language to language or framework to framework like bees are looking for is a tool that allows them to write code without understanding a problem. Someone who actually understands the problem will always outperform them in any given language. In other words, just because your language has an expressive syntax or any specific feature doesn't mean you can hire chimpanzees to code your application.