> Right; the difference is that by the destructing time you have lost the type information about that ‘discarded’ data, meaning you no longer know how to discard it. In Clojure this is not a problem, because the only values you're allowed to have are those that can be garbage collected
Yes, this is very true. Languages like Rust can certainly manage memory and data structures more precisely. Not only is Clojure garbage collected, by virtue of being based on the JVM and being dynamically typed, but in idiomatic usage it encourages data to be built from a small number of basic types.
> On this I absolutely agree. The only thing I'd be careful to distinguish is not simply that Rust doesn't have the machinery but that the machinery makes sense only given a fairly onerous set of additional assumptions about your values that Rust doesn't make
I guess only I'd disagree here that the additional assumptions are "fairly onerous" - but that's just an opinion. You may be doing work that butts into those assumptions far more often than I do (which is almost never).
> No, you're right: I think I was thrown off by your assertion that these are uncoupled from the type system when we were talking originally of ‘conceptual’ types.
I don't think I expressed myself very clearly, and indeed Clojure's type system isn't very clear either, since it's bolted onto the JVM and so can't entirely do its own thing. So we have "types" which refer to Java classes/interfaces, and "schema" or "specs" which refer to Clojure's own runtime validation ideas.
> I guess only I'd disagree here that the additional assumptions are "fairly onerous" - but that's just an opinion. You may be doing work that butts into those assumptions far more often than I do (which is almost never).
I originally meant this mostly in the sense that it forbids a lot of values. But I do also think this is a bit of a Blub situation. There's a good class of pure data algorithms where basically everything you want to interact with is data, and if you're working in that space it's pretty great. But having spent some time in resource-typed languages, for any situation where I have to work with external resources or effects that can't be undone working in a language that doesn't have resource types and deterministic constructors really feels like a big step backwards. There are so many invariants you can't capture if you can't reason about value invalidation.
It certainly could be a blub situation, as aside from some toy applications, I don't have much experience with Rust. Obviously in Clojure, like most languages, you can restrict a resource to a particular scope - but it sounds like you mean something more than that.
Yes, this is very true. Languages like Rust can certainly manage memory and data structures more precisely. Not only is Clojure garbage collected, by virtue of being based on the JVM and being dynamically typed, but in idiomatic usage it encourages data to be built from a small number of basic types.
> On this I absolutely agree. The only thing I'd be careful to distinguish is not simply that Rust doesn't have the machinery but that the machinery makes sense only given a fairly onerous set of additional assumptions about your values that Rust doesn't make
I guess only I'd disagree here that the additional assumptions are "fairly onerous" - but that's just an opinion. You may be doing work that butts into those assumptions far more often than I do (which is almost never).
> No, you're right: I think I was thrown off by your assertion that these are uncoupled from the type system when we were talking originally of ‘conceptual’ types.
I don't think I expressed myself very clearly, and indeed Clojure's type system isn't very clear either, since it's bolted onto the JVM and so can't entirely do its own thing. So we have "types" which refer to Java classes/interfaces, and "schema" or "specs" which refer to Clojure's own runtime validation ideas.