I think I'd rather move them into the repo itself. it's just a big job I've been avoiding, but there's some useful nuggets in there.

any help would be appreciated

it would certainly help with getting them nicely displayed on clojuredocs (if that's a goal of yours)

how does that work?

i mean cljdoc, sorry

cljdoc will analyze your jar to build the api reference docs, and it will also go to the associated git repo and use a doc/cljdoc.edn file to build "documentation" pages.

here's my linter Splint's cljdoc page: https://cljdoc.org/d/io.github.noahtheduke/splint/1.14.0/doc/home

yeah that looks like a great idea

what's your vision?

guardrails syntax => static typing?

it just compiles to malli and spec right? there's early work on that here: • https://github.com/typedclojure/typedclojure/tree/main/example-projects/spec1-type-providers • https://github.com/typedclojure/typedclojure/tree/main/example-projects/malli-type-providers if you could tweak those examples to use guardrails syntax I'd be happy to add new example projects to the test suite.

Yes. In the end guardrails are backed by malli. I’m wondering if we can get all of the goodness of core.typed 😍 for free!

It's worth a shot! I need people to try it and report bugs, because I didn't fully implement the translation from malli to types https://github.com/typedclojure/typedclojure/blob/main/typed/malli/src/typed/malli/schema_to_type.cljc

I feel that most of the people want optional typing in Clojure, but till malli is alpha not so many are keen to invest time on it.

my hot take: there's a consistent desire for better error messages, I don't know if most people care how they get it. IMO a dev-only debug clojure jar that hardcodes error messages would go a long way.

I've been thinking that for a long time and 1) it's not going to happen, 2) forking clojure is bad for the community. I'm thinking of resurrecting dynalint which hardcodes error messages. https://github.com/frenchy64/dynalint

I would also love to see guardrails support 🙂 Is adapting the example project to it enough to help?

yeah that's all that's needed. just add a new namespace in the spec/malli example projects with the equivalent guardrails forms.

If it doesn't work I will look at it

clj-kondo is completely static checking like Typed Clojure, except it's (currently) less ambitious in terms of expressivity (no polymorphism) and more successful in terms of usability (caching, performance, active community).

Schema, Malli, and spec are pretty similar in that they do completely runtime checking. Malli and spec are basically the same in many ways. What sets them apart from schema is they have regular expressions for sequences and a better generative testing story. Also Schema's error messages are often great and readable.

There's a few bridges being built to take advantage of all the specs that already exist in schema, spec, and malli to get static type checking for free. Malli can output clj-kondo annotations. Typed Clojure can convert Malli and spec specs to types.

> How does static typing, which I assume Typed Clojure is an example of, differ from what spec, Malli, and Schema are? Typed Clojure and clj-kondo are static typing. they analyze the source code of your program before it's run and flag potential errors. Spec, malli, schema use dynamic verification. They don't have/need access to the source code of your program, and use purely runtime information to verify your program conforms to your spec. Like instrumenting functions and asserting specs just-in-time as the program runs, or generating examples to exercise functions.

> What can you do with static typing that you can't do with the kind of thing that spec, Malli, and Schema are, and vice versa? It's a huge subject but there's really an entire spectrum between dynamic and static typing. there's not just two approaches. for example, many static type systems check as much as they can at compile-time and then emit runtime assertions to check the rest.

the way I see it is that they are complimentary approaches. sometimes you can prove something more convincingly with static typing, other times with dynamic testing or assertions. they both have their costs and benefits. dynamic is more probabilistic but more expressive. you often are constrained in what you can prove statically, but there's a bit more certainty (if you believe the type system is sound).

I think you're on the right track in terms of convergence. What I care about is verifying programs, and I want to use the right tool for the job. Ideally, the full spectrum of verification approaches are available for whenever they are needed.

Great, that cleared up a lot. Thanks for taking the time, Ambrose! 🙂

Isn't performance one of the big topics surrounding static vs. dynamic typing? With static typing (and AOT compilation), more of the performance cost is paid upfront at compile-time, and the compiler can use type information to do some clever low-level optimizations that would be incredibly difficult or maybe even impossible to do at runtime. With dynamic typing, the JIT compiler/VM/runtime is burdened with more work when doing schema validation, etc.

Yes, although a static type system doesn't guarantee better performance, only that you CAN get the benefits of polymorphism and pay the cost at compile time. There's still plenty of performance to be gained in other means but that's orthogonal