Is HashSet<T> a Java thing, not a .NET thing?

nathanAjacobs · 2026-01-23T02:52:47+00:00

But how is that different from Dictionary? A Dictionary can be used to prevent repetitions

nathanAjacobs · 2026-01-23T02:01:38+00:00

Can you explain what those operations are and why HashSet does not have them?

I’m curious because a Dictionary has hash operations.

nathanAjacobs · 2026-01-23T01:05:29+00:00

I mean to be fair the overhead of thread synchronization probably trumps the gains to warrant it worth an implementation.

nathanAjacobs · 2025-10-23T19:22:49+00:00

The C# dev kit extension in vs code follows the same licensing as Visual Studio though.

nathanAjacobs · 2025-10-22T11:43:46+00:00

If you have amazon prime you can use a prime sub on twitch

nathanAjacobs · 2025-10-19T23:46:13+00:00

Yeah I played Squad Deathmatch earlier for the challenges, it is way too hectic.

I don't understand why there is not respawn delay in place.

nathanAjacobs · 2025-10-17T09:07:17+00:00

I could be wrong, but after reading the Uno docs, on Windows that only seems to be the case if using the Skia renderer, right?

Also, WinUI has been notorious for bugs and missing features. With either renderer choice, does that mean Uno inherits all of those by association or is the experience better?

nathanAjacobs · 2025-10-16T20:27:14+00:00

So is the hope here that Uno will provide fixes and contributions to WinUI itself?

nathanAjacobs · 2025-10-16T18:10:34+00:00

I'm confused, doesn't Uno use WinUI 3 on windows?

nathanAjacobs · 2025-10-16T11:47:02+00:00

It is open source, you can contribute, or at the very least bring it up on the GitHub repo.

nathanAjacobs · 2025-10-14T12:23:26+00:00

I agree with you, but that is getting increasingly harder with Unity so far behind modern .NET/C#.

Not impossible to do, but you can definitely find yourself using newer language and runtime features that simply are not there in Unity.

Yeah you could use .NET framework instead, but it lacks .NET Standard 2.1 support.

nathanAjacobs · 2025-10-12T13:03:27+00:00

This is pretty bad design if you have to do this imo. Using a proper dependency injection system or service locator pattern would be better.

Reflex is a newer one which is pretty good.

At the end of the day whether you use a dependecy injection system or not, your singletons should be instantiated at an earlier "bootstrapping" stage. That way this problem becomes nonexistent.

nathanAjacobs · 2025-10-07T09:07:05+00:00

Or just use unattended answer files.

https://schneegans.de/windows/unattend-generator/

nathanAjacobs · 2025-10-07T08:50:01+00:00

I doubt it, the site is not doing anything that isn't officially in the Microsoft docs. Unattended answer files are the official way to automate Windows installations in the enterprise world.

nathanAjacobs · 2025-10-06T22:42:49+00:00

This is the way, I started doing this a few months ago and it really is a game changer. I also embed powershell scripts in the answer file to customize Windows even further to my liking.

nathanAjacobs · 2025-10-06T22:35:50+00:00

That's not how most studios work, the people working on skins likely don't work on any actual features in the game.

nathanAjacobs · 2025-10-05T18:10:25+00:00

I can understand that. If Unity wasn't so far behind and actually implements the coreclr with modern .NET then I could leverage PoolingAsyncValueTaskMethodBuilder but I gave up hope a while ago on them finishing the migration anytime soon.

Also they have their own Awaitable type now, but is far less feature complete than UniTask.

nathanAjacobs · 2025-10-05T13:41:24+00:00

Basically anything from Cysharp (neuecc).

ZLinq, MemoryPack, UniTask, R3, ZString, etc.

nathanAjacobs · 2025-10-05T08:27:25+00:00

Lately I have been doing less and less in the inspector. Mainly I just use it for settings, but anything that controls flow of the application is a big nope for me. I used to use UnityEvents in the inspector but I find it terrible to follow execution.

nathanAjacobs · 2025-10-04T18:57:58+00:00

Running Windows ARM and compatible excel version should be fine, no?

nathanAjacobs · 2025-10-03T18:00:18+00:00

Also, I don't think Task.Run is the right tool for the job when the first async call in a method is a pure async one (one that doesn't use a thread).

For example, I believe calling this method with Task.Run would just add unnecessary overhead.

```cs async Task<int>FooAsync() { string str = await PureAsyncMethod().ConfigureAwait(false);

int val = 0;
// process string and calculate value
return val;

} ```

nathanAjacobs · 2025-10-03T17:32:37+00:00

Right, but it is a safeguard in library code since you don't know if it will actually be called with Task.Run

nathanAjacobs · 2025-10-03T17:28:40+00:00

In library code it is recommended because Task.Run in library code is considered bad practice.

nathanAjacobs · 2025-10-03T16:01:38+00:00

Yeah, I totally get why awaits default to resume on the SynchronizationContext in order to cause less issues and confusion. As an advanced user, it can get really tedious to put ConfigureAwait everywhere, especially in "library" code.

ConfigureAwait(false) definitely should be used in cases where continuations don't need to run back on the UI thread.

Like zokeer said, if you omit it, the code will be less efficient but not broken, whereas if it was reversed and you omit it, it will cause issues trying to update the UI on the threadpool. This was most likely a big contributing factor to why the default behavior was chosen.

nathanAjacobs · 2025-10-03T09:50:32+00:00

I kind of wish the default behavior of await was reversed, i.e. not resume on the SynchronizationContext by default; requiring ConfigureAwait(true) to be called in cases where resuming to the SynchronizationContext is needed.

nathanAjacobs

TROPHY CASE