royjacobs

Through my three year old son I've discovered the concept of Fumikiri channels on YouTube in which railway crossing signs not only protect railway crossings, but have families, go to restaurants, etc. It's a subgenre of train videos we never realised we needed.

I'm not sure language design should be a race to see who can add the most features, though.

I prefer Java's more thoughtful approach to introducing new features.

You might be thinking of the article written by Pascal of Cubic Team. I think the archive is called pasroto.zip and it explained why rotozoomer performance would tank when the texture was rotated by 90 degrees (since you're stepping in the Y direction and blowing out your cache for every pixel). Really interesting at the time.

Counterpoint: why not?

How optimized is the generated code? One of the benefits of using LLVM is the amazing set of optimization passes, after all. Will Onyx have to reimplement a lot of these optimizations?

I was prepared to read the article and scoff at the author's misuse of std::fs. However, the article is a delightful succession of rabbit holes and mysteries. Well written and very interesting!

Plug plug: I've written an assembler[0] for the 6502 (with full LSP and debugging support). It also supports the concept of unit tests whereby your program gets assembled and every test individually gets assembled and run, whereby you can add certain asserts to check for CPU register states and things like that.

[0] See https://mos.datatra.sh/guide/unit-testing.html

James Burke has a new Connections series up on Curiosity Stream, I'm looking forward to seeing it.

Looks interesting, I wonder if the method of marking functions as 'having side effects' is going to be easy to make fool proof. For instance, I assume that in the example the random number generation is a side effect because it comes from a RNG provided by flawless itself. Would this have worked with a regular Rust function as well?

I assume there is going to be some kind of test harness that allows developers to check their workflows.

It can function as a NAND gate, and anything can be built out of NAND gates. At that point it might be simpler to just use actual NAND gates though :)

I was part of the PC demoscene in that era (1997-2002) and it definitely was a super productive and exciting time. The transition to Windows wasn't necessarily a big deal, but the impact of 3d acceleration definitely was.

In that period 3d accelerators were basically capable of running Quake and not much else. Traditional demo effects that relied on reading the backbuffer (even to just do some basic postprocessing) were either unavailable or had to have bespoke implementations per card. There were no shaders to speak of, and so on.

For me that really killed demoscene innovation for a while, and a lot of demos basically consisted of a bunch of alpha-blended layers for a while.

Nowadays, though, I'd say the scene is probably doing pretty well even though it's arguably even more niche than it used to be. Oh well.

Here in The Netherlands there's a recycling box next to my local (walking distance) convenience store. There are separate openings for cables, phones, chargers, etc. It works really well and it makes it effortless to toss in an unused cable or whatever into my shopping bag whenever I need to pick up some groceries.

This is true for the demoscene in general, as well. Not completely, thankfully, but it seems like that it is becoming even more niche than it already was.

Would you rather he posted it to an open-source platform where everyone already agrees with him?

This is pretty nice. I've written some tools for my own softsynth that revolved around parsing various DAW formats and having a standard format, even just to export to, would have been very nice to have.

Meanwhile Microsoft dropped their major Windows update today too, enabling me to ungroup taskbar items. Put THAT in your Apple and smoke it!

In a movie specifically about the person Oppenheimer, why would it be considered weird that it focuses mostly on him?

I mean, the movie isn't about the broad topic of the nuclear arms race, it explicitly makes the choice not to show the bombing of Japan, there are many things it consciously leaves out. It's not a documentary, it's explicitly very subjective.

Crytek started by recruiting people from the demoscene, somewhere in the early to mid 00s. Cevat Yerli did this himself, simply by shooting off some emails to whoever did some cool demos, I guess. I got contacted as well, but this was before they were doing Far Cry. I believe it was some kind of space game, but I'm sure there are some people here who have a better recollection of that.

I'm fairly sure Italy would happily trade some pasta-based dish for unlimited hydroelectric energy.

Well sure, there are a lot of different options. But I wanted to pick a toolkit where there were already a lot of UI components available and I would haven't to hand roll a lot of them manually.

For instance, my UI contains a node graph. Since I was using Electron I could simply use react-flow [0]. As part of my research I also implemented node graphs in both imgui and Qt and, while certainly possible, it is a lot of work to get all the interaction nuances right.

The main drawback of using Electron was having to do a lot of interop work, of course, but as long as I was mostly working on the UI side I had all the benefits of hot reloading, existing design systems to pick and choose (I ultimately picked Mantine [1]), etc.

[0] https://reactflow.dev/ [1] https://mantine.dev/

Yes, but at that time Tauri did not have support for WebGPU on MacOS. Also, the Electron community is substantially larger and since this is mostly a personal project speed of development and easy access to community forums were more important to me than things like install size.

I'm looking forward to seeing how this pans out. I've been working on some WGPU based rendering code the last year or so, and in lieu of any truly decent UI libraries on the Rust side (no offence to the existing players) I ended up going the Electron route, since my code was already compiling to WASM anyway. I also explored going the imgui and Qt routes, but Electron felt the most fully featured and easy to use. Still, it's Electron.

I'm happy to see that Xilem is not blindly copying JS/Swift ideas (or 'adapting' them, as Raph says :)) but applying them in a way that feels very Rust native. They've been experimenting a lot the last few years and I really hope we're finally getting to that point where we go beyond experiments and into something useable!

Isn't that the grandparent's point though? Features that other languages have are first considered "not beneficial" and are in fact mocked as being useless or extravagant. Then, once said feature is introduced to one's favourite language, the feature is considered useful and it turns out that maybe those other languages had a reason for including them beyond mere extravagance.

edit: gp, not p

This reminds me of one of those software protection libraries. I think it was by Syncrosoft, the company that used to protect software like Cubase before it got acquired by the manufacturer of Cubase, Steinberg.

Basically you'd write your algorithms in C++ but instead of using the built-in types like int or float you'd use custom types that had all of their operators overloaded. Your code would look pretty similar to what you'd have before (modulo the type definitions) but when compiled your algorithm would turn into an incredibly inscrutable state machine where some parts of the state machine would come from some kind of protection dongle. Pretty effective.

This is pretty cool, but at the same time it's unfortunate to be reading things like "one could simply write" followed by "hc: impl HealthCheck<check(): Send> + Send + 'static".

I really enjoy writing Rust but I feel like a lot of things related to async just don't map very cleanly to the rest of the language. Apart from the complicated type shenanigans in this post there are a lot of gotchas with async that result in panics at runtime instead of compilation errors. Basically, I don't feel like Rust has my back when I'm writing async code.

Disclaimer: I am not a language designer so I have no clear idea how this could be solved, and I appreciate it's a very difficult problem!

Quite niche, or quiche.

Those tools are typically used to augment existing footage whereas a tool(l) like this is much more focused on procedural content creation like Houdini or indeed many other tooling that comes from the demoscene, which is where this came from too(ll).

Heh, what a coincidence. I was noticed the Android player Symfonium announced support for OpenSubsonic and the first link is this HN topic created less than an hour ago.

I might add support for it in the Subsonic server I wrote (mostly for personal use). https://github.com/datatrash/beatlocker

Your question was why the advice was given to avoid ThreadLocals. This is the primary reason. It's not necessarily related to avoiding a larger memory footprint.

This is such a good way to make these old games look really spectacular. 2d graphics of the era haven't aged particularly badly but old 3d games usually look pretty janky (imo!). Being able to literally see them in a new light is wonderful.