kllrnohj

> The RTX 5050 8 GB is 10-20% faster

yeah... like I said, basically the same? but if you're determined to split hairs, then that 10-20% faster is also 10-20% more expensive ($1050 vs $1200), so it's still a wash either way. But when "just" a 5060 Ti 8gb (supposedly a $380 GPU) is then 50% faster than the 5050... Clearly the steam machine and 5050 are playing in the same ball pit here. They're doing the same gaming experience

Just to pick on someone, iBuyPower's cheapest "RDY" prebuilt gaming PC has 6 performance cores, 16GB RAM, 8GB VRAM RTX 5050, 1TB NVME, and costs $1200. Basically same specs as the Steam Machine, for a very similar price, but in a typical midtower instead of a sleek, compact cube

The price of this steam machine is a rounding error away from the build it yourself DIY price. It's not marked up, this is just what PC components actually cost these days :/

This is often given as the defensible reason, but it's not even that true. Java 1.5/5 had several "breaking" changes in it regardless including the newly reserved 'enum' and a whole freaking memory model update.

And besides if any of your dependencies updated for all practical purposes you did, too, since you had to use a newer runtime to run their code regardless, it never really made sense to keep using an older javac out of spite

This says the UNAS Pro 8 can saturate 20gbe with reads. It won't with just a single user, though, so for homelab enthusiasts it's less attractive even though the price is appealing. But for an actual small business using it to serve a handful of people? The 10gbe isn't a waste

That is exactly why Rust's behavior for +/- operators is a mistake and wrong. It should always panic and anyone that wants something different can specify that in code, where it's clear and explicit.

I don't know if Rust will ever attempt to fix this mistake, but I seriously hope they do.

It lets Rust claim to be UB free without delivering the actual value of being UB free. You still can't rely on a given behavior because it doesn't have one behavior, it has two, and the two behaviors are wildly incompatible with each other.

imo one of those soundness holes is caused directly from trying to prevent UB - integer overflows. It is inconsistent in Rust what happens in that scenario depending on compiler flags, which basically just makes it UB for any given piece of code. And, unfortunately, default release mode behavior is unsafe.

If someone tells you to write a web app, do you also cry? Surely there's more JavaScript frameworks than subsets of C++ at this point, no? Do you also go memorize all of them? Or do you just quickly pick one, and then only learn that one, and forget the rest exist? Because that's kinda how you approach C++. You pick a subset (like, say, just modern C++, only caring about C++17 & later or whatever), and just use that. And move on with your life. There's absolutely no reason to learn how std::auto_ptr works because it's dead in the same way you aren't learning how PHP & CGI works if you're making a modern web app. They're dead relics of the past that you can just pretend don't exist.

You're almost certainly better off with Rust at this point or, if you must have C-like development, Zig.

None of HDR10, HDR10+, or DolbyVision ever answered the question of how to adapt for varying ambient brightness levels, either, which is again a very important question to answer for portable devices like phones, tablets, and laptops.

But at a high level you're basically asking "why doesn't scRGB exist" and, well, it does :) https://en.wikipedia.org/wiki/ScRGB (also called extendedSRGB)

Possibly, but Apple choosing a new, thicker chassis the same generation that they introduce their more power efficient replacement is certainly a thing. Even if Intel failed to achieve the TDP they told Apple, Apple also seems to no longer believe the thinness they were doing was viable for that TDP anyway.

Intel's product offering certainly wasn't as compelling towards the end there, but it also looked almost uniquely bad in Apple's chassis vs everyone else's

Although I'm kinda surprised the DGX Spark used USB-C at all for power instead of just like a DC jack or whatever. But whatever.

Well, MediaTek actually said they made most of the SoC in fact. But the actual CPU cores themselves are all but certainly off-the-shelf Cortex parts, since MediaTek doesn't have a custom core design at all afaik.

Qualcomm is also working on a really good ARM ISA CPU with their acquisition of NuVia and subsequent Oryon architecture.

Meanwhile this is just using off-the-shelf ARM CPUs in a MediaTek SoC with blackwell bolted to the side of it. ARM's CPUs so far have been subpar for laptop-class chips. Hence why neither Apple nor Qualcomm are using them.

did you miss the context I was responding to? They were comparing against JS & Python and rapid iteration speeds. That's obviously not "serious systems work" where GC pauses matter

> this does not exclude the possibility of creation of libraries that manage everything for me within their domain of responsibility, such as dvui

Sure, but if you're philosophically okay with hidden allocations and control flow, why not just choose a language that doesn't compromise itself for those ideals in the first place?

Didn't Go already do that?

> I am so used to thinking that Zig, Rust, and the likes are only viable in niches where C is viable, but no. not anymore at least - once this linker and incremental compilation on other targets land, Zig will become THE C replacement

Yes, and it will still only be useful in the same niche that C is because the entire philosophy of Zig is to essentially be like C. You're never going to interate at JS/Python speeds with Zig because you'll always be wrangling with memory lifecycles, object lifecycles, etc...

Rust is significantly different.

It's unlikely to be just a devex issue. The fact of the matter is that a memory unsafe language is an extremely tough sell today, and companies that have a security team at all have likely already made or are planning on making policies like https://chromium.googlesource.com/chromium/src/+/master/docs...

There's a reason "rewrite it in Rust" was a meme long before LLM coding tools or this Bun drama. With AI accelerated fuzzing techniques and similar, memory safety is rapidly going to become a basic requirement of anything run in a production environment.