MurphyA/hacker-news huggingface dataset:
by jacobgkau | 2025-10-03 21:34:30+00:00
> I literally never said that.

The person you replied to said, "democrats will push us in 1984 dystopia where they force you to accept that reality is what they tell you..."

You replied with, "Which reality is that? The real reality?"

So, yes, you "literally" did. You "literally" argued that "the reality Democrats tell you" is "the real reality," which also strongly suggests your political background. If that was just some kind of joke that you're now unable to stand behind, maybe you should think harder before you quip next time.

But it doesn't seem like it was just a joke. It seems like you're deluded enough to continue arguing that, from a purely "scientific" and "non-political" standpoint, Democrats never make false statements (and hence "the reality they tell you" is "the real reality"), despite there clearly being examples to the contrary.
by g-mork | 2025-10-03 21:34:41+00:00
The EMV standard has long supported an offline transaction flow. AFAIK it was the default almost everywhere in Finland circa 2011, contactless there was almost always instantaneous. Digging into why that was compared to the invariable wait when using contactless in the UK revealed this flow.

The card has a variety of risk counters on it that allow it to securely decide whether an offline transaction can proceed, at least some of which are also exposed to the terminal which can have its own separate policy. I imagine internally the banks and payment gateways have a huge variety of internal related tuneables.
by daneel_w | 2025-10-03 21:35:29+00:00
> "It's usually not said out loud, but cash is often considered to be dirty and criminal ..."

Are you sure this isn't impression you've gotten from isolated reactions involving a small number of individuals, perhaps just a single individual? I can't relate to the sentiment at all, having lived here for just over three decades and experiencing the popularity shift from cash to debit card. I can, in fact, not recall a single time ever that someone has divulged the opinion that they consider cash "dirty and criminal".

More than anything else the Swede's favor of debit card is the convenience. Second to that I would say is the security of not immediately losing funds if you misplace the card or it being stolen - it feels less risky carrying a debit card, in particular if you're the type who prefers having more than a few "tens" on you in case you'd need or want to buy something.
by segmondy | 2025-10-03 21:35:41+00:00
They don't want you on there, they need your silence. Your posting about injustice gives them great fear. They don't want your unsolicited commentary on state of affairs. You are a friend only if you boost their propaganda. So yes, go hide away and say nothing and pretend the world is normal, you will eventually have to deal with it in the real world.
by kkfx | 2025-10-03 21:36:18+00:00
Personally, I dream of an open-hardware, FLOSS wallet, also usable on POS like a bank smart card, confirming crypto transactions like legacy/traditional ones on its own display.

Internally, the signature part isolated like a smart-card, "embedded signature" hardware as a measure against double (multiple) spending, and reasonable limits on offline transactions with both parties offline (e.g., €10k/month).

The "embedded signature" hardware part is a bit vague because technologically it's not clear how to do something like that in a "secure enough" way, but it's a necessary part and the limit somewhat lowers the risk.

For use: mounted as a smartwatch or a pendant with a retractable lanyard, like ski-pass holders.
by pornel | 2025-10-03 21:36:31+00:00
"Cancel correctness" makes a lot of sense, because it puts the cancellation in some context.

I don't like the "cancel safety" term. Not only it's unrelated to the Rust's concept of safety, it's also unnecessarily judgemental.

Safe/unsafe implies there's a better or worse behavior, but what is desirable for cancellation to do is highly context-dependent.

Futures awaiting spawned tasks are called "cancellation safe", because they won't stop the task when dropped. But that's not an inherently safe behavior – leaving tasks running after their spawner has been cancelled could be a bug: piling up work that won't be used, and even interfering with the rest of the program by keeping locks locked or ports used. OTOH a spawn handle that stops the task when dropped would be called "cancellation unsafe", despite being a very useful construct specifically for propagating cleanup to dependent tasks.
by femiagbabiaka | 2025-10-03 21:38:03+00:00
The distinction between public and private is obvious to the initiated, but probably not to everyone. e.g. https://www.kenklippenstein.com/p/charlie-kirk-assassination...

