MurphyA/hacker-news huggingface dataset:
by Veserv | 2025-10-31 22:13:20+00:00
I thought Rust async is a colored stackless coroutine model and thus it would be unsafe to continue execution of previously executing async functions.

To explain, generally speaking, stackless coroutine async only need coloring because they are actually “independent stack”less coroutines. What they actually do is that they share the stack for their local state. This forces async function execution to proceed in LIFO order so you do not blow away the stack of the async function executing immediately after which demands state machine transforms to be safe. This is why you need coloring unlike stackful coroutine models which can execute, yield, and complete in arbitrary order since their local state is preserved in a safe location.
by strgcmc | 2025-10-31 22:14:10+00:00
In such scenarios (data engineering / DS / analytics is my personal background), I have learned not to underestimate the value of, explicitly declaring within Team X, that person X1 is dedicated to line L1, person X2 is dedicated to line L2, etc. (aka similar to your last line about embedding a person with that line of business).

In theory, it doesn't actually "change" anything, because Team X is still stuck supporting exactly the same number of dependencies + the same volume and types of requests.

But the benefit of explicit >>> implicit, the clarity/certainty of knowing who-to-go-to-for-what, the avoidance of context switching + the ability to develop expertise/comfort in a particular domain (as opposed to the team trying to uphold a fantasy of fungibility or that anyone can take up any piece of work at any time...), and also the specificity by which you can eventually say, "hey I need to hire more people on Team X, because you need my team for 4 projects but I only have 3 people..." -- all of that has turned out to be surprisingly valuable.

Another way to say it is -- for Team X to be stretched like that initial state, is probably dysfunctional, and in a terminally-fatal sense, but it's a slow kind of decay/death. Rather than pretending it can work, pretending you can virtualize the work across people (as if people were hyper-threads in a CPU core, effortlessly switching tasks)... instead by making it discrete/concrete/explicit, by nominating who-is-going-to-work-on-what-for-who, I have learned that this is actually a form of escalation, of forcing the dysfunction to the surface, and forcing the organization to confront a sink-or-swim moment sooner than it otherwise would have (vs if you just kept limping on, kept trying to pretend you can stay on top of the muddled mess of requests that keep coming in, and you're just stuck treading water and drowning slowly).

---

Of course, taking an accelerationist stance is itself risky, and those risks need to be managed. But for example, if the reaction to such a plan is something like, "okay, you've created clarity, but what happens if person X1 goes on vacation/gets-hit-by-bus, then L1 will get no support, right?"... That is the entire purpose/benefit of escalating/accelerating!

In other words, Team X always had problems, but they were hidden beneath a layer of obfuscation due to the way work was being spread around implicitly... it's actually a huge improvement, if you've transformed a murky/unnameable problem into something as crispy and quantifiable as a bus-factor=1 problem (which almost everyone understands more easily/intuitively).

---

Maybe someday Team X could turn itself into a self-service platform, or a "X-as-a-service" offering, where the dependent teams do not need to have you work with or for them, but rather just consume your outputs, your service(s)/product(s), etc. at arms-length. So you probably don't always want to stay in this embedded or explicit "allocation" model.
by tadfisher | 2025-10-31 22:14:35+00:00
Nothing should rely on how store paths are named, ever. Like, there is actually no reason to know that hash 1234abc is a certain output of derivation xyz-12.1.0. The contents of the store can be garbage-collected at any point. So you actively do not want things outside the Nix store (or managed by NixOS tools, or Nix-aware tools) referencing paths in /nix/store.

If you do something like write a config file that references /nix/store/1234abc-xyz-12.1.0/bin/xyz, that config file will break the next time you update the derivation that produces that path. Again, this makes knowing what things are in the store completely pointless unless you are writing Nix-aware tooling or debugging, in which case there are tools to show you what path your derivation produced. But you should never need to do the opposite, which is to resolve which derivation produced a path in /nix/store/.

The Windows Store problem is completely orthogonal; paths in /nix/store are not "installed" on your system, they are derivations or outputs of Nix derivations. NixOS "installs" things by adding some of these to your PATH in a shell script that is also a derivation output in /nix/store.
by michaelt | 2025-10-31 22:14:35+00:00
For one thing, with printed passports border officials have to recognise all the anti-fraud features on all the passports issued worldwide in the past 10 years.

Quick, what security image on a valid UK passport - a thistle, a daffodil, a rose, a clover, a coat of arms (but not the same coat of arms as on the front cover), a map of the UK, a harlequin pattern, a crown, a lighthouse, a pair of bird wings, William Shakespeare, an oak leaf, a compass, a marine chronometer, the letters UK, the words United Kingdom, a Bermuda-rigged boat, a square-rigged boat, a steamship, or the holder's birth date?

It's a trick question, you'll find all of them; they changed the passport once for brexit, and again after the queen's death. And that's just one document from one country. Far simpler to just hold it to the reader and get a beep.

For another thing, if you're worried about bribed officials - it's much harder to bribe airport border officials if they're required to scan every passport into a computer, and match it against the airline's passenger list.
by martinvonz | 2025-10-31 22:14:41+00:00
> it always seem to amount to that people bother to read the manual and understand the tool AFTER they used a VCS for years.

Perhaps, but I don't think that's true for me (or for Steve). I've contributed something like 90 patches to Git itself (mostly to the rebase code). To be fair, that was a while ago.

My impression is actually that many people who disagree with the sentiment that jj is much easier to use seem to have not read its manual :) Some of them seem to have not even tried it. So, the way it looks to me, it's usually the people who argue for jj who have a better understanding of the differences between the two tools.

Have you tried jj yourself and/or have you read some of the documentation?
by sothatsit | 2025-10-31 22:15:08+00:00
This is clearly false. LLMs being able to multiply large numbers is the clear example to me that there is more than just memorisation going on. They cannot just memorise the answers to multipling huge numbers like they do.

That's not to mention that these programming competition problems are designed to be novel. They are as novel as the competition designers can get while sticking to the bounds of the competition. This is clearly not stochastic parrot behaviour.

Additionally, them falling over in large codebases is not evidence that they cannot reason over smaller well-defined problems. It is just evidence that their reasoning has limits, which should not be surprising to anyone. Humans also have limits in our reasoning. That does not mean we do not reason.
by debarshri | 2025-10-31 22:16:19+00:00
This is a pessimistic comment.

I'm a cofounder of a data and identity security startup operating specifically in APAC. Data security in india a joke.

I would argue even with DPDPA, RBI C-Site and cyber resilience framework from SEBI, it is just going to not happen here.

The list PAN card the blog is taking about is probably already leaked by some other services.

The recent flipkart cash on delivery scams [1] are example of how your personal information is just out there in wild in india, open for exploitation.

There are lot of who do security in good faith (often driven by compliance) and lot of them are our customers too but I hope to see rest of indian tech ecosystem take security seriously.

[1] https://www.reddit.com/r/FuckFlipkart/comments/1hhrw9w/what_...
by generationP | 2025-10-31 22:17:06+00:00
Wondering if the project will get better from the pushback or will just be folded like one of Elon's many ADHD experiments. In a sense, encyclopedias should be easy for LLMs: they are meant to survey and summarize well-documented material rather than contain novel insights; they are often imprecise and muddled already (look at https://en.wikipedia.org/wiki/Binary_tree and see how many conventions coexist without an explanation of their differences; it used to be worse a few years ago); the writing style is pretty much that of GPT-5. But the problem type of "summarize a biased source and try to remove the bias" isn't among the ones I've seen LLMs being tested for, and this is what Elon's project lives and dies by.

If I were doing a project like this, I would hire a few dozen topical experts to go over the WP articles relevant to their fields and comment on their biases rather than waste their time rewriting the articles from scratch. The results can then be published as a study, and can probably be used to shame the WP into cleaning their shit up, without needlessly duplicating the 90% of the work that it has been doing well.
by HeyLaughingBoy | 2025-10-31 22:17:17+00:00
Yes, but often the "business priorities" get so screwed up that people's needs go unmet, and the business ends up wasting money as a result.

My best example was a conversation I had with one of the scientists at my job when she mentioned that she had people spending hours every day generating reports from data our instruments produced. I pointed out that with the code we had it would be simple to generate the reports automatically.

Her response that she had asked repeatedly for a developer to be assigned to the task, but she kept being pushed away because it was low priority.

I couldn't just change the codebase on my own (it was for a medical device), but it was easy enough to spend a lazy afternoon writing a tool to consume the output logs from the device and generate the reports that she needed. That's it: about 4 hours of work and produced something this person had asked for a year prior, and that people were already spending hours each day doing!

The people in charge of vetting requests never even bothered to ask a developer to estimate the task. They just heard that there was a work around, so it immediately became "low priority."
by user205738 | 2025-10-31 22:17:37+00:00
These are just words, excuses that hide the fact that they illegally stole funds that did not belong to them.

Can I read more about the seizure of German bank accounts? As far as I know, they (USA) continued to sponsor Germany until 1944. (through various branches.)

Some Swiss banks serviced Nazi accounts until 2020 and did not see any problems in this.

A tit for tat would have been Iraq had seized American assets in response to the US invasion and the theft of Iraq's gold assets.

Remind me, when did Russia invade the USA or the EU?)
by seanw444 | 2025-10-31 22:19:00+00:00
I wish for both to succeed. I'm more of a Nim guy, but it's nice that there is a modernized C-like alternative to C gaining traction.

My biggest complaint about both is the lack of built-in run-time polymorphism. Rust gets you comptime and runtime polymorphism in one complete package. Nim makes use of shallow inheritance, which I find hacky, because it only lets you go one level deep. And Zig's stdlib makes it the norm to construct vtables manually, which is absolutely grotesque in my opinion. Why are we manually creating vtables in a "modern" language in 2025?
by teiferer | 2025-10-31 22:20:13+00:00
Down in the recursion example, the model outputs:

> it feels like an external activation rather than an emergent property of my usual comprehention process.

Isn't that highly sus? It uses exactly the terminology used in the article, "external activation". There are hundreds of distinct ways to express this "sensation". And it uses the exact same term as the article's author use? I find that highly suspicious, something fishy is going on.
by mlmonkey | 2025-10-31 22:20:31+00:00
Believe it or not, me (not white, did not grow up in the West, had the faintest clue about Nazism) used to do what you would consider a "Nazi salute" when I'd see friends and wave to them from a distance. I don't know how I picked that up but it happened.

I'm not saying that Musk is doing the same; but that one can be charitable and say he probably did not mean that. I mean, what does he stand to gain from doing so? He's a businessman.
by octoberfranklin | 2025-10-31 22:20:39+00:00
> 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.

No, just have select!() on a bunch of owned Futures return the futures that weren't selected instead of dropping them. Then you don't lose state. Yes, this is awkward, but it's the only logically coherent way. There is probably some macro voodoo that makes it ergonomic. But even this doesn't fix the root cause because dropping an owned Future isn't guaranteed to cancel it cleanly.

For the real root cause: https://news.ycombinator.com/item?id=45777234
by bawolff | 2025-10-31 22:20:53+00:00
I think there is a problem sometimes that "debunkers" are often more interested in scoring points with secondary audiences (i.e. people who already agree with them) than actually convincing the people who believe the misinformation.

Most people who believe bullshit were convinced by something. It might not have been fully rational but there is usually a kernel of something there that triggered that belief. They also probably have heard at least the surface level version of the oppising argument at some point before. Too many debunkers just reiterate the surface argument without engaging with whatever is convincing their opponent. Then when it doesn't land they complain their opponent is brainwashed. Which sometimes might even be true, but sometimes their argument just misses the point of why their opponent believes what they do.
by austinjp | 2025-10-31 22:20:59+00:00
> Araq will state his personal & honest opinions, which may come off as abrasive or "un-welcoming" in your opinion. I don't agree with everything he says but that's OK.

Nope. This is a sop, an equivalent to the non-apology "I'm sorry you took what I said so badly".

Aggression masquerading as "honesty" has no place in any organisation that wants to be taken seriously.

It's most certainly not "OK" when Andreas' personal opinions are expressed in ad-hominem attacks.

Nim unfortunately has a toxic Dictator at the top, and his subordinates defend his behaviours. While this continues nobody should take Nim seriously.
by zbentley | 2025-10-31 22:22:28+00:00
> a native stack [is] just a form of memory allocator

There is a lot riding on that “just”. Hardware stacks are very, very unlike heap memory allocators in pretty much every possible way other than “both systems provide access to memory.”

Tons and tons of embedded code assumes the stack is, indeed, a hardware stack. It’s far from trivial to make that code “just use a dummy/static allocator with the same api as a heap”; that code may not be in Rust, and it’s ubiquitous for embedded code to not be written with abstractions in front of its allocator—why would it do otherwise, given that tons of embedded code was written for a specific compiler+hardware combination with a specific (and often automatic or compiler-assisted) stack memory management scheme? That’s a bit like complaining that a specific device driver doesn’t use a device-agnostic abstraction.
by treyd | 2025-10-31 22:23:47+00:00
> thus it would be unsafe to continue execution of previously executing async functions.

There's more nuance than this. You can keep polling futures as often as you want. When an async fn gets converted into the state machine, yielding is just expressed as the poll fn returning as not ready.

So it is actually possible for "a little bit" of work to happen, although that's limited and gets tricky because the way wakers work ensure that normally futures only get polled by the runtime when there's actually work for them to do.
by tbirdny | 2025-10-31 22:24:28+00:00
I wish it took 2 hours. For me it's spend 2 hours shopping for the right part, finding it for a good price, and ordering it. Then spend an hour watching youtube videos for how to do it. Then spend 4 hours gathering the right tools, getting the car jacked, tires off, etc., then put everything away, and clean up. That's the best case. I could get the wrong part, my car looks different than the videos, I do it wrong, or break something. I recently replaced my front brakes. I maybe saved $400. I'm proud of myself. I kind of enjoyed it, but it's hard to justify.
by mycoliza | 2025-10-31 22:24:45+00:00
Indeed, you are correct (and hi Matthias!). After we got to the bottom of this deadlock, my coworkers and I had one of our characteristic "how could we have prevented this?" conversations, and reached the somewhat sad conclusion that actually, there was basically nothing we could easily blame for this. All the Tokio primitives involved were working precisely as they were supposed to. The only thing that would have prevented this without completely re-designing Rust's async from the ground up would be to ban the use of `&mut future`s in `select!`...but that eliminates a lot of correct code, too. Not being able to do that would make it pretty hard to express a lot of things that many applications might reasonably want to express, as you described. I discussed this a bit in this comment[1] as well.

On the other hand, it also wasn't our coworker who had written the code where we found the bug who was to blame, either. It wasn't a case of sloppy programming; he had done everything correctly and put the pieces together the way you were supposed to. All the pieces worked as they were supposed to, and his code seemed to be using them correctly, but the interaction of these pieces resulted in a deadlock that it would have been very difficult for him to anticipate.

So, our conclusion was, wow, this just kind of sucks. Not an indictment of async Rust as a whole, but an unfortunate emergent behavior arising from an interaction of individually well-designed pieces. Just something you gotta watch out for, I guess. And that's pretty sad to have to admit.

[1] https://news.ycombinator.com/item?id=45776868
by 1718627440 | 2025-10-31 22:24:50+00:00
I wanted, but it didn't compile due to needing a newer Rust compiler, than is available in my Distro. And the tutorials I found told me to run the equivalent of curl|bash, which I will not do. I don't felt like learning a new language/ecosystem just to try out another VCS, so I said, it's not worth it, I wait until it is available in my distro.

So actually no, and you have a point. :-)

I often just read "this is hard in Git" and think isn't this just this command? JJ has some nice features, but what appeals to me seems to not to be that hard to add to Git, so I will just wait a bit.
by judah | 2025-10-31 22:24:57+00:00
The ADL, the left-wing Jewish human rights group not aligned with Musk in the slightest, called out that Musk's gesture was merely an awkward salutation, not a Nazi seig heil[0].

[0]: https://www.jta.org/2025/01/21/politics/how-did-the-adl-conc...
by elchananHaas | 2025-10-31 22:25:25+00:00
My view of this is that its closer to the basic 2 lock Deadlock.

Thread 1 acquires A. Thread 2 acquires B. Thread 1 tries to acquire B. Thread 2 tries to acquire A.

In this case, the role "A" is being played by the front of the Mutex's lock queue. Role "B" is being played by the Tokio's actively executed task.

Based on this understanding, I agree that the surprising behavior is due to Tokio's Mutex/Lock Queue implementation. If this was an OS Mutex, and a thread waiting for the Mutex can't wake for some reason, the OS can wake a different thread waiting for that Mutex. I think the difficulty in this approach has to do with how Rust's async is implemented. My guess is the algorithm for releasing a lock goes something like this:

1. Pop the head of the wait queue. 2. Poll the top level tokio::spawn'ed task of the Future that is holding the Mutex.

What you want is something like this

For each Future in the wait queue (Front to Back): Poll the Future. If Success - Break ???Something if everything fails???

The reason this doesn't work has to do with how futures compose. Futures compile to states within a state machine. What happens when a future polled within the wait queue completes? How is control flow handed back to the caller?

I guess you might be able to have some fallback that polls the futures independently then polls the top level future to try and get things unstuck. But this could cause confusing behavior where futures are being polled even though no code path within your code is await'ing them. Maybe this is better though?
by hitekker | 2025-10-31 22:25:32+00:00
Skimming through, this document feels thorough and transparent. Clearly, a hard lesson learned. The footnotes, in particular, caught my eye https://rfd.shared.oxide.computer/rfd/397#_external_referenc...

> Why does this situation suck? It’s clear that many of us haven’t been aware of cancellation safety and it seems likely there are many cancellation issues all over Omicron. It’s awfully stressful to find out while we’re working so hard to ship a product ASAP that we have some unknown number of arbitrarily bad bugs that we cannot easily even find. It’s also frustrating that this feels just like the memory safety issues in C that we adopted Rust to get away from: there’s some dynamic property that the programmer is responsible for guaranteeing, the compiler is unable to provide any help with it, the failure mode for getting it wrong is often undebuggable (by construction, the program has not done something it should have, so it’s not like there’s a log message or residual state you could see in a debugger or console), and the failure mode for getting it wrong can be arbitrarily damaging (crashes, hangs, data corruption, you name it). Add on that this behavior is apparently mostly undocumented outside of one macro in one (popular) crate in the async/await ecosystem and yeah, this is frustrating. This feels antithetical to what many of us understood to be a core principle of Rust, that we avoid such insidious runtime behavior by forcing the programmer to demonstrate at compile-time that the code is well-formed
Ask HN: Why I rarely see game dev startup here?
by blindprogrammer | 2025-10-31 22:25:41+00:00
Do investors despise game development companies, and do you have to go solo? If so, I would have expected to see at least one on Show HN. Or maybe I missed it—definitely not as popular as other apps.

Also, why haven’t LLM wrappers penetrated this sector? Is it because OpenAI and other “parasites” haven’t had the opportunity to access source code to build their wholesale theft, so they don’t have the code to instruct you to build games? Or maybe there are a lot, and I just missed them.
by PaulDavisThe1st | 2025-10-31 22:25:43+00:00
Wikipedia clearly states that its purpose is to catalog knowledge/information that has been collected and published elsewhere. If you do not provide adequate citations to what are considered reputable sources, Wikipedia will reject your work.

It happened to me a number of times before I came to understand the Wikipedia model. They are not interested in your analysis, they are interested in statements that reference other inspectable "reputable" analyses.