Så du bruker det kun under utvikling, ikke i prod?

Jo, det første punktet gjelder i prod også. Jeg setter (s/check-asserts true)(kunne også gjort det med en Java system property), og har mange funksjoner med {:pre [(s/assert ::en-eller-annen-spec et-argument-til-funksjonen)]} . Så det feiler i produksjon hvis input er feil. Men det gjør det jo ikke, for jeg har tester! 🙂 Joda, det hender det feiler, men det er fordi jeg ikke har forutsett et eller annet. Da skriver jeg en test, fikser koden som kaller den aktuelle funksjonen, og går videre.

Ahh. Det var mitt neste spørsmål egentlig, om du gjorde dette via :pre ☺️

Det fins noen (assert (s/valid? ::en-eller-annen-spec et-argument) "En forklaring") rundt forbi også. Den praktiske forskjellen er vel bare hvordan man eventuelt skrur av/på kastingen av exceptions.

Jeg baserte et ui-bibliotek på spec en gang i tiden. Var også veldig fornøyd med bruken av det på den måten, men mener å huske at det ble litt performance problemer. https://github.com/bdo-labs/ui

trenger litt kjærlighet for å kunne kjøre det repoet nå tror jeg 🙂

av verktøy for concurrency i Clojure har jeg brukt: 1. Immutable data 2. Atoms 3. Ekstern database. Føler at jeg er i samme båt ...