royjacobs

Typically ThreadLocals are used whenever something is costly to initialize per-request. The rule of thumb is usually: you might want to use some heavy object without locking, so you stick into a ThreadLocal.

However, if suddenly you have a million threads then this optimization doesn't work anymore. Sure, the concept of ThreadLocal still works, but in practice you'll end up creating a million of these heavy objects - something you wanted to avoid!

I can definitely recommend Guy Delisle's books. He has books on Pyongyang, Shenzhen, Burma and Jerusalem and they're all excellent.

I hope so, too! I like asdf as a concept but it's just way too slow for daily use.

Whenever I see news about libreboot the first thing that happens in my brain is that I somehow associate it with a library that handles rebooting. Takes a few seconds every time to, well, reboot my thoughts.

This reminds me of very early pixel shaders, which could only consist of about 6 assembly instructions.

Agreed. I don't think the PC demoscene at that time even had 6000 sceners that were well-known enough for Gravis to send them sound cards.

You'd still need the same kind of interop layer. The question then becomes if there are more or fewer classes and methods you'd need to wrap on the Rust side.

A little bit of everything, but the WebGPU stuff requires a full interop layer to translate WebGPU calls on the Rust side into calls on the JS side (a poor man's wasm-bindgen basically).

Additionally, there's just a lot of code being generated for common containers. It would probably be simpler and smaller to create unsafe containers that just shift pointers to boxed structs around or something, but I haven't gotten around to that yet.

I'm actually in the process of writing a demoscene 64k in Rust+WASM, that will be contained in a single index.html.

Actually not sure if I'll get around to finishing it, but currently a WebGPU-based renderer + scene graph + softsynth fits in about 30k compressed. That's unfortunately a bit big, but we'll see.

If I don't get around to finishing it I'll probably open source the code anyway, just as a fun starting point for others maybe.

BeRo is a demoscener who's still writing a ton of stuff in Pascal, IIRC. [0]

[0] https://www.rosseaux.net/

What kind of stuff do you want to do on a 6502 that requires emulated floating point support?

This pattern has been used for GUI toolkits as well. I specifically recall seeing it in the Caliburn.Micro framework for C#. It takes a bit of getting used to but it's pretty neat.

A quick Google found that this tutorial shows the technique off a bit: https://www.atmosera.com/blog/jounce-part-15-asynchronous-se...

My biggest pain point with Rust (in a startup context) is that Rust works really well, until you get to anything related to threading or async.

Yes, the claim is "fearless concurrency" but you'll still deadlocking mutexes and once you're heavily into async you need to start using language constructs that feel REALLY awkward, like pinning, runtime checks like RefCell, and so on.

IMO if Rust could make that whole aspect of the language more elegant, it'd be much easier to scale up to a larger org.

That's a pretty reductive (and needlessly negative) characterisation of a YouTuber who does a great job of finding pretty random science tidbits all around the globe and making short, to-the-point videos about them.

The same author has another book from around the same time called "Gardens of Imagination" which explains how to write a Wolfenstein 3d-style raycaster. I can highly recommend that book as well.

This is pretty cool! It's surprising to see the project be at version 0.2.5 when the first commit was _yesterday_ though. What's the reason behind cutting this many releases?

Just to add a data point, I've written a tiny Rust library [0] that can compile to WASM, that is quite effective for smaller payloads. It is based on PAQ so memory usage explodes a bit once you start compressing large files, but on smaller files it is super competitive.

As far as I can tell the blog author didn't include the 91MB file they used to test the compressors with, so I couldn't give it a try to see how it holds up. I guess 91MB would be too big anyway.

[0] https://github.com/datatrash/mashi

The trickiest part of this endeavour is finding 11 floppy disks.

Exactly.

Going further back in history there's also this thing called Film Noir that further disproves the argument that digital cameras (or, more narrowly, Netflix) is the origin of the high-contrast look.

I mean, even the most celebrated film of all time, Citizen Kane, is celebrated among other things for its stark contrast and that was shot in 1941 or thereabouts.

Is ENR similar to bleach bypass? They seem to be mentioned in the same breath but it's a bit vague.

A famous counterpoint to your statement that eighties film stocks would not be able to capture that kind of low-light high-contrast scene: Barry Lyndon (released in 1975).

However, it's pretty much guaranteed that both the old and new scenes mentioned in TFA have a _ton_ of extra lights and flags just out of camera. If anything, the article is pretty naive in assuming that they just walked up to some diner and started filming using available daylight.

No worries! There's a good chance that anything I post that sounds remotely authoritative turns out to be super inaccurate as well :)

This will not magically make extra detail appear, though. Film does not have infinite resolution.

For instance, the ARRISCAN film scanner goes up to 6k for 35mm. They could go higher, but there's no point.

Because sometimes digital footage has to be matched to film. Alternatively, some directors enjoy film artifacts just like some people enjoy analog distortion artefacts in audio.

Additionally, you seem to be asking a lot of leading questions but not volunteering any opinions of your own. Is there something you'd like to share?

Amélie is from 2001, not 1995. Interestingly, it is one of the first films that was colour corrected completely digitally. This is also why the movie's colour palette is so striking. Not necessarily to everyone's taste, but I really found it to 'pop' in the cinema.

Tarantino uses film because he likes the artifacts film gives, not because it's objectively better. Same for PT Anderson. Indeed, both directors favor grungy 1970s aesthetics, which should give you an indication where they're coming from, stylistically. Nolan typically uses large film gauges like 65mm which are not comparable to 'regular' 35mm film.

Additionally, film does not have more dynamic range than digital. Take the latest sensors used by the Arri Alexa cameras for instance, they have a range of 17 stops. This is better than regular 35mm film. [1]

[1] https://www.arri.com/en/camera-systems/cameras/alexa-35#2730...

This is completely incorrect. Later shows like Voyager and DS9 were also shot on film.

However, all post-production happened in standard definition, so all special effects, editing and colour correction would have to be redone, which is incredibly expensive.

They did that with TNG, but since those blurays didn't sell enough, they didn't bother doing the same for DS9/VOY.

To be fair, having the concept of a desktop matches quite well with the concept of a folder.

On the Amiga, you didn't have a desktop per se, but a Workbench. A Workbench has drawers.

The analogy breaks down somewhat, since I can't pull down my real-world workbench to reveal a red and white bouncing ball. Unfortunately.

I think all relevant links are in the video description.

This looks pretty nice, but so do a lot of the alternatives. In trying to search for the perfect development model none of these libraries are being developed enough to find any traction, though.

Not to take away from the effort btw, but I wish they'd bundle their efforts somehow.

It's the difference between a Rust game engine like Amethyst which spent years being rewritten all the time and Bevy, which has a community and a clear focus and are just getting it done. The argument can be made that Bevy needed Amethyst to exist in order to figure out what to do, though. Oh well.