MurphyA/hacker-news huggingface dataset:
by laurencerowe | 2025-07-30 05:56:52+00:00
> One key part of how async/await works in Python is that nothing really happens until you call await. You’re guaranteed not to be suspended. Unfortunately, recent changes with free-threading make that guarantee rather pointless. Because you still need to write code to be aware of other threads, and so now we have the complexity of both the async ecosystem and the threading system at all times.

I don’t understand how free-threading changes things here. In a multithreaded Python program without free-threading you might be preempted at any point before calling await at the granularity of the GIL.
by johnisgood | 2025-07-30 05:57:54+00:00
Not even only that, but it can auto-scroll to ANY parts these days, see: "URL Text Fragments".

https://www.lexo.ch/blog/2025/01/highlight-text-on-page-and-...

In any case, yeah, what was suggested in the submission is nothing esoteric, but I guess everything can be new to someone.
by PaulRobinson | 2025-07-30 05:58:21+00:00
Despite the name of "Generative" AI, when you ask LLMs to generate things, they're dumb as bricks. You can test this by asking them anything you're an expert at - it would dazzle a novice, but you can see the gaps.

What they are amazing at though is summarisation and rephrasing of content. Give them a long document and ask "where does this document assert X, Y and Z", and it can tell you without hallucinating. Try it.

Not only does it make for an interesting time if you're in the World of intelligent document processing, it makes them perfect as teaching assistants.
by hardwaresofton | 2025-07-30 05:58:30+00:00
If I'm understanding the suggestion, the proposed python virtual threads are ~= fibers ~= stackful coroutines.

I have this paper saved in my bookmarks as "fibers bad":

https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p13...

AFAIK sync/await and stackless coroutines are the most efficient way to do async operations as far as I can tell, even if they are a unwieldly and complicated. Is there something to be gained here other than usability?

