TCP or UDP are orthogonal to this, so the original comment feels like a non sequitur. These streams are not network streams and could be a file, chunks of procedural audio, or whatever.
I agree, the stream concept should be (and is) very general and ideally cover all these cases - any “bytes producing” source.
I was trying to be open minded about that and conceive a stream API over a UDP socket. It’d work IMHO, but be a little odd compared to an event-like API.
Depends. If I was the one coming up with the implementation anyways, it's basically just the "coding" part that was replaced with "fingers hitting keyboard" and "agents writing to disk", so reviewing the code certainly is faster, you just have to "check" it, not understand it from scratch.
If we're talking receiving random patches where first you have to understand the context, background and so on, then yeah I agree, it'll take longer time probably than what it took for someone to hammer with their fingers. But again, I'm not sure that's how professionals use LLMs right now, vibe-coding is a small hyped world mostly non-programmers seem to engage in.
> you just have to "check" it, not understand it from scratch.
How can you "check" that which you don't "understand"?
> I'm not sure that's how professionals use LLMs right now
I'm a professional and I can tell you how I use LLMs: I write code with their assistance, they don't write code for me.
The few times I let Claude or Copilot loose, the results were heartbreaking and I spent more time reviewing (and then discarding) the code than what it took me to later write it from scratch.
> How can you "check" that which you don't "understand"?
??? I do understand, since I literally just instructed it, how would I otherwise? I'm not letting the LLM do the design, it's all me still. So the "understand" already exists before the LLM even finished working.
> I'm a professional and I can tell you how I use LLMs: I write code with their assistance, they don't write code for me.
Hey, welcome to the club, me too :) I don't write code, I write English prose, yet nothing is vibe coded, and probably I'll end up being able to spend more time than you thinking about the design and architecture and how it fits in, because actual typing is no longer slowing me down. Yet again, every line is reviewed multiple times.
It's more about the person behind the tools, than the tools themselves I think ultimately. Except for Copilot probably, the times I've tried it I've just not been able to produce code that is even slightly up to my standards. It's a breeze with Codex though (5.2), and kind of hit and miss with Claude Code.
Maybe they are able to write unambiguous fully specified English prose? But yeah there should tell the world then, we others desperately don't know how to do that.
> But hey, don’t take it from me. Take it from… the Copilot people. According to The Verge and a bunch of other reputable news sources, Microsoft is openly encouraging their employees to use multiple tools, and as a result, Claude Code has rapidly become dominant across engineering at Microsoft.
Well, that explains the sloppy results Microsoft is delivering lately!
They're just trying to ride the wave of Valve's deck (and they will fail). The fact is that, since I bought the Steam Deck, I bought less from GOG and more from Valve.
And this won't change a thing: it doesn't matter if they make a Linux-native frontend to the horrible GOG Galaxy. I just want my games to launch as seamlessly as they do from Valve's UI, not yet another launcher that I have to launch on top of Valve's system UI. I am already doing that with Heroic Games Launcher, which is far better than whatever they will concoct in-house and supports many other stores.
>I just want my games to launch as seamlessly as they do from Valve's UI
Valve integrated steam all the way down to the OS level to do all that. GOG galaxy meanwhile is focusing more on being an accompanying app to optionally use than centralizing everything under GOG. I think Galaxy trying to strive to be as "seamless" will break the very philosophy of GOG to begin with; being a store to grab games you truly own, not a platform to immerse yourself in.
While on the other hand I'm often frustrated and feel limited by a steam-only deck and am going to start installing the other store fronts. I have games there I've gotten cheaper or even free. I don't like being locked into steam and "Gabe the goodest billionaire" propaganda exists to keep people from engaging in competitor products. I also want to support stores that take less from developers, especially smaller ones. Steams 30% cut while Epic is 0% up to $1m is concerning. I want smaller devs to succeed better. Steam is a huge compromise even if its a 'fan favorite' quasi-monopoly.
So yes I want gog to be native linux on things like the deck.
OP isn't claiming all runtime bugs can be prevented with static lints suggested by LLMs but, if at least some can, I don't see how your comment is contributing. Yet another case of "your suggestion isn't perfect so I'll dismiss it" in Hacker News.
Why is this such a common occurrence here? Does this fallacy have a name?
In Spain's case Telefonica (largest telecom, used to be state owned) is private but has a large State participation and the government literally appointed the latest CEO.
Guess who sells the largest football games as part of their expensive TV package?
Guess who asked a judge to order the other telecoms to also block Cloudflare IPs?
If this is true, and seems likely. There is some satisfaction seeing corrupt cronyism agencies getting slapped with a hard "NO" when they are used to getting what they want.
reply