With the right sorts of access given by companies seeking to avoid the ire of the administration, I'm pretty sure even private profiles could be considered to be public.
by dzaima | 2025-10-03 21:38:20+00:00
"3R1W integer pipeline" is kinda ambiguous; I think it'd be extremely-stupid for any core to have all their ALUs be 3R. Much more sane is having ~half be such (if even that), and the rest at 2R.

Or, better yet, have the 3R extra port come from some of the 2R being split up; e.g. for a block of 3×2R1W ALUs, be able to split one up for its read ports, reusing it as 2×3R1W when needed, thereby being able to do 3R1W at 66% the throughput of 2R1W without any extra register ports (i.e. 1.3x throughput benefit of 3R1W over two 2R1W instrs). Probably has some extra costs from scheduling & co needing to handle 3R though.
by alexey-salmin | 2025-10-03 21:38:26+00:00
A brief history goes like this:

In the past embossed credit and debit cards were both accepted on planes. That's why they were embossed in the first place: for offline processing which in even more distant path was the only option. Later CC machines and offline chip/stripe transactions co-existed with online transactions.

Normally (at least in Europe) you couldn't get an embossed card, even a debit one, without proving your credit worthiness. The possibility of offline transactions assumes overdraft — the same as with check books.

When online transactions appeared, banks started to issue Visa Electron and Maestro cards which didn't work offline, could explicitly prohibit overdraft and were easier to get.

But nowadays all boundaries gradually disappeared. Nothing is embossed, Visa Electron doesn't exist, bank issue debit cards with credit codes. It's all much simpler and more confusing at the same time.
by bitwalker | 2025-10-03 21:38:43+00:00
> There is a separate concern around denied data environments in the software realm but that is not on many people's radar. Most software devs would not know where to even start to protect systems from this.

The concept of a denied environment is pretty clear to me when it comes to physical space, or radio communications - but could you clarify what you mean by a "denied data environment"? I have some notion of what you _might_ mean, but I can't find a clear definition of the idea anywhere.
by fpoling | 2025-10-03 21:38:51+00:00
Extracting keys from a modern SIM card is very difficult. The cost is way above 10K USD. So a payment card in offline mode is absolutely possible as long as one limits the payments to few hundreds USD.

The bigger challenge is an offline terminal that can easy accumulate tenths of USD in case of a long outage. But then compared with cards the terminal may have better protection.
by Terr_ | 2025-10-03 21:38:57+00:00
> “If people are simply being relocated from one public space to another, it is not accomplishing anything for anyone’s benefit,” Clauss said.

> Still, she said she plans to continue reporting them.

> “I think if people simply stop reporting them, the implication could be, ‘Oh, well, people aren’t complaining. I guess it’s not a problem anymore.’ ”

I empathize with this dilemma. The same data that might be misused tomorrow could be important for true reform in a month.
by IshKebab | 2025-10-03 21:39:02+00:00
Insightful article. As they say doubly linked lists are approximately useless and never used. But trees were nodes can refer to their parents are extremely common.

And I agree, a custom arena is usually the best option here. Even though it seems like "giving up" and going back to C, it's still way better.

There's this great comparison of Arenas in Rust: https://donsz.nl/blog/arenas/

Some of them have keys that can't be reused too, so you can avoid "use after free" style bugs (at runtime) which is way better than C pointer wrangling.

It's not perfect though. I kind of wish Rust did have some kind of support for this stuff natively. Pretty low on my list of Rust desires though - way behind better compile time and fewer async footguns.
by alembic_fumes | 2025-10-03 21:39:20+00:00
I see. Do you suppose that the origin of these bugs is more about the difficulty of reasoning about the execution of deep async stacks, or does it come down to the developers holding an incorrect mental model of the Rust futures in their minds?

