HN user

tbillington

518 karma
Posts14
Comments45
View on HN

Is threatening the computer program and typing in all caps standard practice..?

    - Honesty is a core value. If you lie, you'll be replaced.
    - BREAKING THE LETTER OR SPIRIT OF THE RULES IS FAILURE.
Wild to me there is no explicit configuration for this kind of thing after years of LLMs being around.
Rewriting Rust 2 years ago

vendor + linecount unfortunately doesn't represent an accurate number of what cargo-watch would actually use. It includes all platform specific code behind compile time toggles even though only one would be used at any particular time, and doesn't account for the code not included because the feature wasn't enabled. https://doc.rust-lang.org/cargo/reference/features.html

whether those factors impact how you view the result of linecount is subjective

also as one of the other commenters mentioned, cargo watch does more than just file watching

to qualify as a new Show HN there needs to be some major new development, not just a new feature

One could argue a major version qualifies. Apart from the genuine dupe 3 months ago all of these are separate stories.

dang's comment also specifically covers "show hn" posts which this is not. Some clarification from dang would be helpful though.

Super interesting proposal from David who is working on the wild linker. Sort of inverting the compilation process to drive codegen by what is actually needed, as opposed to compiling everything then throwing away what you don't need later.

The duplicate function checker tool is nifty too, 9% of my release build is duplicate functions. As mentioned in the article there are ways to bring this down if you can accept the trade offs.

https://github.com/davidlattimore/wild

https://github.com/davidlattimore/duplicate-function-checker

aside: find it funny (genuinely), you describe this as "pretty easy" xD. ffmpeg is so impressive but so daunting from a cli perspective to me. how do you even know whats possible! I would never have imagined it could generate palettes

Basing the recording off it's 24.6s runtime and 3.58MB download size it comes out about 145KB/s which is honestly really decent.

What format is it stored as (eg protobuf etc?) Is Rerun doing compression on the "raw" game data to achieve that?

Also had a good laugh at the cranky job in bacon.toml, might steal that :D

I also noticed the elements in the recording were all clickable, is that a Rerun feature, and did you have to manually reconstruct all the Bevy elements in a Rerun specific format?

Just curious how long this took you to make?

Super cool demo btw :) do you have more demos/PoC/examples listed somewhere I could peruse? Cheers

EDIT: Can your twitter post this so I can retweet :D

I _guarantee_ they knew about it.

They even posted on social media 1 week before launch warning people to expect lower than expected performance, and raised the system requirements.

If companies have to decide between prioritising features that they've advertised, show stopper bugs, and performance, guess which one always takes the back seat :)

Fundamentally, async/await and threads are different tools. Async/await is "in vogue" at the moment, but there are still real advantages in certain scenarios.

For example, the blog authors project is an OS running on minimal resources that would not be appropriate for any threading model I'm aware of.

  This is a wee operating system written to support the async style of programming in Rust on microcontrollers. It fits in about 2 kiB of Flash and uses about 20 bytes of RAM (before your tasks are added). In that space, you get a full async runtime with multiple tasks, support for complex concurrency via join and select, and a lot of convenient but simple APIs.
Rust actually used to have green threads before 1.0. You can read about the proposal and reasoning for it's removal here https://github.com/rust-lang/rfcs/blob/master/text/0230-remo....

If you'd like more info on the story around the adoption of async/await in rust you can see this excellent talk by Steve K. https://www.infoq.com/presentations/rust-2019/.