MurphyA/hacker-news huggingface dataset:
by amluto | 2025-10-31 21:59:46+00:00
I’m not convinced that this can help in a meaningful way.

Fundamentally, if you have two coroutines (or cooperatively scheduled threads or whatever), and one of them holds a lock, and the other one is awaiting the lock, and you don’t schedule the first one, you’re stuck.

I wonder if there’s a form of structured concurrency that would help. If I create two futures and start both of them (in Rust this means polling each one once) but do not continue to poll both, then I’m sort of making a mistake.

So imagine a world where, to poll a future at all, I need to have a nursery, and the nursery is passed in from my task and down the call stack. When I create a future, I can pass in my nursery, but that future then gets an exclusive reference to my future until it’s complete or cancelled. If I want to create more than one future that are live concurrently, I need to create a FutureGroup (that gets an exclusive reference to my nursery) and that allows me to create multiple sub-nurseries that can be used to make futures but cannot be used to poll them — instead I poll the FutureGroup.

(I have yet to try using an async/await system or a reactor or anything of the sort that is not very easy to screw up. My current pet peeve is this pattern:

data = await thingy.read()

What if thingy.read() succeeds but I am cancelled? This gets nasty is most programming languages. Python: the docs on when I can get cancelled are almost nonexistent, and it’s not obviously possible to catch the CancelledError such that I still have data and can therefore save it somewhere so it’s not lost. Rust: what if thingy thinks it has returned the data but I’m never polled again? Maybe this can’t happen if I’m careful, but that requires more thought than I’m really happy with.)
by banashark | 2025-10-31 21:59:59+00:00
The main release note here is more stable async. I’m curious how folks using nim feel about the async situation.

One of the most recent opinions from the discord is:

“ we have async and asyncdispatch but its leaky and bug prone esp when used with threads and causes deep ownership issues, i prefer using taskman when possible but it leaves the IO problem yet unsolved ”

I’ve also been told to just use regular threads whenever possible.

Do others have more info or sentiments to share?
by jordanb | 2025-10-31 22:00:49+00:00
Prior to 2025, Affinity used a perpetual license model. In 2025, new owner Canva (which purchased. Serif in 2024) released a new version of Designer that integrates the functionality of Photo and Publisher into a singular application, and switched the program to a freemium model monetized by artificial intelligence features exclusive to Canva Pro subscribers.

I guess that's better than Adobe
by falleng0d | 2025-10-31 22:01:25+00:00
We may joke about it, but the fact is that it's releasing dumb ideas like this that you sometimes get masterpieces. Maybe this one is really just one of the bad ones, but eventually Elon will have some good ones just like he already has.

And a lot of us would be better off releasing our dumb ideas too. The world has a lot of issues and if all you do is talk down and don't try to fix anything yourself. Maybe it's time to get off the web a little and do something else.
by zahlman | 2025-10-31 22:01:38+00:00
> The biggest tool in the performance toolbox is stubbornness. Without it all the mechanical sympathy in the world will go unexploited.

The sympathy is also needed. Problems aren't found when people don't care, or consider the current performance acceptable.

> There’s about a factor of 3 improvement that can be made to most code after the profiler has given up. That probably means there are better profilers than could be written, but in 20 years of having them I’ve only seen 2 that tried.

It's hard for profilers to identify slowdowns that are due to the architecture. Making the function do less work to get its result feels different from determining that the function's result is unnecessary.
by mattfrommars | 2025-10-31 22:02:17+00:00
Thank you for the detail reply. I feel less overwhelmed now and sort of idea for next step to take. I've noticed Andrew NG deep learning specialization to be frequently mentioned along with Karpthy Zero To Hero free course.

I have toyed around free open source models, gemma3n, and running locally, etc.

As per project I did, it was to load up vector database and built a 'mini' agentic chat bot. Nothing fancy like fine tuning a model.

