MurphyA/hacker-news huggingface dataset:
by Muromec | 2025-07-23 23:21:10+00:00
>How is "let it crash" helpful to my customer who now needs to wait for the issue to be noticed, resolved, a fix deployed, etc.?

Let it crash is more about autorestarting and less about type bugs. If you have a predictable bug in your codepath that always breaks something, it just means you never tested it and restarting will not fix it. But this kind of straightforward easy to reproduce bugs are also easy to test the hell out of.

But if you have a weird bug in a finite state machine that gets itself into a corner, but can be restarted -- "let it crash" helps you out.

Consider hot reload -- a field exists in a new version of a record, but doesn't exist in a old one. You can write a migration in gen server to take care of it, but if you didn't and it errored out, it's not the end of the world, it will restart and the problem will go away.
by meerab | 2025-07-23 23:21:14+00:00
YT transcripts definitely lack speaker ID. LLMs can infer speakers from context but miss nuance without proper speaker recognition.

I have been tackling this while building VideoToBe.com. My current pipeline is Download Video -> Whisper Transcription with diarization -> Replace speaker tags with AI generated speaker ID + human fallback.

Reliable ML speaker identification is still surprisingly hard. For podcast summarization, speaker ID is a game-changer vs basic YT transcripts.
by greenie_beans | 2025-07-23 23:22:54+00:00
there it is, and here it is: https://news.ycombinator.com/item?id=44662250

specifically

> i have a different overall vision than those products, and it's built with a more modern tech stack and design considerations. i have an ai prototype for appraising books that i've successfully used to appraise and list my own collection. and i plan to build in some automation tools that would be useful to a bigger brick & mortar, like "order me 5 more copies of 'as i lay dying' when inventory count gets down to 3" and other ways a savvy bookseller could hook into automation that could help them with their work. and for the non-technically savvy users, i'm hoping to have great customer service to help them with some automation. i think this might end up being a core part of the product but only time will time. i also have some marketing tool ideas that nobody has built, based on some past experiences working in library tech and my time doing marketing for a bookseller.

helps to have somebody helping me who works in a bookstore. and also helps to use it myself, since i am user #1. was waiting for the HN cynicism! glad you like it :)
by zimzi | 2025-07-23 23:23:02+00:00
Generally no - cross origin iframes don't allow camera/audio by default. Even if the toplevel site allows it (via https://developer.mozilla.org/en-US/docs/Web/API/HTMLIFrameE...), user still needs to grant permissions to toplevel site. Of course you can still use window.open and top.location.href in the iframe and use the same trick as in the article.
by rramadass | 2025-07-23 23:24:09+00:00
I am not sure that you have really understood the topics you have named. All high-level programming languages give you a set of fundamental types and the ability to construct user-defined types. Currying is not an exception but falls under the same model if one considers it as a Relation between "sets of functions". Also by Curry-Howard correspondence you have "formula/proposition = type" and "proof = function". So you have a direct mapping between Sets/Relations/Logic in Mathematics and Types/Logic in a Program.

A Program then becomes a trajectory enforced using predicate logic through a state space obtained from the cartesian product of all the types in the program.

You are using all of the above whether you know it or not when programming in a high-level language. The real value comes when you do it with the knowledge of the mathematics in hand because then it allows you to prove your Program as "Correct" (w.r.t. a specification).
by kragen | 2025-07-23 23:25:53+00:00
Land mines have been killing people by surprise for decades. Flying drones, some of them dropping land mines and others lying in wait for incoming convoys, produced 70% of the casualties on both sides in the Ukrainian invasion last year, and a few weeks ago the Ukrainians shipped some drones to near a Russian airport several thousand kilometers from Ukraine to blow up a bunch of airplanes. This betokens a future of borderless warfare in which probably most of your family members will be killed over the next few decades, by one or another type of semi-autonomous or fully autonomous weapon.

CARA is a super cool project which is never going to kill anybody, but it's another piece of evidence that the cost of the technology for such weapons has decreased enormously.

