I recently used a pretty well-tuned LLM to find ~500 safety bugs across the Rust ecosystem. Most of them are minor, and even major safety issues in Rust usually mean "it's possible to accidentally use this API in a way that is broken" not "this is directly exploitable", but I didn't want to just file LLM output as issues on these repos.
I very briefly considered doing something like this: if I just post the results on the internet, people can crowdsource filing issues and working on fixes. It's certainly not the nicest way of doing this, but on balance I'd like these issues to be fixed eventually.
I ended up not doing that and am instead filing a couple issues a day because it's not that much of a burden. This was an experiment that was much more successful than I expected, so I didn't budget to spend this time, but it's also not a huge deal to slowly do it.
Some "root" passwords are ones I do not put in my password manager out of "what if my pwd manager gets compromised" paranoia, but that makes me more vulnerable to this.
And annoyingly some websites like to forget you're logged in. Not Google as much, but it's a thing that happens enough that means that there's a chance that I would blindly enter a password if my guard was down. A slight chance I think (especially in the last year where i've been worried about more sophisticated scams) but a chance nonetheless.
.... we're talking about serialization here. "convert to a raw string" is sort of the name of the game.
It's a string in a well specified string format. That's typically what you want for serialization.
Temporal is typed; but its serialization helpers aren't, because there's no single way to talk about types across serialization. That's functionality a serialization library may choose to provide, but can't really be designed into the language.
Yeah, and it's even better if you have a GC where you can control when the collection phase happens.
E.g. in a game you can force collection to run between frames, potentially even picking which frames it runs on based on how much time you have. I don't know if that's a good strategy, but it's an example of the type of thing you can do.
Worth highlighting: library-level GC would not be convenient enough to use pervasively in Rust anyway. library-level GC does not replace Rust's "point".
And there's a huge benefit in being able to narrowly use a GC. GCs can be useful in gamedev, but it's a terrible tradeoff to need to use a GC'd language to get them, because then everything is GCd. library-level GC lets you GC the handful of things that need to be GCd, while the bulk of your program uses normal, efficient memory management.
Diplomat has a wasm backend so it would even be really easy to produce a WASM ffi target with idiomatic JS and TS bindings.
Also, Diplomat supports traits and callbacks so you could actually make the timezone impl pluggable. Though we don't currently have JS support for that.
They're also explicitly tracking new code by language, and talking about memory safety vulnerabilities per year, and they also link to [1] which talks about how most memory safety bugs they get are in new code.
GATs allow traits to abstract over associated types that are themselves to some degree abstract. In this case, it's necessary to do the relevant trait machinery around lifetime transformation since we need to be able to talk about "a replaceable lifetime of a type" in a generic way.
(the person who posted the article here isn't the author (me))
The bugs in part 1 all around using higher ranked trait bounds. I'd disagree with the characterization that they're "feature requests": five years ago, yes, I would agree, but this entire area of the compiler needs to be bug-free for an upcoming feature (GATs) anyway, and indeed, the issues I found were often fixed by people working on fixing related GAT bugs. Ultimately, my use of higher ranked trait bounds is an attempt to emulate some of what GATs get you in stable Rust, so it's not surprising that the bugs are in the same area of the code.
I think most of these companies have had a pretty large investment, they're just not really open about it in many cases. So yeah, it's a pretty visible signal, but the investments they had already were much larger ones. A team of core developers is a pretty small investment compared to having a ton of teams all over the place, which most of them had already.
Many of us are looking for (or have found) dayjobs, but it's possible some folks may be open to contracting work on servo/etc. But nobody is being paid to work on servo right now.
We spent a significant amount of effort in the last year and a half working on a redesigned modular/parallel layout subsystem.
The VR focus was because it was a good way to get servo out to end users early without needing to be fully web compat -- WebXR doesn't require complex layout. We didn't drop our focus on full web compat during this, but full web compat has always been a more long term goal given how complex the web platform is.
Servo was never tightly integrated with a sizeable browser project. It shared some components with Firefox, but the only time Servo itself was inside an actual browser release was Firefox Reality for AR. Which still exists, though I'm not sure what the future of development for it will look like.
So this is the core problem with all of the general relativity materials that model it as a rubber sheet causing curvature in spacetime. They always model it with focus on _spatial_ curvature: which is totally able to model an orbit or a hyperbolic trajectory as a geodesic, but it totally cannot model "throwing a ball up" since the geodesic for throwing a ball up is just a straight line.
The important thing is that gravitation is a distortion in space-_time_, which is way trickier to model as a rubber sheet because you end up with one dimension of space and one of time. If you distort _those_ (also, they don't distort quite like a ball-in-a-rubber-sheet), you can get the results of a ball being thrown up. It's also possible to visualize this for 2 spatial dimensions with a distorted 3d space, but tricky.
No, not quite, the signature will be `fn foo<'a>() -> &'a u8` (there is no way to elide this)
However, Rust lifetimes are stretchy-squeezy, and a free lifetime is basically the same as 'static when it comes to covariant lifetimes, since both are "I can be whatever you want me to be".
I very briefly considered doing something like this: if I just post the results on the internet, people can crowdsource filing issues and working on fixes. It's certainly not the nicest way of doing this, but on balance I'd like these issues to be fixed eventually.
I ended up not doing that and am instead filing a couple issues a day because it's not that much of a burden. This was an experiment that was much more successful than I expected, so I didn't budget to spend this time, but it's also not a huge deal to slowly do it.