Ambitious project I've been thinking is to build an inference on top of established model, for example inference on deep seek model or llama in Python or Rust. But I run into self doubt since I don't have any formal ML background, so I'm not sure how I can pull it off.

I do keep an eye on trending github project, I'm amazed on project people make. My recent interest has been coding agent that operates within CLI and coding agent that work off git workspace.

This brings back a point I should have mentioned, since I don't have a picture, I am unable to prioritize on which step to take first and from there, branch off.
by mycoliza | 2025-10-31 22:02:40+00:00
Yeah, a coworker coming from Go asked a similar question about why Rust doesn't have something like the Go runtime's deadlock detector. Your comment is quite similar to the explanation I gave him.

Go, unlike Rust, does not really have a notion of intra-task concurrency; goroutines are the fundamental unit of concurrency and parallelism. So, the Go runtime can reason about dependencies between goroutines quite easily, since goroutines are the things which it is responsible for scheduling. The fact that channels are a language construct, rather than a library construct implemented in the language, is necessary for this too. In (async) Rust, on the other hand, tasks are the fundamental unit of parallelism, but not of concurrency; concurrency emerges from the composition of `Future`s, and a single task is a state machine which may execute any number of futures concurrently (but not in parallel), by polling them until they cannot proceed without waiting and then moving on to poll another future until it cannot proceed without waiting. But critically, this is not what the task scheduler sees; it interacts with these tasks as a single top-level `Future`, and is not able to look inside at the nested futures they are composed of.

This specific failure mode can actually only happen when multiple futures are polled concurrently but not in parallel within a single Tokio task. So, there is actually no way for the Tokio scheduler to have insight into this problem. You could imagine a deadlock detector in the Tokio runtime that operates on the task level, but it actually could never detect this problem, because when these operations execute in parallel, it actually cannot occur. In fact, one of the suggestions for how to avoid this issue is to select over spawned tasks rather than futures within the same task.
by 7952 | 2025-10-31 22:02:47+00:00
I think this approach makes sense for services with a small number of users relative to the data they are searching. That just isn't a good fit for a lot of hosted services. Think how much that TB's of data would cost on Algolia or similar services.

You have to store the data somehow anyway, and you have to retrieve some of it to service a query. If egress costs too much you could always change later to put the browser code on a server. Also it would presumably be possible to quantify the trade-off between processing the data client side and on the server.
by Matthias247 | 2025-10-31 22:03:35+00:00
As far as I remember from building these things with others within the async rust ecosystem (hey Eliza!) was that there was a certain tradeoff: if you wouldn’t be able to select on references, you couldn’t run into this issue. However you also wouldn’t be able run use select! in a while loop and try to acquire the same lock (or read from the same channel) without losing your position in the queue.

I fully agree that this and the cancellation issues discussed before can lead to surprising issues even to seasoned Rust experts. But I’m not sure what really can be improved under the main operating model of async rust (every future can be dropped).

But compared to working with callbacks the amount of surprising things is still rather low :)
by munificent | 2025-10-31 22:05:17+00:00
Here's an anecdote that might help answer. When my wife was pregnant with our first doctor, she started hemorrhaging spontaneously ten weeks before her due date. We rushed to the ER.

1. Shortly after, a doctor A came in, asked some questions, looked at the chart, and told us she was having the baby tonight. Holy shit our life is about to get crazy and we're going to be parents 2+ months early! He leaves.

2. Several hours later doctor B comes in. We ask about delivery. "Oh, no. You're not going to have the baby now. But you will have to be on bed rest until the due date." Jesus, my wife is going to have to quit her job.

4. Even more hours later, now the next morning, doctor C arrives. "OK, you're free to go home. No bed rest needed. Just let us know if anything else happens."

My general experience with doctors is that you get as many unique opinions as there are doctors in the room. This is not an indictment of the profession. Human bodies are insanely complex, there is way more variation between them than most people realize, and doctors are operating under very very limited time and information.