I am asking because I've noticed that many developers with previous experience from "task-based" languages (specifically the JS/TS world) tend to grasp the basics of Rust async quickly enough, but then run into expectation-misalignment related problems similar to the examples that you used in your post. That in turn has made want to understand whether it is the Rust futures that are themselves difficult or strange, or whether it's a case of the Rust futures appearing simple and familiar, even though they are completely different in very subtle ways. I suppose that it's a combination of both.
by orwin | 2025-10-03 21:39:26+00:00
I've read that the US have almost a million skilled worker shortage in construction (especially commercial and industrial that demand more specific skills), and that since a quarter of the demand is for federal/state/county projects that cannot decide as fast as a company to accept rising prices, it also mean the already decaying public infrastructure risk to never be repaired in time (constructing new stuff is more expensive than repairing expensive stuff. More GDP growth i guess, but :/)

And you have a boom in hardware manufacturing, in Asia mostly, but even in europe you see new companies popping up (before Covid we had like 2 comapnies that could print custom pcbs, both german, now i found like 5 in France (2 of them are the german who expended but still))
by mananaysiempre | 2025-10-03 21:40:46+00:00
> those work because they're just a normal visa transaction

I wouldn’t be so sure about that. In some payment situations you’re asked whether you’d like to have the transaction go through as debit or as credit—so those two must be different somewhere. And probably in more than just a bit in a packet, as, for example, paying with debit Visas or MasterCards (normal ones, not Electron resp. Maestro) in the Netherlands (where locals almost universally have credit cards) is something of a crapshoot.
by wizzwizz4 | 2025-10-03 21:40:59+00:00
> “Your entire face is bad” sounds like lashing out from a place of hurt.

Childlore isn't well documented online, but in my part of the world, "your face" was the orphan-friendly equivalent of "your mom". It is well-understood to be an extremely bad comeback in the circles I frequent: I've not known anyone to misunderstand it. Your mileage may, of course, vary.
by 01HNNWZ0MV43FF | 2025-10-03 21:41:14+00:00
The network effect and the funding is the hard part. People want to be on Facebook, Twitter, and Instagram because they spend billions hosting images for free and they have a million para social friends there

Any competitor will have to compete not on technical competence or privacy, but on "can I upload lots of HD video?" and "are my favorite celebrities there?"

Offramps to let people migrate easier, syndication to let people leave and still do POSSE, a solution to the problem that all free image hosting eventually attracts CSAM, those are difficult problems
by simianparrot | 2025-10-03 21:41:15+00:00
> Yes, but this applies to any media channel or just other human minds.

You can hold a person responsible, first and foremost. But I am so tired of this strawman argument; it's unfalsifiable but also stupid because if you interact with real people, you immediately know the difference between people and these language models. And if you can't I feel sorry for you, because that's more than likely a mental illness.

So no I can't "prove" that people aren't also just statistical probability machines and that every time you ask someone to explain their thought process they're not just bullshitting, because no, I can't know what goes on in their brain nor measure it. And some people do bullshit. But I operate in the real world with real people every day and if they _are_ just biological statistical probability machines, then they're a _heck_ of a lot more advanced than the synthetic variety. So much so that I consider them wholly different, akin to the difference between a simple circuit with a single switch vs. the SoC of a modern smartphone.
by sunshowers | 2025-10-03 21:41:23+00:00
So, regarding transactions, absolutely you can throw them away on cancellation. But there's an interesting wrinkle here: if you use a connection pool like most users, and you were going to do the ROLLBACK at the end of your future on error, then that ROLLBACK wouldn't run it the future is cancelled! Then future operations reusing the same connection would be stuck in transaction la-la land.

(This is related to the fact that Rust doesn't have async drop — you can't run async code on drop, other than spawning a new task to do the cleanup.)

This is prong 3 of my cancel correctness framework (that the cancellation violates a system property, in this case a cleanup property.) The solution here is to ensure the connection is in a pristine state before handing it out the next time it's used.
by legostormtroopr | 2025-10-03 21:42:13+00:00
> Have you considered that … conservatives are self-selecting out or can't cut it at all?

When the ingroup is underrepresented the question is “how can we get more ingroup in”.

But when the outgroup is underrepresented it’s met with “maybe outgroup just isn’t as good”.

Eg. women in tech, men in nursing; conservatives vs liberals in academia.
by sfink | 2025-10-03 21:42:15+00:00
That's not how lexical scope works anywhere but in JavaScript. Or rather, it's the interaction between "normal" lexical scope and hoisting. In a "normal" lexically scoped language, if you tried:

