Not who you are responding to, but the common idea that static types are all win and no cost has become very popular these days, but isn't true, it's just that the benefits of static typing are immediately apparent and obvious, but their costs are more diffuse and less obvious. I thought this was a pretty good write up on the subject that gets at a few of the benefits https://lispcast.com/clojure-and-types/

Just to name some of the costs of static types briefly:

* they are very blunt -- they will forbid many perfectly valid programs just on the basis that you haven't fit your program into the type system's view of how to encode invariants. So in a static typing language you are always to greater or lesser extent modifying your code away from how you could have naturally expressed the functionality towards helping the compiler understand it.

* Sometimes this is not such a big change from how you'd otherwise write, but other times the challenge of writing some code could be virtually completely in the problem of how to express your invariants within the type system, and it becomes an obsession/game. I've seen this run rampant in the Scala world where the complexity of code reaches the level of satire.

* Everything you encode via static types is something that you would actually have to change your code to allow it to change. Maybe this seems obvious, but it has big implications against how coupled and fragile your code is. Consider in Scala you're parsing a document into a static type like.

    case class Record(
      id: Long,
      name: String,
      createTs: Instant,
      tags: Tags,
    } 
    
    case class Tags(
      maker: Option[String],
      category: Option[Category],
      source: Option[Source],
    )

//...

In this example, what happens if there are new fields on Records or Tags? Our program can't "pass through" this data from one end to an other without knowing about it and updating the code to reflect these changes. What if there's a new Tag added? That's a refactor+redeploy. What if the Category tag adds a new field? refactor+redeply. In a language as open and flexible as Clojure, this information can pass through your application without issue. Clojure programs are able to be less fragile and coupled because of this.

* Using dynamic maps to represent data allows you to program generically and allows for better code reuse, again in a less coupled way than you would be able to easily achieve in static types. Consider for instance how you would do something like `(select-keys record [:id :create-ts])` in Scala. You'd have to hand-code that implementation for every kind of object you want to use it on. What about something like updating all updatable fields of an object? Again you'll have to hardcode that for all objects in scala like

    case class UpdatableRecordFields(name: Option[String], tags: Option[Tags]) 
    def update(r: Record, updatableFields: UpdatableRecordFields) = {
      var result = r
      updatableFields.name.foreach(r = r.copy(name = _))
      updatableFields.tags.foreach(r = r.copy(tags = _))
      result
    }

all this is specific code and not reusable! In clojure, you can solve this for once and for all!

    (defn update [{:keys [prev-obj new-obj updatable-fields}]
      (merge obj (select-keys new-fields updatable-fields)))
    
    (update 
      {:prev-obj {:id 1 :name "ross" :createTs (now) :tags {:category "Toys"}} 
       :new-obj {:name "rachel"} 
       :updatable-fields [:name :tags]})
      => {:id 1 :name "rachel" :createTs (now) :tags {:category "Toys"}}  

I think Rich Hickey made this point really well in this funny rant https://youtu.be/aSEQfqNYNAc.

Anyways I could go on but have to get back to work, cheers!