Python is certainly in the business of trading efficiency and optimal solutions for readability and some notion of simplicity, and that has held it back (and all the programmers that overindex on the pythonic way, it's incredibly sad that all of modern ML is essentially built on python) IMO, but the language is certainly easy to write.

[EDIT] - wanted to put here, people spend a lot of characters complaining about tokio in Rust land, but I honestly think it's just fine. It was REALLY rough early on, but at this point the ergonomics are quite easy to use and understand, and it's quite performant out of the box. It's not perfect, but it's really quite pleasing to use and understand (i.e. running into a bug/surprising behavior almost always ends in understanding more about the fundamental tradeoffs and system design for async systems)

Swift doing something similar seems to be an endorsement of the approach. In fact, IIRC this might be where I saw that first paper? Maybe it was a HN comment that pointed to it:

https://forums.swift.org/t/why-stackless-async-await-for-swi...

Rust and Swift are the most impressive modern languages IMO, the sheer amount of lessons they've taken from previous generations of PL is encouraging.
by rtpg | 2025-07-30 05:58:42+00:00
I just disagree with the article's premise of:

> Adding non-primitive props you get passed into your component to internal dependency arrays is rarely right, because this component has no control over the referential stability of those props.

Expecting referential transparency is a fine constraint. Inversely, the useRef technique might lead to its own weirdness where your UI is using some stale composite object that your event handler doesn't see anymore (and I prefer slow perf to chasing down correctness issues because you have a ref _and_ you have some accidental mutability somewhere in the stack _and_ you have stale UIs)
by seec | 2025-07-30 05:59:35+00:00
Yep, this is distorted "competition". The actors are not playing by the same rules because one party isn't forced to follow them to the same extent and doesn't have a whole lot to lose if it doesn't follow them at all.

The reality is that it isn't just a Temu problem, "free trade" with countries that do not have the same rules is necessarily imbalanced. It seems crazy to me that we impose very stringent rules inside the EU for many things and then allow anyone to import stuff from a faraway country that doesn't have to follow those rules.

China has been cheating by definition for many years now and it's just now that people are reacting because it's now clear we have exported all the value creation process thanks to a lack of protection for inside actors...
by nromiun | 2025-07-30 05:59:50+00:00
After several years of dealing with concurrency I have come to the same conclusion.

Cooperative multitasking is not worth the pain of manually selecting where your IO hot spots are. It is too easy to block your entire program and not easy to debug where it is getting blocked.

IMO preemptive scheduling like Goroutines and Java virtual threads are the future. As a bonus they play well with parallelism too, because you are already doing all the synchronization.
by EagnaIonat | 2025-07-30 06:00:42+00:00
> What, the cloud scanning of user photos was a good idea for you?

That is what is happening before Apples suggestion and is still happening.

> The automated surveillance that could lead to people wrongfully accused idea?

A hash scan is perfectly fine. It can tell you nothing about what is in your file except that if it matches another file that they know is CP.

Even then a flagged item has to be reviewed by law enforcement in case of a mistake and a single file is normally not enough to convict.

The chance is very slim of a mismatch. Facebook for example report a 1 in 50 billion chance of a mismatch.

To put that in context. The chance of a miss is 1 photo every 10 years across all users of facebook (approx 3 billion active users).

> If Apple can decrypt your data when they find a match, they can decrypt ALL your data.

Again. This is what is happening now for ALL service providers.

Apples suggestion was that if a file wasn't flagged it could only be decrypted by the owners device and nothing else. Not even Apple.
by sagarm | 2025-07-30 06:00:57+00:00
LLM evaluation on GPU and CPU is memory bandwidth constrained. The highest-end Apple machines are good for this because they have ~500GBps high memory bandwidth and up to ~128GB, not just because they can share that memory with the GPU (which any iGPU does). Most consumer machines are limited to 2xDDR5 channels (~50GBps).
by brazzy | 2025-07-30 06:01:58+00:00
I is absolutely a VERY valuable distinction because the behavior as it affects humans (up to and including killing them) is VERY different.

Regular waves that are a little higher than your seawall might cause some water damage to the buildings right next to it. A tsunami that is a little higher than your seawall will flood your entire town and drown people who are caught in basements.
by lelanthran | 2025-07-30 06:03:00+00:00
When I got my first credit card, circa mid-90s, no one told me I had to sign the bank. Took my brand new card with my brand new girlfriend to a shop and bought something.

Handed the clerk my card during payment, she looked at it and said it is not signed so she is not allowed to accept it. I took it back, she gave me a pen, I signed it and gave it back to her.

She ran the transaction, got an approved slip, gave me the slip to sign, I signed it and gave it back.

She compared the signature on the slip to the signature on the back of the car, and Lo And Behold, They Matched!
by rahulbisht | 2025-07-30 06:04:23+00:00
I've been working on a project called Stac.dev - It's a Server-Driven UI framework for mobile apps. We are currently supporting Flutter, but native android & ios support will come soon. The main idea is to help developers(and teams) update mobile app easily, without having to push app updates through the PlayStore or AppStore everytime.

It came out of frustration with how slow and rigid it is to ship frequent UI changes, especially for onboarding flows, home screens, or anything that’s experiment-heavy.

Some things you can do with it:

- Push UI changes instantly via JSON configs

- Customize UI per user, like showing different screens based on their profile

- Iterate on layouts and flows without triggering a full release cycle

A couple of real world examples where it’s useful:

1. Fintech onboarding: say you want different fields based on the country or change requirements for credit checks. You can do that on the fly.

2. Fintech home: if someone only uses mutual funds in your app, you can personalize the home screen to show more relevant stuff or cross-sell.

Please try it out. Feedback and suggestions are appreciated :)
by teiferer | 2025-07-30 06:04:46+00:00
How come you are assuming that there is an "end goal"?

Humans believing that they are special is as old as human history goes. Special as a species, but many groups also consider themselves special, and individuals as well. Seems to be an emergent thing from the human psyche. One that has had terrible consquences over the millenia, but I might be overlooking the upsides.
by viccis | 2025-07-30 06:05:43+00:00
A couple of things, some of which are difficult topics to broach:

