@danderson My biggest quarrel with most DSLs is that they're not designed with any consistent principles in mind, but merely slap a soggy poultice over whatever lexical grievance the author had with whatever they were using previously.
If you're gonna make new life, at least take it seriously, I say.
Just one more wrapper around runc, i promise just one more wrapper and then cloud-native is done, come on bro just one more coordination layer i swear just one more api come on bro just one more
@danderson I wish that, as an industry, we'd stop rewarding people for "solving" the difficulties of one complicated system by wrapping it in a new complicated system that is trying REALLY HARD to look different from the old complicated system (as it painstakingly reproduces the same complications with different warts).
Ideally our systems wouldn't be so complicated in the first place, ha, but I'd settle for harm reduction at this point.
@danderson Yeah. Though arguably we didn't even really do that, because with a few exceptions, none of the container ecosystem tools do ANYTHING independent of a huge hairball of related nonsense in harness. So it's more of an artist's impression of the philosophy than a real implementation of it.
@danderson You can tell a lot about how much it will hurt to use a project from the degree of excitement its maintainers have about everything being pluggable.
They say: "you can do anything!"
I hear: "I have to do everything"
Good design choices are hard. But not making them never helps.
@matt@danderson Yeah, though much of it is not worth the effort. It's a weird mix of a small handful of genuinely useful improvements with a large helping of wallowing.
@danderson Yep, some of it IS actually nice. (Though IMO the matching is one of the jankier and more abrasive changes, despite that I like the feature generally)
https://without.boats/blog/let-futures-be-futures/ is a very good read. From outside rust, the only take on async that went viral enough that I read it was "what color is your function?" Although it was about the javascript world, I was exposed to it as a takedown of async/await in rust.
This post goes quite deep into another framing: if we accept that there is a "color" tradeoff, how is it justified, what do we get out of it? Quite a lot of things, I've learned. Still a significant tradeoff, but I get it now.
@danderson I mean, simplified a bit that is more or less always the case, the question is always what facilities you let yourself have for controlling it. The options are "none" (or perhaps "explicitly drop into asm / setjmp / longjmp / hand write CPS"), some kind of library bolted to the compiler (async/await, other state machine nonsense), or explicit continuations of some kind. All require some runtime to actually get control of the machine, but that is unavoidable anyway.
I have two fns set_deep_val1 and set_deep_val2. The first works fine, the second angers the borrow checker. By my current understanding of borrows, either both should work or both should fail. What am I missing?
dangit, my inner data structure has a structural fault because of rust ownership semantics.
Conceptually, the inner struct is a binary tree where inner nodes can carry a value, and leaves can carry a value or a child tree. If you need a leaf to hold both a child and a value, you store the child and move the value to the child's root node.
Conceptually again, lookups walk down this tree-of-trees looking for the node representing the lookup key, and nearest self-or-parent value is the result.
@danderson@irenes The morally defensible case for an unsafe treatment is when you have knowledge that cannot be expressed to the compiler, but which you've already ensured some other way (e.g., by constraining the input higher up in the call tree). It's still unsatisfying, of course. And I always worry about the next joker who tries to cross the street because they saw me do it. 💀
@danderson@irenes Yeah. And Rust lets you express to the compiler many things you'd otherwise have to shoulder the burden for yourself. As you say, there's value in seeing how far you can push it, especially at the beginnings of things.
Hmm, I wrote out a neat little iterator for the next step of this algorithm, which outputs a sequence of "go into child table" followed by a final "insert in this table" (enum with 2 vals).
But that breaks the borrow checker when used, because the final insert case moves a value, and rust reasonably goes "you can't do that because what if another loop iteration gets here?"
I don't think I can express the promise that it won't happen without unsafe... Is there some std wrapper type for this?