From what I've read, this is for the first implementation of unions, to reduce amount of compiler work they need to do. They have designed them in a way they can implement enhancements like this in the future. Things like non-boxing unions and tagged unions / enhanced enums are still being considered, just not for this version.

This is the general pattern of how the C# team operates, IME.

    "Never let perfect be the enemy of good"

Very much what I've seen from them over the years as they iterate and improve features and propagate it through the platform. AOT as an example; they ship the feature first and then incrementally move first party packages over to support it. Runtime `async` is another example.

In the meantime I still haven't done any project with nullable references, because the ecosystem has yet to move along. Same applies to ValueTask for async code.

I personally like the direction C# is taking. A multi-paradigm language with GC and flexibility to allow you to write highly expressive or high performance code.

Better than a new language for each task, like you have with Go (microservices) and Dart (GUI).

I'm using F# on a personal project and while it is a great language I think the syntax can be less readable than that of C#. C# code can contain a bit too much boilerplate keywords, but it has a clear structure. Lack of parenthesis in F# make it harder to grasp the structure of the code at a glance.

There are more than 10x more users than lines of code

Being less efficient is also a problem, because if majority becomes less efficient (lower productivity), the overall wealth and economic growth of that society are going to decline significantly.

We do have evidence that when money is not a problem, we become less efficient. For example, monopolies or state run companies.

Just the first result from google: https://www.mdpi.com/2227-7390/11/3/657

Another problem with UBI is that, if we want for UBI to cover basic costs of living, these expenses are actually quite big as UBI essentially would need to cover things like rent, food and health services. Otherwise we will still have plenty of homeless people with UBI.

I think this further proves that the hypothesis of decoupling content from presentation is flawed. The question is how many more data points do we need before we admit that?

Yes, iirc the concept wasn't to decouple content and presentation but to decouple semantics from presentation in order to re-present content in different media in that medium's native representation of a particular semantic. However, many things are not much different in different media, a headline is a headline. And other things like "emphasis" can have cultural differences even within the same media, like being bold, italicized or even double-quotes.

I suppose to a limited extent, that being “articles” in the typical sense, the strategy might be said to have some modicum of success. I’m sure many CMSs store articles as mostly “plain” HTML and regurgitate the same, directly into a part of the final HTML document, with actual normal CSS rules styling that.

Try creating a task that tries to delete these tasks. It could be triggered on startup and periodically like once a day.

Some sort of LLM audit trail is needed (containing prompts used, model identifier and marking all code written by LLM). It could be even signed by LLM providers (but that wouldn't work with local models). Append only standard format that is required to be included in PR. It wouldn't be perfect (e.g. deleting the log completely), but it might help with code reviews.

This would probably be more useful to help you see what (and how) was written by LLMs. Not really to catch bad actors trying to hide LLM use.

This would be a useful feature to bake into the commits generated by agents. Heck you don’t even need to wait — just change your prompt to tell it to include more context in its commit messages and to sign them as Claude rather than yourself…

1. Without noise you become more aware of your tinnitus.

2. WFH -> Less movement -> Decreased blood flow can contribute to the onset of tinnitus.

Long exposure to high volumes causes hearing damage. Many people set volume on headsets too high to hear better.

3. Many people are diagnosed with tinnitus every day, and some are bound to have it discovered after a vaccine shot. In the same way, some people will have tinnitus discovered after COVID. That doesn’t yet prove causation.

Are we going to see more memory channels for consumer desktop at some point from AMD or Intel? Apple seems to be the only one that offers it.

Am6 Socket isn't due for a couple of years. The current sTR5 used by Threadripper processors supports up to 8 channels of memory.

I'm not sure what you mean - I think the mobile 300 series can do quad channel already for its APU at least. I'd assume it can do more but do you not need more slots beyond that?

There are a single-digit number of products using the AMD Strix Halo mobile parts that have a 256-bit memory bus. All other mobile x86 processors (including AMD's mainstream Mobile silicon used for these desktop processors) have the usual 128-bit bus.

I'm talking about desktop computers, not mobile.

> The best UX in every single instance I've encountered is consistency.

While I agree that consistency is hugely important, I have also seen a lot of cases where it made the UX worse. The reason is that, unfortunately, UX isn't so simple. There isn't a single UX rule that is always true. UX design rules (best practices, guidelines, or principles) are a good starting point, but in a lot of situations multiple rules are conflicting each other. UI/UX design is dealing with tradeoffs most of the time. Good designer will know when breaking a specific rule will actually improve the UX.

Consistency is very important, but sometimes a custom UI element will be the best tool for the job. For example, imagine UI for seat selection in a movie theater ticket booking app. A consistent design would mean using standard controls users are already familiar with, but no standard control will provide high quality UX in this situation (not without heavy modifications).

But I still I agree with you that a lot of bad UX is due to inconsistency. There needs to be a good reason each time consistency broken and often it is broken for the wrong reasons.