Having overlapping doctors would likely cause even more patient confusion and increase the risk conflicting treatments. Also, it would obviously double the cost of care.

(My wife and baby were fine. Partial abruption. Very scary and my daughter was born five weeks early, but no other significant problems.)
by zb3 | 2025-10-31 22:06:23+00:00
Well, I'd rather verify myself with the government identity than accept a stock OS that literally woke me up with a fake message promoting Gemini despite me spending almost 2 hours turning every possible privacy-invasive setting off.

To me, the attention to these verification changes seems misplaced. We need to defend the ability to unlock the bootloader, pressure Google to revive AOSP and then encourage people to switch to a more user-friendly OS.

You're already unable to install what you want on a stock OS due to Android permission model treating you as a third-class citizen, after Google and OEMs.
by godelski | 2025-10-31 22:06:36+00:00
> where that 1% is worth any hassle

You'll need context to answer your question, but yes there are cases.

Let's say you have a process that takes 100hrs to run and costs $1k/hr. You save an hour and $1k every time you run the process. You're going to save quite a bit. You don't just save the time to run the process, you save literal time and everything that that costs (customers, engineering time, support time, etc).

Let's say you have a process that takes 100ns and similarly costs $1k/hr. You now run in 99ns. Running the process 36 million times is going to be insignificant. In this setting even a 50% optimization probably isn't worthwhile (unless you're a high frequency trader or something)

This is where the saying "premature optimization is the root of all evil" comes from! The "premature" part is often disregarded and the rest of the context goes with it. Here's more context to Knuth's quote[0].

There is no doubt that the holy grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified.

Knuth said: "Get a fucking profiler and make sure that you're optimizing the right thing". He did NOT say "don't optimize".

So yes, there are plenty of times where that optimization will be worthwhile. The percentages don't mean anything without the context. Your job as a programmer is to determine that context. And not just in the scope of your program, but in the scope of the environment you expect a user to be running on. (i.e. their computer probably isn't entirely dedicated to your program)

[0] https://dl.acm.org/doi/10.1145/356635.356640 (alt) https://sci-hub.se/10.1145/356635.356640
by raggi | 2025-10-31 22:06:55+00:00
The language team tends to look at these kinds of challenges and drive them to a root cause, which spins off a tree of work to adjust the core language to support what's required by the higher level pieces, once that work is done then the higher level projects are unblocked (example: RPIT for async drop).

That's not always super visible if you're not following the working groups or in contact with folks working on the stuff. It's entirely fair that they're prioritizing getting work done than explaining low level language challenges to everyone everywhere.

I think you're seeing a lack of data and trying to use that as a justification to fit a story that you like, more than seeing data that is derivative of the story that you like. Of course some people were horribly disrupted by the changes, but language usage also expanded substantially during and since that time, and there are many team members employed by many other organizations, and many independents too.

And there are more docs, anyway:

https://rust-lang.github.io/rust-project-goals/2024h2/async.... https://rust-lang.github.io/rust-project-goals/2025h1/async.... https://rust-lang.github.io/rust-project-goals/2025h2/field-... https://rust-lang.github.io/rust-project-goals/2025h2/evolvi... https://rust-lang.github.io/rust-project-goals/2025h2/goals....
by DracheZahn | 2025-10-31 22:07:09+00:00
This is the best advice for long-term security. Take advantage of a ROTH if you can. Regardless of the market or your income, contribute now. Take advantage of the Rule of 72. Double your money every few years. With every raise, add more until you reach your maximum contribution. When you turn 50, raise it to the new maximum. When YOU want to retire, you will have a sizable savings.
by bobbylarrybobby | 2025-10-31 22:07:51+00:00
I wonder whether they're simply priming Claude to produce this introspective-looking output. They say “do you detect anything” and then Claude says “I detect the concept of xyz”. Could it not be the case that Claude was ready to output xyz on its own (e.g. write some text in all caps) but knowing it's being asked to detect something, it simply does “detect? + all caps = “I detect all caps””.
by heavyset_go | 2025-10-31 22:08:12+00:00
I imagine running ARM code on ARM cores would be more efficient than running them on x86 with or without compatibility extensions, and vice versa.