1. Every dude here is pretty unattractive, so the question is which camera gives them enough camera makeup to hide it. If you shake your head at this, take a peek at this: https://i.imgur.com/vdD5r8M.jpeg Every dude is mewing for his life in the latter photo

2. They aren't making the same face for each shot, so all of this is a waste of time. That's so much more important.

3. The only real difference is just the background being blurred or not. Otherwise it's a totally different pose for each guy.
by Ancapistani | 2025-07-30 06:06:51+00:00
This is the opposite of my experience.

I went from a D300s kit with about $10k of lenses to Fuji. I had an X100s, then an X-E2, and now an X-Pro3.

The X-Pro3 especially is light, has excellent physical controls, and very much feels like a vintage Leica. It's what I'd consider an "art camera" -- not what I'd choose if I were shooting weddings regularly, but perfect for street photography, family stuff, and perfectly capable of higher-end commercial work if you're willing to put up with its quirks.

The quirks are the point, though.
by efreak | 2025-07-30 06:07:04+00:00
There's a website I use irregularly (I sign in maybe every other month) that doesn't use passwords, doesn't use sign in with X, etc. Instead, they have a form to enter an email address, and they send you a magic link to log in. Since it's a generic email field with no password prompt, my password manager doesn't offer to fill it in for me, and my browser helpfully offers every email address I've ever put into a form. I now have 7 accounts with this website; half of them were created to get a new API key, the other half were to submit feedback that I'll never get notified of responses to because I can't be signed into multiple accounts at once and they don't email me about comments.

I expect that by sometime next year I'll hit 10 accounts with them.
by gsf_emergency_2 | 2025-07-30 06:07:11+00:00
Q=Quadrature, I=In-phase

(As you point out not in the first couple pages, but waaay down)

he "explains" those

https://wirelesspi.com/two-birds-with-one-tone-i-q-signals-a...

Not trying to be charitable like furgot ... The wikipedia page is the first time I've seen authors go pro on the topic
by teiferer | 2025-07-30 06:07:58+00:00
I read GP comment as "there is no evidence that everything having a brain is conscious (and vice versa)", not as "the place where the individual's consciousness operates is the brain".

The former could be applied to whatever LLM is the hype of the day.

It's interesting though that the only consciousness that I'm sure of exists is my own. Anybody else's is just somehing I'm assuming. You can measure intelligence, but not consciousness.
by groby_b | 2025-07-30 06:09:29+00:00
It's not "tired" to see if something is actually relevant in context. LLMs do not exist as marvel-qua-se, their purpose is to offload human cognitive tasks.

As such, it's important if something is a commonly shared failure mode in both cases, or if it's LLM-specific.

Ad absurdum: LLMs have also rapid increases of error rates if you replace more than half of the text with "Great Expectations". That says nothing about LLMs, and everything about the study - and the comparison would highlight that.

No, this doesn't mean the paper should be ignored, but it does mean more rigor is necessary.
by BLKNSLVR | 2025-07-30 06:09:31+00:00
> “If you can’t show real traction for the AI tool we’re launching, maybe this role isn’t for you.”

If he's depending on a fresh graduate to generate "real traction" then maybe (probably?) his role isn't for him.

As far as I'm aware AI image generation tools are springing up all over. I don't particularly care about them, but I've played with maybe seven or eight, mostly sourced from "the 10 best image generating AIs" kinda lists.

What makes yours different from the pack?
by PaulRobinson | 2025-07-30 06:09:45+00:00
As somebody who has done both tech support, and lectured a couple of semesters at a business school on a technical topic... they're not that far removed from each other, it's just context and audience changes. The work is pretty similar.

So why not have tech support that teaches you, or a tutor that helps with you with a specific example problem you're having?

Providing you don't just rely on training data and can reduce hallucinations, this is the angle of attack that is likely the killer app some people are already seeing.

Vibe coding is nonsense because it's not teaching you to maintain and extend that application when the LLM runs out of steam. Use it to help you fix your problem in a way that you understand and can learn from? Rocket fuel to my mind. We're maybe not far away...
by hakfoo | 2025-07-30 06:09:45+00:00
I was always sort of curious how they determine which prototypes to go after-- it seems like some classes are much more widely produced than others. It seems like in WWII aircraft, Japanese and Soviet designs are underrepresented compared to US/UK/DE ones. Ship models seem aligned towards ones that sunk famously over ones that survived and were retired after long service.

