kbknapp

Initially I was like, "Oh cool, a new layer on top of Nix to make it more accessible!" And then read on to see it's basically just the NixCpp fork from save-nix-together now with Meson. I guess gradually moving to Rust is a cool idea, but there also exists tvix in that space with a greenfield version in Rust.

GPS satellites don't "send" your coordinates to your receiver. Your receiver is just listening to the broadcast signal from several (usually 4+) satellites and based on the strength of that signal determining how far it is from each of those satellites. Which means the receiver is able to triangulate it's own position.

In fact, I believe that's exactly where this bug lies. You're effectively able to trigger a case in which passing `&'a &'b` without providing any correlation (`where 'a: 'b`) that one would normally be required to provide makes the compiler behave as if those correlations were passed, albeit inferred incorrectly.

Rust can re-use an allocation, but if the new item is smaller than the previous it doesn't automatically remove (free) the "wasted" memory left over from the previous allocation. I think this is categorically not a memory leak as the memory was absolutely accounted for and able to be freed (as evidenced by the `shrink_to_fit()`), but I can see how the author was initially confused by this optimization.

The 2x versus 200x confusion IMO is the OP was conflating that Vec will double in size when it needs more space, so they were assuming the memory should have only ever been 2x in the worst case of the new size. Which in the OPs case because the new type size was smaller than the previous, it seemed like a massive over-allocation.

Imagine you had a `Vec<Vec<u16>>` and to keep it simple it there were only 2 elements in both the inner and outer Vec's, which if we assume Rust doubled each Vec's allocation that'd be 4x4 "slots" of 2 bytes per slot (or 32 bytes total allocated...in reality it'd be a little different but to keep it simple let's just assume).

Now imagine you replace that allocation with a `Vec<Vec<u8>>` which even with the same doubling of the allocation size would be a maximum of 4x4 slots of 1 byte per slot (16 bytes total allocation required). Well we already have a 32 byte allocation and we only need 16, so Rust just re-uses it, and now it looks like we have 16 bytes of "waste."

Now the author was expecting at most 16 bytes (remember, 2x the new size) but was seeing 32 bytes because Rust just re-used the allocation and didn't free the "extra" 16 bytes. Further, when they ran `Vec::shrink_to_fit()` it shrunk down to only used space, which in our example would be a total of 4 bytes (2x2 of 1 byte slots actually used).

Meaning the author was comparing an observed 32 byte allocation, to an expectation of at most 16 bytes, and a properly sized allocation of 4 bytes. Factored out to their real world data I can see how they'd see numbers greater than "at most 2x."

TBF, when a 1.0 is released doesn't mean it's viable right way for things like this. It takes a certain level of market adoption and ecosystem buy-in first.

Also, Zig still isn't 1.0 so if we're measuring languages from when they first became public, I believe those others in your list are much older as well.

I'm not a fan of trying to put hard numbers on unknowns like this because it biases against uncertainty, but if they shaved ~74 minutes off their CI time and assuming it runs multiple times a day that very quick equates to a small teams cost savings over a year.

However, I think trying to find the actual numbers is dumb because there's also the intangibles such as marketing and brand recognition bump by doing this both for the company and individuals involved.

That's not to say all greenfield endeavors should be actioned, but ones with substantial gains like this seem fine given the company is big enough to absorb the initial up front cost of development.

I've had significantly fewer issues with `cargo [b]install`ed compiled Rust programs than `npm install`ed ones. Getting nodejs/npm installed (and at an appropriate version) is not always trivial, especially when programs require different versions.

OOTH, Precompiled Rust binaries have the libc version issue only if you're distributing binaries to unknown/all distribtuions, but that's pretty trivially solved by just compiling using an old glibc (or MUSL). Whereas `cargo install' (and targetting specific distributions) does the actual compiling and uses the current glibc so it's not an issue.

Really cool idea but this gives me anxiety just thinking about how it has to be maintained. Taking into account versions, command flags changing output, etc. all seems like a nightmare to maintain to the point where I'm assuming actual usage of this will work great for a few cases but quickly lose it's novelty beyond basic cases. Not to mention using `--<CMD>` for the tool seems like a poor choice as your help/manpage will end up being thousands of lines long because each new parser will require a new flag.

Many (most?) disagree with this line of thinking, but I believe the "Rust will never have a 2.0" style thought is what ultimately leads these multi-year pursuits of perfect (or at least good enough to last "essentially forever"). The Editions provider a certain release valve for some styles of breaking changes, but I don't believe it's quite enough ultimately over the entire lifespan of a language which will undoubtedly grow cruft that even Editions cannot remove.

Seems the author is expecting OAI to continue merrily along its way working towards AGI (albeit at a stated slower pace) while MSFT is able to take Altman et al and circle the wagons on what already exists (GPT4) squeezing it for all its worth. While that's entirely possible, there are other outcomes not nearly as positive that would put MSFT at a disadvantage. It's like saying MSFT's AI hedge is built on what appears like sand; maybe it's stable, maybe it's not.