And also it's been confined to Switzerland for at least a couple years now; committing US federal crimes isn't a new circumstance for it.

In any case, it's still UB under the language guidelines, it's just not exploited yet.

I'm on a campus with these robots and over winter break, with the first big snow, a friend of mine was bored and apparently spent parts of his days just going around and helping the Starships that got caught in the snow.

Hey I'm also on venlafaxine! It's worked very well for me as well, though I don't think I can really speak to the topic of the OP since I started taking it when I was relatively young. I haven't noticed.. much? I guess?

Not sure if they edited the comment after you commented, but that is a bitfield now, at least

You're right, I didn't see the :1's. Maybe it was edited, maybe I was just blind?

Oh, it's updated in the article now.

Might be biased/stereotypical, but Rust's cargo does dependencies really well. It's as easy as npm to add new dependencies, but there aren't thousands needed to do anything, and if you take a look at your Cargo.lock/`cargo tree` you can really get to know each of them and what they do or why they're pulled in. I'm still bloat-wary, maybe as a leftover from doing webdev, but with less transitive dependencies in the first place you can actually go through and prune things that aren't needed, or open PRs to transitive deps to prune from their trees or update deps to the latest version to deduplicate your tree. (If there are multiple semver-incompatible versions in a dep tree, they just both get compiled in - for most apps though, you should be able to get the number of duplicates to 0 or almost that.)

I wonder how Cargo will be regarded as in 2-5 years if it gets anywhere near the number of projects/libraries that say Python or Javascript has.

You can either go to lunch or buy a Threadripper server to be able to compile a full project from scratch, everytime you want to check something.

Unless by then cargo has already learned how to deal with binary crates.

If compile time is the problem, Rust is not (yet?) the solution.

I agree that Cargo is much better than the Go build system, though.

Having tried both, focusing on source dependencies is the only way to make sure that dependency sources are universally available and buildable, which makes a huge difference in the long run. Just look at NuGet's issues getting SourceLink adopted.

Binary caching á la Nix can work, but I can't really see that working out without Nix's commitment to environment purity.

When one is lucky to use server hardware as workstation, and works in domains that don't depend on selling binary libraries for their business.

IIRC it involves qemu on aarch64

Gotcha. That still runs counter to the comment:

> I do not wish to install Python or Java on every computer. I have small form factor computers where I need to conserve space.

Now you have to install QEMU on every computer, in which case your options for portability dramatically increase.

You can always build headless blinkenlights https://justine.lol/blinkenlights/index.html (part of the cosmo codebase) for aarch64 or whatever and use that to simulate ape binaries. If you make -j12 MODE=tiny o/tiny/tool/build/tinyemu.com it's 191kb and that simulates the whole x86_64 ring 3 architecture up to ssse3, plus enough of ring 0 currently for the cosmo codebase to have metal unit tests. The APE blog post talks about the possibility of embedding something like that inside these x86 binaries. So if you feel really strongly about non-x86 as many of the people in this thread do, then 90% of the work has been done for you. I haven't taken it 100% of the way there since I personally don't need non-x86 support.

I think given these lines in the article (and the fact that she mentions OpenRC):

> I have been an Alpine user for almost a decade and it's one of my favorite linux distributions.

> This talk is intended to show how green the grass is on the other side and how Alpine can benefit from these basic ideas.

She's probably familiar with it.

Yep, one of the main things I did with nim for the month or 2 I was really into it was write a duktape wrapper[0] (in retrospect, I should have made the name a pun related to wrapping with tape...). It was pretty interesting given the stack-based nature of almost every duktape operation.

[0]: https://github.com/coolreader18/duk