With railway models, there's a selection bias because people tend to model a coherent scene. If you've decided to model Quebec in 1952, you probably can't find a way to fit in a British Rail class 66. But most other model hobbies don't have that restraint going on.
by bubblyworld | 2025-07-30 06:10:20+00:00
Yeah, solving this edge case properly can add a lot of complexity (your solution has the same problem, no? deletes would mess it up as would updates, technically). I've seen people using long-lived "idempotency tokens" point to an event log for this but it's a bit nuts. Definitely worth considering not solving it, which might be a more intuitive UX anyway (e.g. for leaderboards).
by jillesvangurp | 2025-07-30 06:11:32+00:00
I have a Pixel 6 Pro. I played a bit with it's raw format when I got it. It's fairly impressive; especially for night time photography. When that came out, both Apple and Google sourced their sensors from Sony. I think that's still the case. At the hardware level, there's not that much difference between cameras in different phones. Most of the differences are created in software.

The dng files that come out of my Pixel phone down sample from 50 mega pixels to 12.5. You can't access the original 50 mega pixels. So each pixel has information from 4 "real" pixels. That's fairly effective for getting rid of noise. I took some night shots with it and it holds up pretty well. It actually makes Google's night vision AI mode a bit less impressive because the starting point isn't that bad.

My other camera is a Fuji X-T30. The lenses and sensor are clearly better on that one if you look at the raw files. More detail, dynamic range, etc. But at night it's kind of weak (noise). And if you are into that, Fuji's film emulation produces pretty pleasing jpg files without a lot of work. I shoot raw so I tend to ignore that. But it's a somewhat fair comparison because in both cases there isn't much post processing. Except the Fuji isn't doing a lot of AI trickery and is just relying on a good results that come out of the camera and applying a prefab tone mapping that resembles what film used to do.

The difference of course is that with the Fuji, you are making lots of creative choices with focal range, depth of field of the lens (aperture), shutter speeds, and ISO while you are shooting. You don't really have that with a smart phone (though you can have some control). The iphone and pixel phones fake some of this stuff and some people like the portrait mode with the fake bokeh. Lens quality is amazing given the size of phones these days. But it's not the same as shooting with a proper lens and they do have some real physical limitations.

And if you shoot raw, you gain a lot of control over tone mapping etc. Not for everyone of course. But also not the end of the world with the right software. I use Darktable for this and if you dial that in properly, it's not actually a lot of work.

That being said, my pixel takes decent photos without a lot of effort and there is value in that. I have it with me by default and that is invaluable. I only use the Fuji a few times per year. But there's less art to using a smart phone. Point and tap on the button and hope for the best.
by hardwaresofton | 2025-07-30 06:12:05+00:00
Rust vs Go is IMO not even a reasonable discussion to have -- you really have to be careful on the axes for which you compare them for the thought exercise to make any sense.

If you want a productive backend language that developers can pick up quickly, write code in, and be productive relatively quickly and write low latency applications, Go is an easy winner.

If you want a systems language, then Rust is the only choice between those two. Rust is harder to pick up, but produces more correct and faster code, with obviously a much stronger type system.

They could be directly comparable, but usually only if your goal is as abstract as "I need a language to write my backend in". But you can see how that question is a very difficult one to pull meaning from generally.

> How often do we see "stackless coroutine" listed as advantage in Rust vs Go for network programming flamewars?

I'm just going to go out on a limb and say network programming is bar none more efficient in Rust. I could see C/C++ beating out Rust in that domain, but I would not expect Go to do so, especially if you're reaching for unsafe rust.

Again, it also depends on what you mean by "network programming", and whether development speed/ecosystem/etc are a concern.

To avoid the flamewars and stay on topic, it's one of those things that is just a fundamentally limiting choice -- most will never hit the limit (most apps really aren't going to do more than 1000RPS of meaningful requests), but if you do actually need the perf it's quite disappointing.