That said, talking about the dread is going to get boring fast, because nearly every story on the HN front page is catapulting us toward that future.
by dap | 2025-07-23 23:26:06+00:00
The post appears to conclude that this must be a hardware issue because they have no explanation and PostgreSQL and the kernel are too reliable to have data corruption bugs. I've seen data corruption bugs in both databases and the kernel (as well as CPUs, for that matter), so I'm pretty skeptical of that explanation.

When something "can't happen" in your program, it makes sense to look at the layers below. Unfortunately, this often goes one of two ways: you ask people for help and they tell you that it's never one of the layers below ("it's never a compiler bug") or you stop at the conclusion "well, I guess the layer below [kernel/TCP/database/etc.] gave us corrupted data". The conclusion in this post kind of does both of these things. Of course, sometimes it _is_ a bug in one of those layers. But stopping there is no good either, especially when the application itself is non-trivial and you have no evidence that a lower layer is at fault.

People often treat a hypothesis like "the disk corrupted the data" as unfalsifiable. After the fact, that might be true, given the stack you're using. But that doesn't have to be the case. If you ran into a problem like this on ZFS, for example, you'd have very high confidence about whether the disk was at fault (because it can reliably detect when the disk returns data different from what ZFS wrote to it). I realize a lot goes into choosing a storage stack and maybe ZFS doesn't make sense for them. But if the hypothesis is that such a severe issue resulted from a hardware/firmware failure, I'd look pretty hard at deploying a stack that can reliably identify such failures. At the very least, if you see this again, you'll either know for sure it was the disk or you'll have high confidence that there's a software bug lurking elsewhere. Then you can add similar kinds of verification at different layers of the stack to narrow down the problem. In an ideal world, all the software should be able to help exonerate itself.
by crystal_revenge | 2025-07-23 23:28:15+00:00
> I'm sure "move fast and break things" will work out great for health care.

Health care is already broken to the point of borderline dystopia. When I contrast the experience I had as a young boy of visiting a rural country doctor to the fast food health care experience of "urgent care" clinics, it makes my head spin.

The last few doctors I've been to have been completely useless and generally uncaring as well. Every visit I've made to a doctor has resulted in my feeling the same at the end but with a big medical bill to go home with.

At this point the only way I'll intentionally end up in a medical facility is if I'm unconscious and someone else makes that call.

Dentistry has met a similar fate as more and more dentists have been swallowed up by private equity. I've had loads of dental work, including a 'surprise' root canal, and never had an issue. My last dentist had a person on staff dedicated to pushing things through on the insurance front and my dental procedure was so awful it boarded on torture.

I used to be an annual check + 3 times a year dentist person. Today I'm dead set on not stepping foot in any kind of medical facility unless the alternative is incredible pain or certain death.
by cogman10 | 2025-07-23 23:28:16+00:00
Not as much as you'd think. In this article [1], one expert failed to identify that a white wine dyed red was the same. They used different descriptors for the same wine.

And none of this should be too surprising. Our brains are complex things that like to hallucinate details. If you tell someone a bottle of wine cost $1000, their brain will happily invent reasons why it's one of the best wines they've tasted.

[1] https://www.theguardian.com/lifeandstyle/2013/jun/23/wine-ta...
by wrp | 2025-07-23 23:28:23+00:00
Many years ago, like maybe in the 1920s, the randomness of success in life was the focus of popular interest sufficiently to inspire scholarly research. I think it was mostly history professors who collected case studies of "lucky" people and tried to find patterns. I don't know how many publications resulted, but I read two or three books.

The books generally provided lists of observed patterns, usually at least a half dozen but sometimes a few times that. My takeaway from that reading was three general principles.

1. Location: The kind of events that you would consider relevant luck are not evenly distributed geographically. You need to be where they happen more often.

2. Preparation: At those locations, there will probably be multiple candidates waiting to take advantage of an opportunity. You need to aim to be the best candidate.

3. Flexibility: Your expectations for desirable opportunities have been molded by your limited knowledge of the world. You need to be ready to pursue opportunities that weren't exactly what you had in mind but may turn out to be just as satisfying.

