Hacker Newsnew | past | comments | ask | show | jobs | submit | CuriouslyC's commentslogin

Valve has a spear lined up at so much of big tech right now it's honestly impressive they've done it in stealth for so long. Google, Microsoft and Apple are all in the crosshairs in a big way, and I don't think they can avoid the blow that's coming without cannibalizing their margins.

I'm not sure they've got Apple targeted so much, because Apple has been so thoroughly not-invested in gaming. The place they're closest to colliding is VR, but Apple's Vision headset is doing something really different from Valve's VR products, which are far more directly lined up against Meta's Oculus.

Valve could branch into Apple's areas, but they don't seem particularly interested in doing so yet.

EDIT: rather, Apple cares a lot about phone gaming, but that's an area that Valve has shown few signs of moving in on.


> because Apple has been so thoroughly not-invested in gaming

Is Apple invested in anything at all right now? Seems like they are only ever iterating over the same products in their idiotically domain separated legacy zoo of devices. Lately even fucking that up with UI "innovation" literally everyone hates. I mean, who's talking about Apple VR anymore? Apple AI is a meme. What are they cooking with all that cash?

I don't think Valve has to even consider Apple.


They've shown signs of moving on phone gaming if you know what to look for. https://www.pcmag.com/news/valve-has-quietly-backed-projects...

I feel like this was more in support of their new VR headset which has an ARM processor. I actually doubt we'll see a Steam Phone even if the idea is interesting to me (since it would be a linux phone). At least, I don't think we'll see it any time soon.

> since it would be a linux phone

It doesn't have to be. Proton runs fine on Android.


On the other hand, Valve has built a compatibility layer for ARM Linux to run Android APKs, so if anyone could make a jank-free Linux phone it would be them

Sure, but so did Jolla and Waydroid. I think the consensus is that AOSP > Linux for the average Joe's mobile handset.

They’d need to improve desktop Linux a lot to threaten Apple. It’s far more tolerable on their relatively tightly-controlled and stable hardware platforms than it is elsewhere, but it’s still a features-weak jankfest compared to macOS. I mean user facing features relevant to any desktop user, not “docker is native on it” or other developer-only stuff—and for the record Linux was my main desktop OS for about a decade, so I’m far from unfamiliar with it, and I do own a Steam Deck and have used it extensively in desktop mode (and in console-alike mode).

I’d love someone to actually compete with Apple at the specific kind of thing they do, but I don’t see it in the cards for Valve. Too much distance, with things they don’t have to solve to hit other (apparent) targets of theirs.

As for Microsoft, what is Valve threatening? Home no-business-use-case (mostly gaming and maybe light web browsing) PC owners, and I suppose x-box? The former has got to be negligible at this point, and the latter… I guess maybe, yeah, they could threaten that.

[edit] to soften this somewhat, I do love what Valve is doing and their micro-PC thing they’re releasing next year is likely going to be an instant purchase for me, provided supply issues don’t drive the price insanely high or otherwise mess with the release. I happen to be in the exact niche of people who are thrilled to have a good low-tinkering option that lets me ditch my last Windows machine, so this stuff’s my jam.