People are very annoyed with Rust for not having a blessed async solution in-tree, and while it's produced a ton of churn I think it was ultimately beneficial for reasons like this. You can do either one of these in Rust, the choice isn't made for you.

That said, the OP's suggestion seems to be adding virtual threads on rather than swapping out asyncio for virtual threads, so maybe there's a world where people just use what they want, and python can interop the two as necessary.
by Paradigma11 | 2025-07-30 06:12:12+00:00
I am pretty sure that this is filtered out. On a related note I think the whole autonomous agent metaphor is a net negative. It is a pure probabilistic token prediction function. You can run 100 in parallel, add or remove chat history as content to explore the output space. That is much more interesting and powerful than a single sad stateful clippy agent that one might act polite to.
by makerofthings | 2025-07-30 06:13:13+00:00
A lot of people in this thread seem to enjoy the taste of boot and are spending a lot of words trying to say the OSA isn't a big deal. A bit of a sad attitude for a forum called HackerNews. This is massive overreach by the government, we shouldn't have to ID ourselves to message friends on bluesky, read homebrew forums or, soon, use xbox voice chat. The government won't give up this power, it's clearly the thin end of the wedge.
by jauntywundrkind | 2025-07-30 06:13:56+00:00
This kind of checks out for me. But also, there have been decent protocols around this for a long time, that many clients & servers have implemented. From Multi-device in the excellent Modern XMPP:*

> XEP-0280: Message Carbons - for "live" synchronization of conversations between online devices. XEP-0313: Message Archive Management - for "catch-up" of messages that were exchanged while a device was offline

https://docs.modernxmpp.org/client/protocol/

The XEP-0313 spec dates back to 2012 which is less old than I expected, and that's only the 0.1. So, very fair point.

More generally, the above complaint was about the development experience of XMPP. I feel somewhat like complaining about XMPP being failed is well tread from a why consumers didnt adopt it view, that negative sentiment abounds & everyone is more than happy to cast blame as to why. I've seen a lot less complaints about the development experience, and felt like maybe there was some novel fruitful grounds that a more developer-centric view might have been able to open up.
by stolencode | 2025-07-30 06:14:06+00:00
Isn't the test taken only by students under the age of 12?

Meanwhile the model is trained on these specific types of problems, does not have an apparent time or resource limit, and does not have to take the test in a proctored environment.

It's D- work. Compared to a 12 year old, okay, maybe it's B+. Is this really the point you wanted to make?
by nessex | 2025-07-30 06:14:30+00:00
Sure, but if you insist it's like a tide you downplay the risk of the initial hit of the wavefronts and the potential for it to slam up the coast or a seawall becoming a larger local wave. And if you insist it's like a wave, you downplay the persistent risk of both follow-up waves and ongoing flooding that won't subside quickly.

So saying it's not waves is dangerous, and saying it's not a sea level rise is dangerous. It's not useful to try and delineate between a tsunami being one of the two when it's in reality an event that consists of both.

(Ignoring that a sea level rise and a long-wavelength wave are the same thing)
by theshrike79 | 2025-07-30 06:14:51+00:00
IMO it's the same in furniture.

There will always be people who know the difference and care about the difference. And are prepared to pay the premium for handcrafted furniture.

But the vast majority of people either won't care or don't know the difference - mostly because they've never experienced it. They just take it for grated that their IKEA cardboard stuff won't make it through a move and buy a new one.

And then there's the one person with the almost century old desk that was handmade from hardwood and is practically indestructible and fully repairable if something cracks.
by Idesmi | 2025-07-30 06:15:03+00:00
> I cannot understand why the European Commission wants to reduce our reliance on FAANG services, and at the same time they make Google Play a de facto standard

You'll be surprised, most of the time it's simple ignorance: the people making decisions don't know everything about everything. Hence democracy comes to rescue.

But the way the European Commission takes decisions is anti-democratic (secret draft documents, undisclosed lobbying, overlooking the role of the Parliament…)