manishearth.bsky.social
unmappable territory
please leave a message after the beep
552 posts
2,019 followers
167 following
Regular Contributor
Active Commenter
comment in response to
post
(probably not actually so, it's not uncommon for them to work together)
comment in response to
post
this is probably organizationally tricky because legal and PR tend to *both* be orgs that are rather used to being listened to without question
comment in response to
post
I have this canvas triptych behind my computer
www.etsy.com/listing/1452...
the seller appears to have a lot of of different things including some brushy landscapes
i imagine a lot of this art is contracted out, though, it's not a single artist (and they might have switched to AI in recent yrs)
comment in response to
post
oh no! number also go down! who could have predicted this
comment in response to
post
oh dear
comment in response to
post
but number go up
comment in response to
post
yeah, basically, and that requires care in figuring out what the intent is
comment in response to
post
I believe so, yes
comment in response to
post
currently the only tools with an explicit stability policy are clippy and rustc, even cargo doesn't have one, though with cargo there's definitely a generally agreed-upon but unwritten notion of what is and isn't okay at least amongst team members
comment in response to
post
*and I'm saying* that "don't break CI" does not make a useful stability policy that I think Rust can meaningfully evolve with. You can have a more nuanced thing around what types of CI breakage are okay, but again, you have to spend time coming up with it
comment in response to
post
Sure, that's my point! Nowhere here am I attempting to argue that the rustup change *here* was handled correctly. But I am saying that stability policies are really nuanced and you actually have to spend time coming up with one, not just handwave "we are stable".
comment in response to
post
I mean, yes, I'm not disagreeing with you, I'm just saying that stability policies are nuanced and hard to come up with.
rustup is not rustc, the answer for rustc is not going to be the answer for rustup, the rustup team has homework to do to figure it out
comment in response to
post
I think care can and should be taken to make this path smoother, but I do think it is harmful to view all CI breakage as real breakage, and I do not think this is how the Rust project (implicitly) operates right now
(if the Rust project *thinks* it operates that way, I think it is misinformed)
comment in response to
post
I have in the past had people adamantly claiming that a behavior change on a Unicode repo I maintained (to bring it more in line with the spec!) was a breaking change because their CI broke, and I held the line that no, it wasn't, their CI caught their bad assumptions and *did its job*
comment in response to
post
for example, I may soon write a bit of CI that ensures that some of our APIs do not pull in any panic machinery. This is fiddly and can depend on the optimizer. That's fine, if the CI breaks on a rust upgrade, it's on me to investigate how to keep our APIs panic-free, the CI did its job!!
comment in response to
post
quite often the answer to a CI breakage is "great, your CI caught a problem, *as is its job*, and the onus is on your side to fix for it". I think that is 100% valid, and views otherwise tend to be super absolutist
comment in response to
post
eh, hyrum's law means that all things can be depended upon by CI, and even anticipatable at times.
One could anticipate all kinds of CI breakage on all kinds of rustc PRs and halt development if that were actually the policy
It's a per case tradeoff, IMO.
comment in response to
post
once you accept that, then it becomes a matter of degrees. the right answer is different for different bits of software, e.g. clippy has a far more lax stability policy than rustc, because it is fundamentally a developer tool
comment in response to
post
basically, if you plan to evolve your software in observable ways, you do have to decide *some* things that may "break" users are actually not breaking changes, because ultimately all observable behavior can potentially be depended upon (hyrum's law!)
comment in response to
post
so does Rust, even: Rust had the same problem with Iterator::intersperse
comment in response to
post
does that example seem contrived? well, JS went through a whole thing where `Array.prototype.flatten()` (now called `flat()`) might have been named `smoosh()` because of this problem!
JS's notion of stability does not encompass this by default, but in some cases they take care with it
comment in response to
post
this is a good sign for rustup to figure out what it does and doesn't consider stable
("everything" isn't acceptable, full 100% stability effectively means never adding features, nothing has full 100% stability)
comment in response to
post
generally, rustc has a pretty clear stability policy. cargo does too, informally, though it's a bit more lax in some ways (specifically, things like changing the resolver are in scope)
rustup has historically not changed enough to need one
comment in response to
post
I don't like that things like -Zunpretty and -Ztime-passes are unstable because someone "might rely on them in CI" or something :/
comment in response to
post
generally "this will break CI but not end users" should be acceptable IMO, with steps taken to reduce the size of the impact (that's the part that failed here)
comment in response to
post
it does, to some extent, it depends on the tool and the aspect of the tool
this also has negative effects: a bunch of debugging-only rustc flags are basically permaunstable and only available on nightly, which is silly (especially if you need to debug stable)
comment in response to
post
Free, universal access to generation ships pointed at the opposite side of the galaxy
comment in response to
post
the whole point of the un was to be less of a silly party than the league of nations but clearly it's not going far enough
comment in response to
post
I think they aren't visible from the side angle too
comment in response to
post
OH
I was looking at the windows and then at the sky
oops
comment in response to
post
as much as I hate the whole "journos were mean to techies and that's why tech shifted rightwards" bit .... yeah it's absolutely true that journalism reported on tech as if it had some form of original sin and thus things were self evident and could go unexamined
comment in response to
post
... don't give Newsom any ideas
comment in response to
post
the Bowl giveth, and the Bowl taketh away
comment in response to
post
yeah basically. my gut feeling is that there's something possible here, it's not Idris, but Idris has moved the needle and a language learning from Idris may succeed
thanks for the link! that does seem pretty cool!
comment in response to
post
not really, but I also haven't really explored. Idris seems to want to try at least. Haven't looked too much at elixir
comment in response to
post
you basically should never be seeing explicit viramas in Devanagari, it's a "I don't know how to draw this" fallback, and a font fallback
duo handles these correctly in some positions but not all
comment in response to
post
gender identity is not presentation, however I do not think this is a deliberate choice by duolingo to be Progressive About Gender, and this actively hinders understanding why the fuck each verb has two forms and how to pick them
(there are better ways to do this if you really want to)
comment in response to
post
things i think such a language may focus on:
- usable dependent types
- hybrid compilation model that gives you the benefits of typed and untyped languages both
- different takes on async
comment in response to
post
I mean I'm in favor of building broad tents. I also just think it's totally understandable (if unfortunate) for people to go "no I won't fuck with that", and I'm not going to criticize them for their choice.