you're free to have your own opinion based on your experiences here, but i wouldn't blame anyone for feeling that way. for the record, i don't think dang or anybody is a transphobe, but i have to imagine the culture here is pretty off-putting to trans people
i don't think it's that "wild". sure, i'm not so cynical as to feel hn's become a nazi bar or anything, but i am willing to recognize that some of the incidents i've witnessed could be reason enough for a trans person to want to avoid this site.
> It's neutral to this topic, it's about tech.
this thread began by xe bringing up failures in moderation affecting trans people
That isn't how it works. The presence of neutral allies doesn't somehow counterbalance and cancel out the transphobia. If a platform allows transphobic users - as Hacker News does because transphobia isn't against the guidelines - and transphobia is common in threads where trans issues or people are a subject (and it is) then it's a hostile platform to trans people.
Asking trans people to ignore this is like asking Jews to be comfortable in a bar where only ten percent of the patrons are Nazis. Arguing that "well not everyone is a Nazi" doesn't help, an attitude of "we're neutral about Nazis, we serve drinks to anyone" still makes it a Nazi bar, just implicitly rather than explicitly.
I'd agree with this logic if we were discussing all kinds of different topics here, and one's stance on gender would be immediately visible to anyone. But I can't remember the last time the matters of gender were discussed here at all, and pretty sure anything openly transphobic would be flagged or deleted pretty soon.
>I'd agree with this logic if we were discussing all kinds of different topics here, and one's stance on gender would be immediately visible to anyone.
We do discuss all kinds of different topics here. Despite what many people here want to believe, Hacker News isn't exclusively for tech and tech-related subjects.
>and pretty sure anything openly transphobic would be flagged or deleted pretty soon.
But not banned, that's the problem. The guidelines are extremely pedantic but nowhere is bigotry, racism, antisemitism or transphobia mentioned as being against those guidelines. You might say that shouldn't be necessary, but it's weird that so much effort is put into tone policing specific edge cases but the closest the guidelines come to defending marginalized groups is "Please don't use Hacker News for political or ideological battle. It tramples curiosity." Transphobia is treated as a mere faux pas on the same par as being too snarky, or tediously repetitive. The real transgression being not the bigotry but "trampling curiosity." Any trans person who posts here knows that bigots who hate them and want to do them harm aren't going to suffer meaningful consequences (especially if they just spin up a green account) and that the culture here isn't that concerned about their safety.
Read the green account just below me. That sort of thing happens all the time. Yes, the comment is [dead] but why should a trans person be comfortable here, or consider themselves welcome, knowing that this is the kind of thing they'll encounter?
I'm not in a position to tell marginalized people how they should feel, but a moderation policy that wouldn't even allow offensive messages by new accounts appear for a short time would make this place into another social media - walled off and tracking their users. I understand the point though.
This is a ludicrous example. Being in the physical presence of somebody who hates you and may want to kill you is quite different than being on a forum with them. Any person who may want to harm a transperson cannot jump through the cables and attack somebody.
> You cannot even use Nvidia/AMD/Intel DGPUs with AS Macs
afaik you technically can, except that m1/m2 force pcie bars to be mapped as device memory (forbids unaligned r/w), so most gpu software (and drivers) that just issue memcpys to vram and expect the fabric to behave sanely will sigbus. it's possible to work around this, and some people indeed have with amdgpu, but it'd absolutely destroy performance to fix in the general case
so it doesn't really have anything to do with apple themselves blocking it but rather a niche implementation detail of the AS platform that's essentially an erratum
don't see why they would care to put out docs on it considering macos doesn't even permit kexts anymore, there'd be no gpu drivers anyways. i figured it was obvious we're talking in the context of running linux on these things, given the parent topic.
> There's also an Apple VP saying unified memory on AS doesn't leave room for DGPUs and separate VRAM
can you link to this? my intuition is that they're speaking on whether apple would include dgpus inside AS systems like they used to with nvidia and amd chips in macbooks, which i agree wouldn't make much sense atp
There were uses for DGPUs in MacOS before AS, those uses could have continued, but Apple left no choice. It's weird how continuity wasn't as important to Apple in this case.
Whatever kernel or hardware facilities are available to Apple's own GPU driver, should be available to other GPU drivers. Anything else is myopic thinking, which I realize might be common for Apple, but it is also monopolistic.
Linux also allows userspace drivers with less performance I think, but I don't think DGPU use can be made performant because of AS hardware choices.
I am predisposed to ignoring link requests for things that can be easily googled.
> Runtime borrow checking: RefCell<T> and Rc<T>. Can give other examples, but admittedly they need `unsafe` blocks.
Where are the “subtle linguistic distinctions”? These types do two completely different things. And neither are even capable of being used in a multithreaded context due to `!Sync` (and `!Send` for Rc and refguards)
I did say "runtime borrow checking" ie using them together. Example: `Rc::new(RefCell::new(value));`. This will panic at runtime. Maybe I should have used the phrase "dynamic borrowing" ?
You don't need different threads. I said concurrency not multi-threading. Interleaving tasks within the same thread (in an event loop for example) can cause panics.
I understand what you meant (but note that allocating an Rc isn’t necessary; &RefCell would work just fine). I just didn’t see the “subtle linguistic distinctions” - and still don’t… maybe you could point them out for me?
imo if you're sprinkling around `unsafe` in your codebase "liberally", you're holding it wrong. In general it's really not that hard to encapsulate most unsafety into a wide-contract abstraction; I’d argue where Rust really shines is when you take advantage of the type system and static analyzer to automatically uphold invariants for you
Glancing at the Cargo.toml, the package doesn't define any features anyways. `cargo b --no-default-features` only applies to the packages you're building, not their dependencies -- that would lead to very unpredictable behavior
You've managed to miss the entire point of using a union: the value is either a success payload or an error value, never both.
You can't encode that mutual exclusivity if you return a std::pair or std::tuple. That's exactly why std::expected, std::variant, or Rust enums exist, to make that constraint explicit in the type system.
Yeah that makes sense. My assertion was definitely incorrect, but also not really what I was trying to describe. My argument is that they are not conceptually different. The implementation is different, in that a union occupies the same memory for either value, but whether they occupy the same memory or not, you have to check the value to determine that is an error. The compiler can force you to handle multiple return values the same way it can force you to check a variant.
> My argument is that they are not conceptually different.
Your argument is nonsensical on its face, it could not be a more different way to compose types.
> The implementation is different
It's also largely irrelevant, the commenter above makes no mention of the memory state, because that's not the point. The point is that the states are exclusive.
> The compiler can force you to handle multiple return values the same way it can force you to check a variant.
No it can not, specifically because it's a product type (or it would be if it were a type anyway), and there is no relation between the fields. At most you can apply some mangy heuristics and hope they don't fuck up to often.
A sum type tells you in no uncertain terms that you can have only one of the types at any given time.
And that's not accounting for the fact that a result is a reified value, which an MRV is not, so it can be passed around and manipulated as any value, and can be operated on as a thing of its own.
I don't know that there's whining about "having to handle errors" in principle, it's pretty clearly a complaint with the syntax and semantics of doing so
Some languages even make omitting error handling impossible! (e.g. Result sum types). None have anywhere near the amount of "whining" Go seems to attract
Codex-like agents are cool but as someone with even just a passing interest in compilers I absolutely hate this attempt at appropriating the word "codegen"