TFA is hard to comment on because it feels like a rough draft. The reasoning could be sharpened. I have reservations about the "air your weirdness", because it seems to contradict the principle of flexibility.
by throwawaymaths | 2025-07-23 23:28:37+00:00
sure part of the decision is that you can't really soundly type (in a developer sanity preserving way) across a cluster that runs multiple versions of software (which is a real use case that the authors absolutely needed to support as part of the core business). but they let dialyzer in to the core so it's not like the team was actively hostile to typing.
by haberman | 2025-07-23 23:29:25+00:00
This kind of "expected next field" optimization has a long history in protobuf, but results are mixed.

The generated code in C++ used to check for the expected next field before falling back to the switch() (example here: https://github.com/protocolbuffers/protobuf/blob/460e7dd7c47...) but this was removed in 2016 when load tests found that it hurt more than it helped.

One tricky part of making this optimization work is making a good guess about what the next field should be. Miguel's article alludes to this:

> Each field specifies which fields to try next. This allows the compiler to perform field scheduling, by carefully deciding which order to try fields in based both on their declaration order and a rough estimation of their “hotness”, much like branch scheduling happens in a program compiler. This avoids almost all of the work of looking up the next field in the common case, because we have already pre-loaded the correct guess.

> I haven’t managed to nail down a good algorithm for this yet, but I am working on a system for implementing a type of “branch prediction” for PGO, that tries to provide better predictions for the next fields to try based on what has been seen before.

One delightful thing about the tail-call parser design is that the CPU's branch predictor effectively takes over the job of guessing. With a tail call parser, the dispatch sequence ends up looking like this:

cmp QWORD PTR [rdi+0x8],rsi # Bounds check jbe .fallback movzx r10d,WORD PTR [rsi] # Load two bytes of tag mov eax,r10d and eax,0xf8 mov r9,QWORD PTR [rcx+rax*2] # Load table data xor r9,r10 mov rax,QWORD PTR [rcx+rax*2+0x8] # Load field parser function jmp rax # Tail call to field parser

That "jmp rax" instruction is an indirect branch that can be predicted by the CPU. The CPU effectively guesses for us!

And unlike any kind of guess we might have performed ahead-of-time, the branch predictor will constantly adapt to whatever patterns it is seeing in the data. This is good, because statically guessing ahead-of-time is hard.
by paulryanrogers | 2025-07-23 23:30:36+00:00
If the Second Amendment (2A) meant to preserve the ability to overthrow the government then why can we not have bombs and tanks?

And why does it mention the right within the context of a "well regulated militia"?

Could it be they feared having a permanent national army, so did the 2A instead? Only later to realize having a standing army were necessary after all?

No that couldn't be it. Because then there would be no rational reason for keeping 2A and flooding the country with deadly weapons.
by consumer451 | 2025-07-23 23:31:03+00:00
My post, which is likely not clear, is not about training models. It is about an AI product which could replace everything that your brain does. Not just work, but all of your decision making [0].

If all of your work and knowledge is done via text like Slack or Email, or via transcribed online meetings, then this seems relatively easy in the long term. That problem is not that hard, conceptually. However, it would still not know some anecdote that you heard over beers from someone else, which is how multiple AI concepts were discovered.

If we continue that idea, not just work, but to offload all our our thinking, a virtual you, it would require from birth A/V data capture, right?

[0] The reason that this came up in my mind is that today I presented a new LLM-enabled feature in my SaaS product, to my beta users. One user quickly and unironically, responded "This is awesome! I don't have to use my brain for this anymore!" This scared the crap out of me, and my post here is the generalization of this idea.
by godelski | 2025-07-23 23:31:10+00:00
> the exploration–exploitation tradeoff ... for which no universally optimal solution is known

I want to nitpick a bit. It may be nuanced, but I think it makes a significant difference.

Exploration-exploitation is about a class of algorithms[0], and I would not say that means "there is no optimal solution." Rather, it is often applied to problems where there is no optimal solution. You can apply it to problems with known optimal solutions and it should still get you to the optima.

What problems don't have global optima? Most. Most problems we simplify in ways that will contain an optima, but it is best to remember the assumptions made and if they appropriately apply. This is part of why always maintaining at least some exploration can be a highly successful strategy. Extremely useful in the real world too as the environment is always changing. You cannot generate globally optimal solutions for dynamic problems where the future states are unknown.

[0] Examples include Q-Learning, Bandits, or sampling algorithms. Multiarmed bandits and Thompson Sampling are mentioned in the wiki but note that there are more bandit algorithms and more sampling algorithms.
by gota | 2025-07-23 23:31:12+00:00
> Earlier this month, hackers using credentials purchased from a C&M employee were able to generate unauthorised PIX transactions

To be clear - This was a "bank robbery" (inside job, given usage of credentials?) and in absolutely zero ways affects trust in Pix as a user

As for your other point - thanks, our values and concerns are not aligned; it would be hard for us to agree on this
by greenie_beans | 2025-07-23 23:31:19+00:00
yes!! love all this. what POS do you use?

i have a chicken and egg problem with POS providers. i've had to reverse engineer the ETL to accept FTP files, making the sync generic since nobody will let me develop on their system without a customer who wants it. i've been waiting two weeks for basil to add the integration for our first customer. and about to start with ibidie for a test customer.

and yes 100% on not using amazon. i was indoctrinated against them as an indie bookseller. i've even avoided using free amazon credits.

the docs feedback is great. thank you!!! and square is next step after i finish shopify. i will use that to sell my books at pop-up events and it would be a great little starter system for a small bookstore. then i'll add ingram integration with ordering etc. going towards "the brains of your bookstore". sort of a newer take on POS that integrates with everything, and the basis is the inventory system.
by WantonQuantum | 2025-07-23 23:31:59+00:00
I started using Claude Opus 4 recently and it's a real step up (I hadn't used Claude at all before that). I don't use VSCode or Roocode - just a Github Copilot plugin for my IDE that allows me to select Claude Opus 4 - and I see all the benefits talked about in this article.

