4 ms·

Normally I'm a core.typed person, but static type constraints don't quite make sense here. We want heterogeneity in some cases (e.g. you want to be able to mix

by aphyr 6y ago

Normally I'm a core.typed person, but static type constraints don't quite make sense here. We want heterogeneity in some cases (e.g. you want to be able to mix nils and ints), but not in others (e.g. this short and int mixing, which could be intentional, but also, might not be) I've considered spec as well, but spec has a weird insistence that a keyword has exactly one meaning in a given namespace, which is emphatically not the case in pretty much any code I've tried to verify. Also its errors are... not exactly helpful.

lemming 6y ago
This is interesting to me as a Clojure person - you would be approximately the first person I've seen using core.typed since CircleCI's post in 2015 discussing why it didn't work for them. Are you using more modern versions of core.typed? What's the experience like these days?
- aphyr 6y ago
  I don't use it often. In general, I've found the number of bugs I catch with core.typed doesn't justify the time investment in convincing things to typecheck--my tests generally (not always, of course!) find type issues first. I also tend to do a lot of weird performance-oriented stateful stuff with java interop, which brings me into untyped corners of the library. That said, I've found core.typed helpful in managing complex state transformations, especially in namespaces which have, say, five or six similar representations of the same logical thing. What do you do when a "node" is a hostname, a logical identifier in Jepsen, an identifier in the database itself, a UID, and a UID+signature pair? Managing those names can be tricky, and having a type system really helps.
  - lemming 6y ago
    Interesting, thanks for the feedback. I often miss having a type system in Clojure and I was really hoping that core.typed might be more ergonomic these days. It sounds like it's still a pretty serious tradeoff, and probably not worth it for most code.

by aphyr 6y ago

lemming 6y ago

This is interesting to me as a Clojure person - you would be approximately the first person I've seen using core.typed since CircleCI's post in 2015 discussing why it didn't work for them. Are you using more modern versions of core.typed? What's the experience like these days?

aphyr 6y ago
I don't use it often. In general, I've found the number of bugs I catch with core.typed doesn't justify the time investment in convincing things to typecheck--my tests generally (not always, of course!) find type issues first. I also tend to do a lot of weird performance-oriented stateful stuff with java interop, which brings me into untyped corners of the library. That said, I've found core.typed helpful in managing complex state transformations, especially in namespaces which have, say, five or six similar representations of the same logical thing. What do you do when a "node" is a hostname, a logical identifier in Jepsen, an identifier in the database itself, a UID, and a UID+signature pair? Managing those names can be tricky, and having a type system really helps.
- lemming 6y ago
  Interesting, thanks for the feedback. I often miss having a type system in Clojure and I was really hoping that core.typed might be more ergonomic these days. It sounds like it's still a pretty serious tradeoff, and probably not worth it for most code.