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.
This is a very important point, careful use of GCs for a special subset of allocations that say have tricky lifetimes for some reason and aren't performance critical could have a much smaller impact on overall application performance than people might otherwise expect.
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.
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.
It's also useful to look at the "rate of bugs per line of new code" because even stablished, long stable projects have code churn. Rare is the project that is unchancged, frozen in bakelite, and any mild refactor can introduce regressions or affect relied upon implicit invariants.
(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.
If I understand correctly, GATs are about being able to change compiler assumptions about data types in user code? Generics acting on the compiler?
How is that helpful? Is it that you're trying to skip all the language boilerplate around creating objects? Are there any risks/footguns to that approach?
Generic type-driven code makes my head hurt, let me know if I'm somewhat close
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.
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.
It's useful to have when you have complex graph structures. Or when implementing language runtimes. I've written a bit about these types of use cases in https://manishearth.github.io/blog/2021/04/05/a-tour-of-safe...
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.