So I guess what I'm saying is that if you want to see what it's like to do some AI coding "that isn't complete garbage", Claude might be your first port of call.

By the way, I used to be a vibe coding skeptic but recently I used Claude to help set up a kubernetes cluster with spark, minio and delta lake. I don't have much experience with these technologies and I leaned on Claude heavily to get it up and running. I give it two thumbs up.
by gilbetron | 2025-07-23 23:32:35+00:00
Oh, I see. Your 5000 mile car is petrol. FWIW I think the math still works to get a new EV, because it isn't like you are going to toss away the current car, but sell it to someone used. I think. It's tricky to work through.

Plus, I'm pretty sure EVs will easily last 13+ years, although we have few examples, but EVs are way less complex so they should generally last longer. Even batteries seem to be doing great at 10+ years.
by ghc | 2025-07-23 23:33:15+00:00
I'm not disagreeing that it's good to keep humans in the loop, but the systems I've worked on give domain experts new information they could not get before -- for example, non-invasive in-home elder care monitoring, tracking "mobility" and "wake ups" for doctors without invading patient privacy.

I think at its best, ML models give new data-driven capabilities to decision makers (as in the example above), or make decisions that a human could not due to the latency of human decision-making -- predictive maintenance applications like detecting impending catastrophic failure from subtle fluctuations in electrical signals fall into this category.

I don't think automation inherently "de-skills" humans, but it does change the relative value of certain skills. Coming back to agentic coding, I think we're still in the skeuomorphic phase, and the real breakthroughs will come from leveraging models to do things a human can't. But until we get there, it's all speculation as far as I'm concerned.
by bm3719 | 2025-07-23 23:33:24+00:00
> This isn't even getting into the Jungian "death drive"

The death drive is Freudian, not Jungian. However, it might be very relevant here. Freud's conception of it would include passively accepting death. As you say, by the time the prisoner is about to be executed, they're often resigned to their fate, the death drive having overcome the id long ago. Contrast with massacres where the victims weren't expecting it (the Malmedy massacre of freshly captured troops comes to mind from the same era) and you see people trying to run away once it starts.