I have a MBP M4 and a Linux desktop, and to be honest other than the Apple ecosystem integration (which is good but doesn't matter to me because I have an android phone) the system software is generally mediocre and annoying.

The third party Mac software is often better, but not always.


> Home no-business-use-case (mostly gaming and maybe light web browsing) PC owners, and I suppose x-box? The former has got to be negligible at this point

With the broader job market being not-great, and everyone trying some sort of side hustle with the aims of making it big, it's definitely the bubble I'm in, but the "home" case has a lot of Google free office suite business looking usage, and even if there isn't a side hustle, maybe my friends are super weird but they use Google sheets to organize things even for non-business life things when things get complicated. Eg planning a wedding. That's Google and not Valve, but if customers get Steamboxes to access that vs Windows laptops (or Chromebooks), it looks like a threat to Microsoft to me. (But it's been the year for Linux on the desktop for decades now, so I'm not holding my breath.)


You should check out the adoption curve for Linux desktops, it's actually starting to hockey stick, Windows 11 is a dumpster fire, Apple is stagnant and Arch based distros are getting crazy good.

> I'm not sure they've got Apple targeted so much, because Apple has been so thoroughly not-invested in gaming.

And yet, Apple controls the world's largest gaming economy (~$78B in 2025), dwarfing Sony's (~$31B) and Microsoft's (~$24B).


I could amend to "Apple is thoroughly not-invested in the kind of gaming that Valve is invested in".

How are Google and Apple in its crosshairs (article's framing notwithstanding)?

From what I see, Microsoft is the only one they have been gunning for, and even that behemoth is looking to get out of the way. Their Xbox platform has practically imploded, and they have specifically designed Windows 11 to be less of a PC operating system and more of an ads platform and a cross-selling channel for their AI/cloud offerings indicating that they've lost interest in the consumer market as a whole.


Valve is clearly using games as a wedge, the Steam Machine is (and will continue to be) pushed as a capable general purpose computing device, and as the Linux desktop experience improves they will lean harder into that angle, until they're selling sexy general purpose devices with a user experience comparable to Apple's. This includes phones, though the timeline for that will lag a few years.

I've learned a lot of shit while getting AI to give me the answers, because I wanted to understand why it did what it did. It saves me a lot of time trying to fix things that would have never worked, so I can just spend time analyzing success.

There might be value in learning from failure, but my guess is that there's more value in learning from success, and if the LLM doesn't need me to succeed my time is better spent pushing into territory where it fails so I can add real value.


Understanding "why it works" is one thing, understanding "why it should work this way and not another, and what the alternatives are" is entirely different. AI shows you just one of countless correct implementations. You might understand that single implementation, but not the entire theory behind it

>I've learned a lot of shit while getting AI to give me the answers

I would argue you're learning less than you might believe. Similarly to how people don't learn math by watching others solve problems, you're not going to learn to become a better engineer/problem solver by reading the output of ChatGPT.


If I know what I want to do and how I want to do it, and there's plumbing to make that a reality, am I not still solving problems? I'm just paying less attention to stuff that machines can successfully automate.

Regarding leveling up as an engineer, at this point in my career it's called management.


Do you honestly think that’s how people learn?

This is an example of a book on Common Lisp

https://gigamonkeys.com/book/practical-a-simple-database

What you usually do is follow the book instructions and get some result, then go to do some exploration on your own. There’s no walk in the dark trying to figure your own path.

Once you learn what works, and what does not, then you’ll have a solid foundation to tackle more complex subject. That’s the benefit of having a good book and/or a good teacher to guide you to the path of mastering. Using a slot machine is more tortuous than that.


I don't find it to be more torturous than that. In fact, if I were to go back and learn lisp again, I think I'd be a lot more motivated seeing how to build something interesting out of the gate rather than the toy programs I learned in my racket course.

Also, for a lot of things, that is how people learn because there aren't good textbooks available.


Define interesting.

I was helping a few people on getting started with an Android Development bootcamp and just being able to run the default example and get their bearing around the IDE was interesting to them. And I remember when I was first learning python. Just doing basic variable declaration and arithmetic was interesting. Same with learning C and being able to write tic-tac-toe.

I think a lot of harm is being done by making beginner have expectations that would befit people that have years of experience. Like you can learn docker in 2 months to someone that doesn't even know Linux exists or have never encountered the word POSIX.

Please do read the following article: https://www.norvig.com/21-days.html


Not trained on pro, distilled from it.

What do you think distilled means...?

It's good to keep the language clear, because you could pretrain/sft on outputs (as many labs do), which is not the same thing.

This is true when SaaS is a simple widget for everyone. The problem is that when SaaS becomes a hydra designed to do a million things for a million people, the extra eyeballs aren't helping you, they're creating more error surface.

On top of that, SaaS takes your power away. A bug could be quite small, but if a vendor doesn't bother to fix it, it can still ruin your life for a long time. I've seen small bugs get sandbagged by vendors for months. If you have the source code you can fix problems like these in a day or two, rather than waiting for some nebulous backlog to work down.

My experience with SaaS is that products start out fine, when the people building them are hungry and responsive and the products are slim and well priced. Then they get bloated trying to grow market share, they lose focus and the builders become unresponsive, while increasing prices.

At this point you wish you had just used open source, but now it's even harder to switch because you have to jump through a byzantine data exfiltration process.


Not sure why the argument is SaaS or build from the ground up. Agents can deploy open source projects and build new featurees on top of them pretty effectively.

I'm gonna go ahead and guess that if you have open source competitors, within two years your moat is going to become marketing/sales given how easy it'll be to have an agent deploy software and modify it.


Anthropic has good marketing, but ironically their well marketed mediocre ideas retard development of better standards.

Pro tip, just add links in code comments/readmes with relevant "skills" for the code in question. It works for both humans and agents.

This is exactly what I do. It works super well. Who would have thought that documenting your code helps both other developers and AI agent? I've been sarcastic.

I would argue that many engineering “best practices” have become much more important much earlier in projects. Personally, I can deal with a lot of jank and lack of documentation in a early stage codebase, but LLMs get lost so quickly, or they just multiply the jank faster than anyone ever could have in the past, making it much, much worse for both LLMs and humans.

Documentation, variable naming, automated tests, specs, type checks, linting. Anything the agent can bang its proverbial head against in a loop for a while without involving you every step of the way.


This might be one of the best things about the current AI boom. The agents give quick, frequent, cheap feedback on how effective the comments, code structure, and documentation are to helping a "new" junior engineer get started.

I like to think I'm above average in terms of having design docs alongside my code, having meaningful comments, etc. But playing with agents recently has pointed out several ways I could be doing better.


If I see an LLM having trouble with a library, I can feed its transcript into another agent and ask for actionable feedback on how to make the library easier to use. Which of course gets fed into a third agent to implement. It works really well for me. Nothing more satisfying than a satisfied customer.

I've done something similar. I ask agents to use CLIs, then I give them an "exit survey" on their experience along with feedback on improvements. Feels pretty meta.

Whew, someone has some /new stans. A mostly Claude written piece of meandering navel gazing that tries to punch above its philosophical weight and fails.

I also soldiered through the piece and felt that unique way you feel after reading an unusually contentless longish text.

> A mostly Claude written piece

I don't disagree with your overall assessment, but I'm curious about the basis for specific attribution to Claude?

Also if that's actually the case, it's incredibly ironic that we have a person who, presumably, is supposed to possess "intelligence", relying on a language model to help formulate and express their ideas about why models can't be intelligent.


NATS data is ephemeral in many cases anyhow, so it makes a bit more sense here. If you wanted something fully durable with a stronger persistence story you'd probably use Kafka anyhow.

Core nats is ephemeral. Jetstream is meant to be persisted, and presented as a replacement for kafka

> NATS data is ephemeral in many cases anyhow, so it makes a bit more sense here

Dude ... the guy was testing JetStream.

Which, I quote from the first phrase from the first paragraph on the NATS website:

    NATS has a built-in persistence engine called JetStream which enables messages to be stored and replayed at a later time.

So is MQTT, why bother with NATS then?

MQTT doesn't have the same semantics. https://docs.nats.io/nats-concepts/core-nats/reqreply request reply is really useful if you need low latency, but reasonably efficient queuing. (making sure to mark your workers as busy when processing otherwise you get latency spikes. )

You can do request/reply with MQTT too, you just have to implement more bits yourself, whilst NATS has a nice API that abstracts that away for you.

oh indeed, and clusters nicely.

It's architecture dependent. A fairly functional modular monolith with good documentation can be accessible to LLMs at the million line scale, but a coupled monolith or poorly instrumented microservices can drive agents into the ground at 100k.

I think it's definitely an interesting subject for Verification Engineering. the easier to task AI to do work more precisely, the easier we can check their work.

Yup. Codebase structure for agents is a rabbit hole I've spent a lot of time going down. The interesting thing is that it's mostly the same structure that humans tend to prefer, with a few tweaks: agents like smaller files/functions (more precise reads/edits), strongly typed functional programming, doc-comments with examples and hyperlinks to additional context, smaller directories with semantic subgroups, long/distinct variable names, etc.

Aren't those all things, humans also tend to prefer to read?

I like to read descriptive variable names, I just don't like to write them all the time.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: