• 0 Posts
  • 1.56K Comments
Joined 3 years ago
cake
Cake day: June 21st, 2023

help-circle
  • This does seem like an issue with the library you’re using. Your second solution, using RawValue, is likely what I would have gone with, bundled with a self-referential type (wrapping the Pin in another nicer-looking type though). This is assuming I want to pass around a 'static type with the partially-deserialized data. In fact, I’ve done something like this in the past to pass around raw log data next to that same data in a parsed format (where the parsed data borrows from the raw logs).

    Alternatively, I’d have deferred the lifetime problem to someone else (library user for example) since the source data is probably provided at a higher level. This is how the libraries you’re using do it from what I can tell. They make the LT the user’s problem since the user will know what they want to do with the data.


  • MN Statutes §609.765:

    Defamatory matter is anything which exposes a person or a group, class or association to hatred, contempt, ridicule, degradation or disgrace in society, or injury to business or occupation.

    Whoever with knowledge of its false and defamatory character orally, in writing or by any other means, communicates any false and defamatory matter to a third person without the consent of the person defamed is guilty of criminal defamation and may be sentenced to imprisonment for not more than 364 days or to payment of a fine of not more than $3,000, or both.

    Exceptions are listed below that, but we know the statements are not true, clearly are not made in good faith, the communications are public, and they were not made with the intent to further any interest or duty shared between the parties who are communicating (I share no interests with these so-called “reporters” for example).

    So, uh, why do these cases never get taken?


  • If I had chosen to write this code in Go I never would have had to think about any of this and I expect it would have been fine.

    Well the article is about zero-copy deserialization in Rust. If you just slap #[derive(Deserialize)] on a bunch of 'static types and let it copy the strings, then you don’t have this issue in Rust either.

    Also, you’d be using Go, not Rust. That’s fine, but not really relevant when you want to do JSON deserialization in Rust, is it?

    What a wild conclusion to come to.


  • Do you want to? Go for it.

    Does your game crawl? Have you identified this code as the bottleneck? Are you certain that asm will give you a meaningful performance increase, and that your issue doesn’t lie with your approach to the problem? Sure, I guess. You said your game runs fine though, so this probably doesn’t apply.

    Is your game fast already? If you don’t want to do it, don’t.

    Writing asm by hand is almost always a waste of time. There are only a few times where it’s actually necessary, and unless you’re writing a bootloader and running your game on bare metal, I can’t imagine why it’d be necessary. But you know your code better than anyone else here, so you should know whether it’s needed or not more than any of us do.

    To begin with, you’re apparently targeting the Z80, which I haven’t seen used for games in the wild… probably in my entire life? Maybe an arcade machine I played on once used it, but I can’t think of any other times. If your targets need custom assembly, then you should already know that. We don’t know your targets.





  • to be specific, when you refer to “that all” happening, you mean Biden signing the bill that banned TikTok in April 2024, I think?

    Yes. Biden happened to be president, but any president would have signed that into law because of the support, and even if it hadn’t become law, we’d still be in this position. Trump wants to control the media. He’ll do it however he needs to.

    your timeline is jumping around a bit here, because now you’re referring to “that period” and linking to a source from January 2025, the time of Trump’s inauguration.

    The period in question went on for quite a while (a yearish if I remember correctly). Anyway, your comment doesn’t actually say anything to contradict my point of ByteDance spreading their cheeks for Trump.

    this ban only passed because Democrats were bamboozled into supporting a proposal that has its roots in Republican “omg China scary” bullshit. I don’t know how to explain it any more clearly.

    You don’t need to. The ban is irrelevant. Without the ban, we’d be in the same place, with Trump attacking all forms of media to gain control.

    ahh yes, “criticizing Democrats is the same thing as supporting Republicans”, the free square on the bingo board.

    You’re not criticizing lawmakers here. You’re criticizing the common person, the people actually affected by the purchase. What you’re doing is essentially victim blaming.

    Your entire analogy is irrelevant. The people you’re criticizing are the people who reviewed the exterminator, not the exterminator.


  • The ban had bipartisan support, and even if that all never happened, you’d still be in the same situation. They would have sold off their US business anyway whether they were forced to or just got a big offer.

    Keep in mind that TikTok also put out messages during that period practically deep throating Trump and sent it out to all their users. This was going to happen either way.

    Ironically, a ban could have prevented this from happening entirely by making TikTok no longer relevant to the US. Not that banning it wouldn’t come with other issues as well, of course.

    Maybe rather than blaming those in search of a solution, you could try blaming those who created the problem. Friendly fire doesn’t do a whole lot of good, but does support Trump, which I’m assuming isn’t your goal here.


  • Breaking down what async fn in trait does, it converts it to a fn method() -> impl Future<Output=T>, which breaks further down into fn method() -> Self::__MethodRet where the generated associated type implements Future.

    This doesn’t work for dyn Trait because of the associated type (and the fact method() needs a dyn-safe self parameter).

    Instead, your methods need to return dyn Future in some capacity since that return type doesn’t rely on associated types. That’s where async_trait comes in. Box<dyn Future<...>> is a dyn-safe boxed future, then it’s pinned because async usually generates a self-referential type, and you need to pin it anyway to .poll() the resulting future.

    Edit: also, being pedantic, associated types are fine in dyn traits, but you need to specify the type for it (like dyn Blah<Foo=i32>. Even if you could name the return type from an async fn, it’d be different for every impl block, so that’s not realistic here.






  • This depends on how the verification is done, in my opinion, as well as whether there is a presence of more anonymous alternatives.

    If the EU has a system which does not rely on third parties for verification and allows the platform to verify directly with a government-run service, then the only real issue there is lack of anonymity, which isn’t necessarily a bad thing on a platform if there are also popular anonymous alternatives people can use when they want to.

    The article doesn’t go into how ID verification will work though. If it’s through third parties like how the US does it, then that’s disgusting and waiting to be breached.






  • While I agree with your post, I do want to call out that Rust’s standard library does use a lot of unstable features and calls compiler intrinsics. Anyone can use the unstable features I believe with just #![feature(...)], but not the intrinsics (not that there’s much reason to call the intrinsics directly anyway).