Lacan called himself Freudian, but I think his conception links the death drive with active desire, seeking a form of self-destructive pleasure by action. I recall from Écrits that he links it to masochism, for example, calling it an expression of transgressive jouissance.
by MichaelZuo | 2025-07-23 23:34:06+00:00
You seem very confused?

There is only 1 HN user who replied with any link whatsoever (at the time of writing this)… so literally not even multiple “people”.

Edit: If you are geniuinely experiencing some kind of vision problems, such that a second user appears to have linked some kind of evidence underneath my comment, I recommend logging off and seeking help for mental/eye issues.
by rtpg | 2025-07-23 23:34:19+00:00
> What I'm hoping though is improved tooling around debugging Python. Currently, in my experience, VSCode (more specifically, debugpy) provides pretty much unmatched remote debugging capabilities, and I'm really hoping we can have a standardized way to connect any IDE to remote Python processes with the same UX as VSCode.

This is what 3.14's remote debugging protocol gives us. And even more than that, because I believe that debugpy needs to be invoked beforehand!

The value of this tooling is you don't need to predict that you need debugging before running the program. All of your Python programs[0] can be debugged. No need to restart. No need to modify the launch parameters either: you don't need the "debug configuration" from vscode, you just need a PID.

[0]: so long as you're using the same version of Python and it has the remote debugging protocol enabled, and also you have the right OS permissions
by fao_ | 2025-07-23 23:34:32+00:00
Eh, you could probably get away with it if you use BearSSL[0]. The only difficulty would be:

These elements can be allocated anywhere in (writable) memory, e.g. heap, data segment or stack. They must not be moved while in use (they may contain pointers to each other and to themselves).

Which you could probably get around with by just keeping track of offsets and using mmap

[0]: https://www.bearssl.org/api1.html
by joseluis | 2025-07-23 23:35:06+00:00
Just a nitpick. Rust's char is really a 21 bit unicode scalar value (a code point without surrogates) using a 32-bit representation and indeed there are a lot of invalid char values in a 32-bit space. Utf-8 is a different encoding format for code points using variable width (1-4 bytes per).
by echelon | 2025-07-23 23:35:29+00:00
> In which world is Rust fantastic for writing desktop applications? Where are the mature Rust UI frameworks?

Rust has come a remarkably long way [1] !

It's better than any language that isn't C/C++. We have bindings to all of the major UI toolkits, plus a lot of native toolkits.

You can also use Electron/Tauri for Javascript, or Dioxus for something more performant. Egui is also really nice for dev tools.

> What does this even mean?

Rewrite It In Rust metrics tend to tell good stories.

Developer blogs (links escaping me right now) show positive performance gains for lots of consumer desktop software written in whole or in parts using Rust. Discord, Slack, lots of other apps are starting to replace under-performing components in Rust.

> For example? And what do you mean by "AI powered desktop apps"?

Stuff like Zed [2] and the open source Photoshop-killer I'm working on (user-guided volumetric rendering, real time instructive Figma). The creator or egui works on Rerun [3], which is industrial / spatial visualization. Etc, etc.

[1] https://areweguiyet.com/

[2] https://zed.dev/

[3] https://rerun.io/
by Rochus | 2025-07-23 23:36:25+00:00
> He literally gives extensive primary source citations to show that the originators of OOP presented this class-domain correspondence

In case of Dahl/Nygaard it seems logical since their work focus was on simulation. Simula I was mostly a language suited to build discrete-event simulations. Simula 67, which introduced the main features we subsume under "Object-Orientation" today, was conceived as a general-purpose language, but still Dahl and Nygaard mostly used it for building simulations. It would be wrong to conclude that they recommended a class-domain correspondence for the general case.

> Bjarne Stroustrup is not just some random guy

Sure, but he was a Simula user himself for distributed systems simulation during his PhD research at Cambridge University. And he learned Simula during his undergraduate education at Aarhus, where he also took lectures with Nygaard (a simulation guy as well). So also here, not surprising that he used examples with class-domain correspondence. But there was also a slide in the talk where Stroustrup explicitly stated that there are other valid uses of OO than using it for modeling domains.