function f() { return x; // Syntax parsing fails here. } let x = 4; return f();

you would get the equivalent of a ReferenceError for x when f() tried to use it (well, refer to it) at the commented line. But in JavaScript, this successfully returns 4, because `let` inherits the weird hoisting behavior of `var` and `function`. And it has to, because otherwise this would be really weird:

function f1() { return x; } let x = 4; function f2() { return x; } return Math.random() < 0.5 ? f1() : f2();

Would that have a 50/50 chance of returning the outer x? Would the engine have to swap which x is referred to in f1 when x gets initialized?

TDZ is also terrible because the engines have to look up at runtime whether a lexical variable's binding has been initialized yet. This is one reason (perhaps the main reason?) why they're slower. You can't constant fold even a `const`, because `const v = 7` means at runtime "either 7 or nothing at all, not even null or undefined".

In my opinion, TDZ was a mistake. (Not one I could have predicted at the time, so no shade to the designers.) The right thing to do when introducing let/const would have been to make any capture of a lexical variable disable hoisting of the containing function. So the example from the article (trimmed down a little)

return Math.random() < 0.5 ? useX() : 1; let x = 4; function useX() { return x; }

would raise a ReferenceError for `useX`, because it has not yet been declared at that point in the syntactic scope. Same with the similar

return Math.random() < 0.5 ? x : 1; let x = 4;

which in current JavaScript also either returns 1 or throws a ReferenceError. I'm not against hoisting functions, and removing function hoisting would have not been possible anyway. The thing is, that's not "just a function", that's a closure that is capturing something that doesn't exist yet. It's binding to something not in its lexical scope, an uninitialized slot in its static environment. That's a weird special case that has to be handled in the engine and considered in user code. It would be better to just disallow it. (And no, I don't think it would be a big deal for engines to detect that case. They already have to compute captures and bindings.)

Sadly, it's too late now.
by twojacobtwo | 2025-10-03 21:43:05+00:00
You need to take a break from the internet for a while. You're getting far too worked up over a passing comment. It clearly wasn't dismissive of the content and, as pointed out, OP immediately followed the comment by talking about the content (I.e. saying it's a decent summary).

Some of us think that anything created by an AI should be labeled as such. Is that an inherently evil belief?

It is a little dumbfounding to compare the seeming emotionality/outrage of your posts with that which spurred it.
by sparky_z | 2025-10-03 21:43:23+00:00
Interesting. Now I have a question about that video, and I think I'm more likely to get a good answer from someone here than in the comments there, so here goes:

Tom says that because that's the only radon cave that can turn the flow of radon on and off at will, it's the only place where you could (in theory) run a double-blind experiment on radon exposure therapy.

My question is: would it not be just as possible to do that in a laboratory setting? Surely there are already lab facilities in the world that are set up for double blind "exposure" experiments of that sort, with easy control of dosages, flow rates, etc. Is the problem that radon gas too expensive to harvest or store safely? Why is that cave the only feasible option?

EDIT: It now occurs to me that the answer could be "because the half life of radon is to short to transport it, so you would basically have to generate it in the lab by getting an enormous amount of uranium in one place and letting it decay and find some way of filtering the byproducts to isolate the radon in a way that putting it under a huge layer of bedrock does naturally." Sounds plausible to me, but does anyone know if that's the case?
by WorldPeas | 2025-10-03 21:43:30+00:00
The problem with rhetoric like this in conjunction with digital convergence is that while, yes, I do have a portal to infinite wasted time in my pocket, it is also how I control my HVAC and tv and pay for everything and use the metro and unlock my doors. There is no longer any separation, mentally, physically or locally. Though I do not use it this way, I cannot imagine the trigger of having to unlock your door with the same device you use to gamble.
by bilbo0s | 2025-10-03 21:43:56+00:00
Not to put too fine a point on it, but do you consider handwriting comparisons "reliable and definitive"?

Because juries regularly convict people in courts based on such evidence.

Maybe a better question is, what is the level of "reliable and definitive" that evidence would need to reach for you to believe it should be admissible in court?

I suspect that maybe that's the misunderstanding. The level for you is much higher than maybe it is in the justice system. Which is fine. But that doesn't change the justice system. In court, the currently accepted levels are still enough.

People will be free to try to refute the attributions during the proceedings if they think it will do any good. I mean the adversarial system is also part of the justice system.
by zahlman | 2025-10-03 21:44:07+00:00
> Relative imports work by relative package path, which is not at all the same.

Exactly. This gives you the flexibility to distribute a complex package across multiple locations.

> Often when you run Python you don't even have a package path.

Any time you successfully import foo.bar, you necessarily have imported foo (because bar is an attribute of that object!), and therefore bar can `from . import` its siblings.

> Using `importlib` is a horrible hack that breaks basically all tooling. You very very obviously are not supposed to do that.

It is exactly as obvious (and true) that you are not "supposed to", in the exact same sense, directly specify where on disk the source code file you want to import is. After all, this constrains the import process to use a source code file. (Similarly if you specify a .pyc directly.) Your relative path doesn't necessarily make any sense after you have packaged and distributed your code and someone else has installed it. It definitely doesn't make any sense if you pack all your modules into a zipapp.
by sunshowers | 2025-10-03 21:44:53+00:00
Yeah, it's a combination of both in my experience. I think even to experienced async Rust programmers, things like Tokio mutexes being really hard to use correctly can be a bit surprising.

Also, as another comment on the thread points out [1], languages where futures are active by default can have the opposite problem.

[1] https://news.ycombinator.com/item?id=45467188
by awaisraad | 2025-10-03 21:44:55+00:00
I have been digging Hydrogen ever since reading this. Imagine a world that is run on H2 generated from solar energy. Fertilizer and Steel manufacturing are going to be revolutionized.

* 10L water to generate 1KG Hydrgoen.

* A 20MW electrolyzer can produce over 8000KG Hydrogen per day

P.S. I have spoken. I wont be able to carry this debate.
by conductr | 2025-10-03 21:46:17+00:00
There’s not a lot of actual innovation in software. Hasn’t been in quite some time. Any project a lot of these companies invest in has to be tied to a revenue stream or it doesn’t get funded. I think it’s a wholesale realization that they’ve been throwing money away at projects with no revenue and they’re shaping up/maturing as a company being smarter about what projects they invest in. I’m sure it has to do with tax code changes and such that initiated the bigger rethink. But it’s also just not a lot of big new foundational innovation taking place.

I’m not so optimistic. But glad some people are!
by zahlman | 2025-10-03 21:46:49+00:00
Yes, if checking for a file is slow, then checking for a file is slow. If you need to know up front whether the module exists, then you can't get around using the "figure out whether the module exists" machinery up front. And if the definition of "a module exists" includes cases where the module is represented by a file whose existence you have to check for, then there's no getting around that, either.

(Trying to do "fallback" logic with lazily-loaded modules is also susceptible to race conditions, of course. What if someone defines the module before you try to use it?)
by sroerick | 2025-10-03 21:48:43+00:00
I remember downloading apps for the TI83 but I only did basic coding stuff in them for extra credit.

I genuinely would ask, how do I have fun? Maybe this is a generational thing, but like where would start? I'm interested in demoscene stuff but know nothing about it.

I'm just a CRUDmonkey who only knows how to CRUD. I love the idea of carrying around a Pico calc and writing BASIC apps but in 2025 I don't know how to begin in a way that motivates me. Probably a personal weakness, but that's just my experience
by craftkiller | 2025-10-03 21:49:33+00:00
By crux you mean the 1 paragraph at the end where it mentions performance? That's basically a footnote to an article that spends the other 99% describing javascript variable hoisting. They cite an 8% performance boost but they don't analyze it, instead just claiming it is a lot of work for the interpreter and linking to a github issue. They've run no benchmarks. They have shown no interpreter internals. They just report that one project saw an 8% performance improvement.

They did a great job of explaining javascript variable hoisting, but that's all that they have explained.