awused

9 ms·

31.
by awused 3y ago
Well, yes. I do think something that is guaranteed is better than something that is not guaranteed. You've at least somewhat accurately captured my position, though with the weird implicit assumption that "guaranteed by convention
32.
by awused 3y ago
>nope! wrong. do not pass go, etc. -- it's a spectrum You are simply incorrect, there's no nuance or room for interpretation. A compiler can guarantee "A or B, but not both or neither", "A or B or both, but never
33.
by awused 3y ago
>The thing is, the false dichotomy was painted before my time. I refuted it. No, it wasn't and you didn't. Result is one option among many in Rust which covers the common case with concise syntax, where (T, error) is the only o
34.
by awused 3y ago
>convention dictates either one or the other Convention is just an educated guess. >is it [convention] roughly the same as compiler-enforced rules? No. The answer is no. I'm not only free to say "no," but if I'm ho
35.
by awused 3y ago
>The discussion opened to say that Result is better than the pattern used in Go You are trying to paint a false dichotomy between Rust's Result<T, error> and Go's (T, error). In reality the dichotomy is between sum types
36.
by awused 3y ago
This entire discussion is about the type system and how it interacts with the language. Go does not have sum types, so the producer cannot signal to the consumer what it can produce and what the consumer has to handle. The consumer in Go mu
37.
by awused 3y ago
Result covers the very common case where there is T or error but never both. Having a decent type system doesn't prevent you from returning both. In Go I simply cannot have something as simple as "A or B, but never both or neither
38.
by awused 3y ago
This tries to sound profound but it really just misunderstands basic sum types. In Rust/Haskell/etc you're free to return multiple values if that's even potentially useful. If you have a function that can completely fail
39.
by awused 7y ago
In my example the sum of possible future allocations for ZFS is still only 10GB total. Each of the ten file systems, considered individually, does truthfully have 10GB available to it before any data is written. The difference is that with
40.
by awused 7y ago
That is not over-provisioning, it's just that 'df' doesn't have the concept of pooled storage. With pools it's possible for different file systems to share their "available" space. BTRFS also has its own p
41.
by awused 7y ago
Snapshots can't cause over-provisioning, not for file systems. If I mutate my data and keep snapshots forever, eventually my pool will run out of free space. But that's not a problem of over-provisioning, that's just running
42.
by awused 7y ago
I think ZFS - or at least the set of features ZFS provides - is relevant at any size or disk count all the way down to a single disk in a laptop. I've previously run ZFS on single block devices, though nowadays all my personal machines
43.
by awused 7y ago
>Isn't this a problem for any over provisioned storage pool ? ZFS doesn't over-provision anything by default. The only case I'm aware of where you can over-provision with ZFS is when you explicitly choose to thin provision