Hacker News Reader

Comment by camgunz | Hacker News Reader

Reading through the source of Elle:

> "I cannot begin to convey the confluence of despair and laughter which I encountered over the course of three hours attempting to debug this issue. We assert that all keys have the same type, and that at most one integer type exists. If you put a mix of, say, Ints and Longs into this checker, you WILL question your fundamental beliefs about computers" [1].

I feel like Jepsen/Elle is a great argument for Clojure, reading the source is actually kind of fun. Not what you'd expect for a project like this.

[1]: https://github.com/jepsen-io/elle/blob/master/src/elle/txn.c...

View on HN

Wonder if this "manual type constraints"-style code is pre-"spec"

Elle is pretty new so I would guess not--unless it's been lurking somewhere else. Dunno what aphyr's thoughts on spec are, plus I'm an amateur clojurian so, I'm not sure what community consensus is or if spec has drawbacks that make it not a good fit.

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.

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?

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.

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.

Reply on news.ycombinator.com