Would you use orogene if it wasn't foss? Just a binary blob off a private repo?

I expect it to be the fastest, safest, and most usable JS package manager out there once I'm done with it.

#orogene

I... guess I have workspaces in orogene now?

#orogene

so this is happening.

All my #Rust #RustLang repos are moved over. Now I just need to figure out CI, republish to crates.io, and archive the github side (and document a tombstone in their readmes).

I have a bunch of other repos I'll either archive or delete as well.

#KDL and #orogene will remain github-side for now because they're a bit more dependent on github services, but I would like to at least move orogene over eventually. KDL might be stuck, though, unfortunately, but I might move only kdl-rs.

#bevy #miette

I was having nice warm fuzzy feelings because even though #orogene itself is kind of on pause (for now), it’s actually spawned multiple widely-used projects:

I think that’s it so far? And of course I’ve had the opportunity to share a lot of learning about performance that have been used by more recent package managers in other ecosystems!

very excited to see a feature I worked on finally see the light of day.

This feature is backed by a wasm version of #orogene!

It's extremely cool to just be able to load arbitrary package code like this, without needing a vm/filesystem. And it's so fast! Please go try it out!

back to poking at adding type acquisition support to vscode.dev and finally fixed some issues that were making it slow. Tested with a huge package.json, yeah, it took a while. Tested on orogene desktop, took about the same amount of time. ok.

npm? 3x the amount of time (9 minutes!!), even though orogene web can only open two fetch requests at a time and has to serialize stuff between the Rust and JS layers.

lol. lmao. And orogene desktop was only a few seconds faster!

I should jump back on #orogene dev some time. This thing is still pretty solid.

my 2c on opt-in vs opt-out:

both are bad in the case of things like telemetry.

If you're going to do something that the user might want to make an important decision about (such as their privacy), you should of course have them opt-in, but opt-in with default-to-no means that something important might not happen, and enablement of that feature will be too low to make it useful. But of course, if you just enable them and yolo, then you're.... well, you're probably violating some laws, tbh, so I'll leave it at that.

I want to have a special term for making opting decisions that doesn't imply defaults, such as "active opt-in" or something, where the application requires that you make a decision either way, during setup, if it's going to do things like telemetry.

Because, in all seriousness, telemetry is useful, and when privacy is respected, it genuinely helps makes products better, but opt-out is gross af, and opt-in won't get you the data you need.

This is what I decided to do with #orogene, btw. It sends anonymized crash reports, but you're prompted the first time you launch orogene and both options are presented equally and you can't just skip this (well, you technically can if you're in a non-interactive environment, where we'll default to no telemetry)