Instead of always playing catch-up platform-wise for compatibility, just embed the ISA platforms into the chips themselves.

As for why: because I'm not abandoning x86 any time soon and this would ease ARM transition. I also think it would set a foundation for hardware-based secure virtualization across platforms.
by LexGray | 2025-10-31 22:08:19+00:00
Perhaps bad taste, but bots could also be legitimately purposely violating the most private or traumatizing moments a vulnerable person has in any exploitative way it cares to. I am not sure using bad taste is enough of an excuse to not discuss the issue as many people do in fact use the internet for sexual things. If anything consent should be MORE important because it is easier to document and verify.

A vast hoard of personal information exists and most of it never had or will have proper consent, knowledge, or protection.
by vrinsd | 2025-10-31 22:08:48+00:00
I understand why someone might this this is a pay issue, but it's goes beyond that.

Culturually, doing something "well"(quality oriented, mindful of end-users) vs. "got it done" (transaction, pragmatic way of looking at things) is the heart of why outsourcing to many different geographical areas (India included) often results in something different than expected.

Also condemning every one in one part of the world as thinking one way is certainly not fair or true, but there are definitely unmistakable trends.
by tomwheeler | 2025-10-31 22:09:02+00:00
> selecting text is scarcely possible

I find non-selectable text maddening, but I recently found an macOS app called TextSniper that restores my control. It lets you select an area with the mouse (as you would when taking a screenshot) and it then OCRs the text and puts it into your clipboard. It almost makes Google Analytics usable again.
by octoberfranklin | 2025-10-31 22:09:13+00:00
For anybody who wants to cut to the chase, it's this:

> The behavior of tokio::select! is to poll all branches' futures only until one of them returns `Ready`. At that point, it drops the other branches' futures and only runs the body of the branch that’s ready.

This is, unfortunately, doing what it's supposed to do: acting as a footgun.

The design of tokio::select!() implicitly assumes it can cancel tasks cleanly by simply dropping them. We learned the hard way back in the Java days that you cannot kill threads cleanly all the time. Unsurprisingly, the same thing is true for async tasks. But I guess every generation of programmers has to re-learn this lesson. Because, you know, actually learning from history would be too easy.

Unfortunately there are a bunch of footguns in tokio (and async-std too). The state-machine transformation inside rustc is a thing of beauty, but the libraries and APIs layered on top of that should have been iterated many more times before being rolled out into widespread use.
by rkagerer | 2025-10-31 22:09:22+00:00
I've been trying to make a UserDebug build for the last few days by following the official instructions at https://grapheneos.org/build, and am running into some trouble which I suspect are due to minor steps in the documentation that are missing or incorrect.

Is it possible to get some help on this? Posted some messages to the #general and #development channels on Discord (you mentioned in your very helpful comment at https://news.ycombinator.com/item?id=42536302 that's the go-to for support) but am not getting any response. I'd even be happy to make a fat donation or pay for some support here.

Also out of curiosity, have you guys considered providing an official release that is configured this way, perhaps gated behind a giant "Proceed at your own risk" banner? Is your reasoning here influenced by a perception that providing root access without enough friction might weaken your bid for Play Integrity recognition or your chances of individual app developers like banks treating your OS on equally trusted footing as Google's?
by j1elo | 2025-10-31 22:10:11+00:00
> Notably, the Pixel 10 series is moving away from physical SIM cards.

Is it? I hadn't followed news of the new Pixels.

