lightingthedark

The animation doesn't work for me with Firefox on Android. The laptop is totally missing and instead it just shows a static image of a logon screen. I was very confused until I tried it in Chrome.

There is another important reason not to store the vtable pointer in the object: performance! In C++ if you want to make a virtual method call you have a double indirection where you must first load the object and only then can you load the vtable. Having a fat pointer like Rust does means that both loads can be in flight at once. If you are using enough dyn references to care about the extra memory then you'll likely care about the performance impact of those extra indirections even more.

Maybe not 10, but my company (in the US) has relationships with several machine shops nearby (some within walking distance of our office) that do custom metal fabrication for us, and sendcutsend and xometry can handle more exotic stuff without having to ship it from Shenzhen. I think the bigger advantage of Shenzen is more for actually manufacturing at production volumes cheaply, although maybe if you need something really exotic? Custom metal fabrication is not a good example here, I have a neighbor who runs a custom CNC parts business out of his garage (said garage is largely taken up by his CNC mill).

It's interesting seeing all of the different ways language designers have approached this problem. I have to say that my takeaway is that this seems like a pretty strong argument for explicit end of statements. There is enough complexity inherent in the code, adding more in order to avoid typing a semicolon doesn't seem like a worthwhile tradeoff.

I'm definitely biased by my preferences though, which are that I can always autoformat the code. This leads to a preference for explicit symbols elsewhere, for example I prefer curly brace languages to indentation based languages, for the same reason of being able to fully delegate formatting to the computer. I want to focus on the meaning of the code, not on line wrapping or indentation (but poorly formatted code does hinder understanding the meaning). Because code is still read more than it is written it just doesn't seem correct to introduce ambiguity like this.

Would love to hear from someone who does think this is worthwhile, why do you hate semicolons?

I think that identity verification "to protect the children" is a mistake. As a parent I know how hard it can be to keep kids safe online, and that having tools to help can make a big difference. But the potential for abuse by governments and corporations is too big of a danger. If it is really possible to build systems that can verify age while preserving anonymity that would be a valuable tool. We will have to see what Discord offers here. Their first attempt burned a lot of the goodwill with their users, and at this point they will have prove they are serious about doing this right. One important thing that they claim they plan is that verification will be optional and only gate off age restricted content, that is much better than requiring age verification to access the platform at all.

I have a Reolink doorbell. It records to a SD card and works great with my Home Assistant setup. So much better than the Ring it replaced.

Okay so in the multiple list case performance would actually be worse because you'd have a double pointer dereference. I was thinking you'd have the list nodes contiguous in memory so the first dereference would always hit cache but that's a bad assumption for a linked list.

Since you shouldn't reach for a linked list as a default data structure modern hardware anyway, I actually do see how this change makes sense for Zig. Neat!

Technically that should be possible the other way by using a Node<T> so the type of the second list ends up being a Node<Node<T>> but I can see why an intrusive list would be preferred to that, and also the linked list API might prevent that pattern.

Usually if I have multiple lists holding something I have one that's the 'owner' and then the secondary data structures would have a non-owning pointer to it. Is that the case where the performance would be better with an intrusive list? My intuition would be that having multiple Node members would pollute the cache and not actually be a performance win but maybe it is still better off because it's all colocated? Seems like the kind of thing I'd have to benchmark to know since it would depend on the number of lists and the size of the actual data.

Can someone explain how the claim of higher performance works here? In C, which lacks generics, an intrusive list is preferred because otherwise you end up with each node having a void pointer to the data it holds. The previous Zig version was a generic, so the data type could easily be a value type. Given that the compiler is allowed to rearrange the layout of both structs unless data is packed or extern (in which case it almost certainly won't want to have a linked list node in the middle anyway) isn't the resulting type exactly the same in memory unless you intentionally made T a pointer type?

If you haven't read it, there's a great paper on the netcode of the originals: https://zoo.cs.yale.edu/classes/cs538/readings/papers/terran...

I'd be surprised if the definitive editions changed the design significantly enough to move the netcode away from P2P, but I don't know of any actual information on it.

I believe the originals just supported offline LAN play. I remember getting my friend to have his modem dial my modem so we could play together, no Internet connection required.

You don't need floating point RGB for additive blending, but to get correct behavior when using additive blending for your light sources, you must use linear buffers and if you do that, the dynamic range of the scene won't fit in eight bits.

Look at the fourth one on the bottom, you can see the black splotches. It's not the best example I've seen, a quick search turned up this better example, notice how the edges become all dark: https://forum.shotcut.org/uploads/default/original/2X/e/edb3...

Rust moves aren't quite the same as C++ moves, you can think of them more like a memcpy where the destructor (if there is one) doesn't get run on the original location. This means you can move an immutable object, the object itself doesn't have to do anything to be moved.