> Once this happens, players will be able to switch between OpenGL rendering and Vulkan rendering

I think this means you'll be able to continue using Minecraft with OpenGL.

In the following paragraph:

> Once we’re happy with the performance and stability of Vulkan across devices we will remove the OpenGL implementation.

So not for long.

What would be the best way to use Vulkan 1.4 in Rust today? Using the C headers with bindgen or writing my own vk.xml generator?

Clip Studio Paint seems very popular for animation. You could also consider Aseprite for pixel art animation.

Really fun! Developing my intuition for a sphere as I played was a nice experience. As other commenters have mentioned, the game ramps up a bit too slowly. Perhaps it would worth adding more than one food item.

One of the reasons I'm really excited about JAX is that I hope it will allow me to write fast Python code without worrying about these details.

Has the talent moved to anywhere in particular?

Nicholas Francis manages a fund for AgTech after a decade making games with Unity (the engine he made). He left in 2013 so I don't associate him with Unity today but it was his product.

2018 We get the new HDRP and Shader Graph.

2019 there were sexual harassment lawsuits.

The other co-founders left after they announced runtime fees in 2023 and the community fled.

2024 the URP team basically imploded. Leaving everything basically flat.

People still appear to use Flash these days by downloading an old version and getting a license key from Reddit/YouTube/etc.

I didn't really want to resort to piracy; I think it's stupid that Adobe won't sell a perpetual license.

I got a license to Moho from a Humble Bundle like a year ago, and I think Toonz is open source nowadays, all in addition to the ToonBoom copy I have so I probably don't need the real Adobe Animate anymore.

Can confirm as someone who was using pre-subscription Office to write/read files while everyone else at work was using the 365 version. Now that I'm using 365 too, I do however appreciate the ability to do shared live editing in the office programs.

If CLU only supported composition, was the Liskov substitution principle still applicable to CLU?

CLU implemeted abstract data types. What we commonly call generics today.

The Liskov substitute principle in that context pretty much falls out naturally. As the entire point is to substitute in types into your generic data structure.

No, because the LSP is specifically about inheritance, or subtyping more generally. No inheritance/subtyping, no LSP.

It is true that an interface defines certain requirements of things that claim to implement it, but merely having an interface lacks the critical essence of the LSP. The LSP is not merely a banal statement that "a thing that claims to implement an interface ought to actually implement it". It is richer and more subtle than that, though perhaps from an academic perspective, still fairly basic. In the real world a lot of code technically violates it in one way or another, though.

Yes it is, as it is about the semantics of type hierarchies, not their syntax. If your software has type hierarchies, then it is a good idea for them conform to the principle, regardless of whether the implementation language syntax includes inheritance.

It might be argued that CLU is no better than typical OO languages in supporting the principle, but the principle is still valid - and it was particularly relevant at the time Liskov proposed it, as inheritance was frequently being abused as just a shortcut to do composition (fortunately, things are better now, right?)

For me, it's the very basics of general relativity which made the distinction between the cotangent and tangents space click. Optimisation on Riemannian manifolds might give an opportunity to apply more interesting tensor calculus with a non-trivial metric.