I don't like the idea of modernizing this and going full eSIM. It will introduce a lot of new friction, somehow I don't doubt it. Just now arrived to Mexico for a quick trip and grabbed a prepaid SIM from a 7-11 in the airport. All quick and simple. I doubt things would be so seamless when not having a SIM tray in the phone. Having to go through an official process to register a new card, ID oneself, hope to not have any incompatibility with the eSIM slots in your phone (admittedly I don't know how this works)... vs. just paying MXN100 and leave the store with a ready to use number.
by Bender | 2025-10-31 22:10:14+00:00
The first time I heard discussion of this with no credible reasons I stocked up on many TP-Link layer 2 switches and several TP-Link access points. I have them all behind a firewall and I only allow the AP's to talk directly outbound when I choose to update the firmware. I have yet to see it attempt to dial home without my prompting it to and I have always been able to download firmware updates. The reason I stocked up is that TP-Link thus far have had the best result negotiating and maintaining proper speed and duplex on long cable runs. I have been quite happy with them. If A USA based company can make something as reliable I will switch to them assuming they have been brutally tested by many others with very custom setups. I have tested many AP's and switches over the years.

Am I the only person here that puts the AP behind a dedicated firewall with its own dedicated LAN/Subnet?
by renegat0x0 | 2025-10-31 22:11:37+00:00
Most web scrapers, even if illegal, are for... business. So they scrape amazon, or shops. So yeah. Most unwanted traffic is from big tech, or bad actors trying to sniff vulnerabilities.

I know a thing or two about web scraping.

There are sometimes status codes 404 for protection, so that you skip this site, so my crawler tries, as a hammer, several of faster crawling methods (curlcffi).

Zip bombs are also not for me. Reading header content length is enough to not read the page/file. I provide byte limit to check if response is not too big for me. For other cases reading timeout is enough.

Oh, and did you know that requests timeout is not really timeout a timeout for page read? So server can spoonfeed you bytes, one after another, and there will be no timeout.

That is why I created my own crawling system to mitigate these problems, and have one consistent mean of running selenium.

https://github.com/rumca-js/crawler-buddy

Based on library

https://github.com/rumca-js/webtoolkit
by Negitivefrags | 2025-10-31 22:11:58+00:00
I think the biggest tool is higher expectations. Most programmers really haven't come to grips with the idea that computers are fast.

If you see a database query that takes 1 hour to run, and only touches a few gb of data, you should be thinking "Well nvme bandwidth is multiple gigabytes per second, why can't it run in 1 second or less?"

The idea that anyone would accept a request to a website taking longer than 30ms, (the time it takes for a game to render it's entire world including both the CPU and GPU parts at 60fps) is insane, and nobody should really accept it, but we commonly do.
by verdverm | 2025-10-31 22:12:05+00:00
It take issue with that stat. If you go to all the PDSes and ask for all the accounts, you will reach a total several million lower. This count does not seem to account for takedowns and self-deletions. Even taking those into account, you still don't reach the numbers this site shows

Also, I have 5 accounts, so "users" is also inaccurate

If you want to reproduce my calculation, my tooling is here: https://github.com/blebbit/atmunge
by tomwheeler | 2025-10-31 22:13:10+00:00
> I vaguely remember, back in 2010, when I wrote my app, you couldn't style a button consistently across all browsers. They were grey boxes in firebox, or used other OS standard styling.

I'm sure I'll trigger a lot of designers by saying this, but I'm probably not alone in valuing basic usability FAR above styling. I much rather have an ugly button that looks like 90's era Tcl/TK than something pretty that doesn't behave like I expect it to.
by kragen | 2025-10-31 22:13:17+00:00
This is far from true in my experience. I'm no Lisp hater (I wrote a self-compiling compiler in Scheme) but different syntaxes have dramatically different degrees of familiarity, like Latin letters and Cyrillic. How long do you think it would take you to learn to read phonetically in Cyrillic as fast as you do in the Latin script? It takes the humans months or years, if they ever arrive. But, also, some notations are more usable than others, even for experts, just as with other kinds of user interfaces. Flat is better than nested, simple is better than complex, complex is better than complicated, Perl and MUMPS are unnecessarily error-prone, etc.