opticfluorine

I wonder if you could generate it via a Roslyn incremental source generator instead of as a file to bypass this limit. I'm guessing not, but it does sound like fun.

Minor nit, Joule-Thomson is not just the ideal gas law - it is a separate thermodynamic effect entirely. Case in point, for certain gases the change in temperature due to Joule-Thomson has the opposite sign that you would predict from the ideal gas law alone.

This has interesting applications. For example, you can exploit this with dilute metal vapor in an expanding helium gas to cool the metal vapor to very low temperature - the Joule-Thomson expansion of helium increases the helium's temperature by converting the energy of the intermolecular forces into heat. This draws out energy from the metal vapor. If done in a vacuum chamber, then in the region before the shockwave formed by the helium, the supercooled metal atoms will form small van der Waals clusters that can be spectroscopically probed in the jet. This was an interesting area of study back in the 80s that advanced our understanding of van der Waals forces.

I have occasionally, just for fun, written benchmarks for some algorithm in C++ and an equivalent C# implementation, them tried to bring the managed performance in line with native using the methods you mention and others. I'm always surprised by how often I can match the performance of the unmanaged code (even when I'm trying to optimize my C++ to the limit) while still ending up with readable and maintainable C#.

I personally think this last sentence from my quote makes it unclear:

"In short, if you use this project to generate revenue, the Open Source Maintenance Fee is required."

Perhaps I'm being too semantic, but I don't feel that is an accurate representation of the license terms involved here.

I came across this a few months ago when I was evaluating open source installer options for my own open source project. I have no issue with charging for binaries while the source is available under an OSI license, but this from the README rubbed me the wrong way:

"To ensure the long-term sustainability of this project, use of the WiX Toolset requires an Open Source Maintenance Fee. While the source code is freely available under the terms of the LICENSE, all other aspects of the project--including opening or commenting on issues, participating in discussions and downloading releases--require adherence to the Maintenance Fee.

In short, if you use this project to generate revenue, the Open Source Maintenance Fee is required."

I'll give the benefit of the doubt and assume this is just a difficult concept to succinctly explain in a short paragraph. But that summary - that revenue-generating use requires payment - feels misleading to me. Under their license, nothing stops me from creating my own build from source and using it per the terms of the MS-RL license, including for commercial purposes. So to me it feels like a scare tactic to coerce commercial users into becoming sponsors for the project.

I certainly understand the challenges faced by open source maintainers today, but the specific approach taken here just doesn't feel ethical to me. I ended up passing on WiX for that reason even though I'm not a commercial user.

Wasn't suggesting at all that you use my distro or that you can't use X11 as your solution. Debian is great and I use it for all of my servers. I'm just responding to the assertion that Wayland doesn't work with NVIDIA today, which is really only true if you are using older packages for a more stable distro. Nothing wrong with that, but it's not accurate to represent the current state of Wayland based on a distro known for using older packages.

I have an RTX 4060 with latest drivers, KDE, and Arch. Wayland works perfectly for me. Maybe Debian has some outdated packages that haven't caught up yet?

This definitely resonates with me. One of my favorite pasttimes is to code away on a 2D multiplayer RPG engine, and I've ended up doing at least a few of the projects on this list as part of that (ECS framework, voxel renderer, physics engine). Integration with a scripting engine like Lua is another fun one for a list like this, especially if you try to do it in an idiomatic way for your main programming language and/or leverage code generation and metaprogramming.

One thing I've found I enjoy is working on a larger-scope toy project composed of many loosely coupled systems. It works well for me because no matter what type of project I'm interested in working on, I can usually find something applicable within the larger project. Currently on my to-do list are behavior trees and procedural terrain generation, and honestly I don't know how I'm going to decide which to do first.

I wonder, how close does Godot get with its web export support? The "authoring tool" seems pretty good, and it exports to WASM.

Especially when one of the language's main purposes is to be embedded in applications written in other languages (which are predominantly zero based) - and so you tend to have a lot of back-and-forth integration between these two styles that can get confusing. Even from the C API side, for example, the Lua stack is one-based but addressed exclusively from the host language which is likely zero-based.

It is funny, isn't it? I always wonder how the language would be perceived had they gone with zero based indexing from the start.

I'm a big fan of Lua, including for the reasons you mention. I suspect the reason this one thing is always brought up is twofold: it's easy to notice, and it's very rare these days outside of Lua (if you consider VB.NET to be a legacy language, anyway). Other criticisms take more effort to communicate, and you can throw a rock and hit ten other languages with the same or similar issues.

Having just gone through the exercise of integrating Lua with a custom game engine over the past few weeks, I have to echo how clean the integration with other languages is.

It's also worth noting that the interface is clean in such a way that it is straightforward to automatically generate bindings. In my case, I used a handful of Roslyn Incremental Source Generators to automatically generate bindings between C# and Lua that matched my overall architecture. It was not at all difficult because of the way the interface is designed. The Lua stack together with its dynamic typing and "tables" made it very easy to generate marshallers for arbitrary data classes between C# and Lua.

That said, there are plenty of valid criticisms of the language itself (sorry, not to nitpick, but I am really not a fan of one-based indexing). I'm thinking about designing an embedded scripting language that addresses some of these issues while having a similar interface for integration... Would make for a fun side project one of these days.

To add to this, there are also official Microsoft extensions to VSCode which add absurdly useful capabilities behind subtle paywalls. For example, the C# extension is actually governed by the Visual Studio license terms and requires a paid VS subscription if your organization does not qualify for Visual Studio Community Edition.

I'm not totally sold on embrace-extemd-extinguish here, but learning about this case was eyebrow raising for me.

When I used to work in defense contracting, this is precisely what we (the contractor) did. We would buy up all available stock of any difficult-to-replace parts (often specific SBCs) when the manufacturer announced end of life.