MurphyA/hacker-news huggingface dataset:
by gambiting | 2026-01-10 09:26:41+00:00
Obviously I know "jad" but I don't see any issue with calling venom "trucizna". Natural languages aren't C++ and you don't get compiler errors when you speak - to me, there is no issue calling both venoms and poison trucizna. Polish dictionary doesn't seem to contradict it either:

https://sjp.pwn.pl/slowniki/trucizna.html

The point is, both are correct(afaik) while in English venom and poison are definitely two different things.
by samrus | 2026-01-10 09:26:48+00:00
The metric used to gauge the efficacy of the usps was rate of ontime delivery, but whe. The same point was made about the canadian postal service, that was never brought up.

Plus the trend being fixated on is between 2022 and 2024/2025. I feel like the author is being abit disingenuous here by not acknowledging the black swan in the room with those numbers
by pajuhaan | 2026-01-10 09:27:07+00:00
In physics, there are tons of things we think we already “solved” but I’m not sure the real problem is the answer. It’s the question.

We often analyze clean observations through an incomplete model, then treat the mismatch as a new “thing” in the universe, and suddenly we get a whole zoo of complex theories. Dark matter and dark energy are the sharpest examples! galaxy rotation curves stay flat where Newtonian gravity says they should fall, and the universe’s expansion seems to accelerate so we add Lamda(!) and call it “vacuum energy,” even though the naive QFT estimate overshoots by absurd orders of magnitude.
by llmslave3 | 2026-01-10 09:27:29+00:00
I was wondering why stuff was written in JS in the past - it seems obvious to use a faster language for these tools, but I then realised that these massive sprawling Typescript codebases are a modern phenomena. I sort of wonder if the tooling is just step one, and step two is not just the tooling but the other codebases going from TS to a faster lang (like Go).

Speaking of Go, Esbuild is amazing. You can write entire dev servers and build pipelines in a couple hundred lines of Go, with hot reloading etc. Full control over your build process, plugins are compiled with the builder so you don't pay the JS -> Go cost, it's really great stuff. I love Esbuild, thank you Evan :)
by Traubenfuchs | 2026-01-10 09:27:39+00:00
Work for big companies that offer SWE positions they don‘t really need but won‘t downsize due to lack of accountability.

Never join small, privately owned (or even worse, privately controlled!) companies with extreme accountability and ownership. No startups. Run if they mention they are a company that is performance driven or a place where you can make an impact.

You want to be one of many random swe who can hide among his peers and you want to be able to make tons of meetings and red tape responsible for your slow progress.

Government, insurances, banks, big-corpo-bodyleasing consulting (like accenture, NOT „high pressure boutique consulting“). Body lease consulting is ideal, you can regularly leave behind the mess you caused and move on.
by JeanMii | 2026-01-10 09:29:18+00:00
I've learned to come to terms with this mentality, mainly due to time constraints. Before, I would always do an insane amount of research and benchmarking to find the absolute best in its category, even for mundane things like a coffee grinder. I would aggregate thousands of reviews and turn them into sentiment analysis, cross-referencing reviews, and so on.

Now, I take a more 80/20 approach: I clearly define my needs and shut down any thoughts about features and capabilities that I don't need right now. Frankly, after years of thinking that I might use a feature later, I realise that I never do and never recover my investment in these kinds of gadgets.

Finding a trustworthy review source is key — by trustworthy, I mean mostly in line with your own standards. However, if you can try it yourself, that's always better.

For sound on small devices with clear voice and a good dynamic range, Samsung is quite good with its high-end Galaxy Tab line.
by adityaathalye | 2026-01-10 09:30:20+00:00
Ah, Anil, but have you fought the plaintext syntax wars yet?

Jokes apart, regular, standardised, visually-suggestive syntax is a key reason I've stuck with org-mode despite its limited acceptance in the world at large.

The many flavours of markdown make it /less/ portable than org syntax, in my experience. As the post below says, "Pandoc lists six different Markdown flavors as output formats." This is not great for collaboration --- now we need some sort of middleware or advanced editor to help people work with more than one syntax format. Besides, mixing syntax in the same document is a boo-boo, because parsers only work at file-level, not semantic token level.

Owing to this, at times, I go as far as to /author in orgmode, but share in markdown/ (org-export), and slurp back and forth (tangle / detangle).

Cue:

Org Mode Syntax Is One of the Most Reasonable Markup Languages to Use for Text: https://karl-voit.at/2017/09/23/orgmode-as-markup-only/
by MORPHOICES | 2026-01-10 09:30:26+00:00
I have noticed a trend with newer JS tooling beyond performance. Indeed, builds are quicker. The cold starts decrease. That’s great. ~

However, the feedback duration is the actual behavior modifier.

My perception map.

Speed test, compilation time benchmarks.

Loop tightness refers to how fast you notice a mistake.

Cognitive load refers to the amount of context you maintain in memory while waiting.

Most developers don't make use of max throughput. They strive to avoid distractions. Tools that are written in faster languages matter mainly because they shrink the gap between action and signal.

Some "quick" weapons stick, that is why. Problems of today often relate to mystery, not slowness.

The rule I abide by now is that if a tool feels calming while debugging, it wins.

Inquisitive.

What tools have made an impact on your daily workflow?

When has hype about performance not translated into adoption?

What is the next bottleneck after speed?
by rvnx | 2026-01-10 09:32:31+00:00
I usually like to accuse people of the wildest privacy conspiracies, but here in the case of Orion, one day the founder approached me together to work with him, and I tried to see how far is he willing to do in practice (“ok maybe we could do X and Y or Z”).

He stopped me and explained to me that is his business model, and… it was to sell apps / subscriptions. He has no interest into anything else and strongly explained that the user pays and that’s it.

Eventually I didn’t work with him but I have a very positive opinion of him, so at least, based on my experience as a potential employee strongly trusts
by mcintyre1994 | 2026-01-10 09:34:06+00:00
I disagree with them on the large PR section. I agree that we sometimes don’t review these in detail, but the thing that enables that for me is a trusted contributor explaining deterministically what they did. I renamed whatever variable, or I changed whatever script in all these places, I updated whatever lint rule and fixed all the errors, I moved whatever to a separate package.

All of these can create a diff across lots of files, but can be easily explained to a reviewer.

The problem is that I can’t trust an LLM to act deterministically the way I trust some people to. So I can’t just take that higher level view of “yep cool that sounds like a good idea” and skim the changes.
by MORPHOICES | 2026-01-10 09:34:13+00:00
Viewing sites like Dwitter always refreshes my confidence in creativity. ~

You would expect severe restrictions to yield sameness. On the contrary, you receive untamed variety. Optical illusions. Modern sayings. People twisting the medium in unplanned directions.

The trend I’ve noticed.

Limits prevent uninvited focus.

Constraints that we all share can become a shared language.

A tiny scope reduces experimentation expenditure.

When the area of surface is small, people penetrate deep instead of spread wide. They experiment with odd concepts since failing is inexpensive and quick.

Unlike most platforms that add features to unlock creative potential, which actually ends up overwhelming it.

A rule that I keep coming back to: if something feels playful, constraints are probably doing their job.

Inquisitive.

In what situations did restrictions lead to better outcomes?

When do limitations start to seem fictitious?

What contemporary instruments ought to be more limited?
by internet_points | 2026-01-10 09:36:07+00:00
Highly recommend the book "Shark Drunk: The Art of Catching a Large Shark from a Tiny Rubber Dinghy in a Big Ocean" by Morten Strøksnes if you're interested in old sharks, small boats or deep oceans https://bookshop.org/p/books/shark-drunk-the-art-of-catching...
by goku12 | 2026-01-10 09:36:19+00:00
> It’s a circle that needs to be broken. It has multiple parties even without device manufacturers.

Well, you're right, however badly I don't want to admit it. Google broke that cycle once with Android. I'm sure that Apple would have too, even if they were not the first mover. And there's no question that their wealth and influence had a massive role in it - something an open platform cannot match realistically.

But the current situation is simply untenable anymore. I want out, no matter how many others don't care for it. The open platform has to be just functional enough (including app support, even as PWAs), for us to break free from this duopoly. Just like how Linux and BSDs are on desktops. I'm able to do everything on it from work to netbanking. I would hate it really badly if I was forced to use Windows or MacOS these days.
by _the_inflator | 2026-01-10 09:36:37+00:00
Nothing comes even close to the Computer History Museum in Moutainview, CA.

On my bucket list is a two weeks trips to spend there. For me it is the world’s only epicenter of start to finish of all technologies. So many precious pieces no matter big or small, from Japan or like the Zuse, from Germany - I cannot get enough of it, especially the people you can meet there.

Founders, builders, billionaires as everyday Joe doing maintenance or giving talks - this is so much better than any ebook there is and also time runs, if you start to find out about the mechanical IBM machines, and especially the the smell there, which was a revelation.

Nevertheless kudos to any Electronics Museum or Automobile Museums. It takes a lot of dedication and maintenance to build these museums for us.

Thanks a lot, this is my Disney World on steroids, my childhood playground.
by DanRosenwasser | 2026-01-10 09:36:37+00:00
I guess since this at the top of HN, I'll just plug that we (the TypeScript team) are looking for broader feedback of the native previews before our stable release, whether that's:

- through builds (https://www.npmjs.com/package/@typescript/native-preview), or

- through the editor extension (https://marketplace.visualstudio.com/items?itemName=TypeScri...)
by sznio | 2026-01-10 09:38:38+00:00
I tried a similar setup when in college, albeit with a X230 and a 1050Ti, and it worked amazing... for a few minutes at a time, since it blue-screened often.

I never managed to figure out the issue. The BSOD was something about a gpu timeout. It worked perfectly at home but shat the bed at the dorm. I assume there was some nasty interference there.
by phtrivier | 2026-01-10 09:40:22+00:00
I was waiting for the moment when the author finds occasion to reciprocate, but then he explicitly says he does not thing he would do this.

That's brutally honest, but really, isn't the lesson from his whole trip that either :

- yes, he would reciprocate, because that's human nature, and it is why the "miracle" keep happening

- no, he would not reciprocate, and how can he not be ashamed of that, or his upbringing, or his society, etc... ? And what is different in the life's of the people who did help him ?

"Elle est a toi cette chanson, toi l'auvergnat qui sans façon..."
by aziis98 | 2026-01-10 09:40:24+00:00
The erdos problem website tells the theorem is formalized in Lean but on the mathlib project there is just the theorem statement with a sorry. Does someone know where I can find the lean proof? I don't know maybe it's in some random pull request I didn't find.

Edit: Found it here https://github.com/plby/lean-proofs/blob/main/src/v4.24.0/Er...
by miemex | 2026-01-10 09:41:14+00:00
OP here.

I built this because "Zoom Fatigue" for me is actually "Understimulation Fatigue".

I noticed the trend of "sludge content" (split screen videos with gameplay) actually helped me focus on audiobooks, so I ported the concept to Google Meet.

It's a Chrome Extension that injects a draggable, resizable `<iframe>` container over the meeting grid.

- Caption Sync: It uses a `MutationObserver` to scrape the live caption node from Google Meet's DOM and renders it into the overlay, so you can watch the loop and read the meeting simultaneously.

- State Management: Handles the fragility of Meet's DOM updates (which break observers constantly) by re-attaching listeners dynamically.

- Privacy: 100% client-side. No meeting audio/video is recorded or sent to a server.

It's a weird solution to a modern problem, but it works for my ADHD brain.

Happy to answer Qs about the implementation!
by jimnotgym | 2026-01-10 09:42:33+00:00
You sound like you are just repeating the same mistake in telling a nuerodiverse person to 'just do this brain hack, it worked for me.' It will never work for them. Never. It will just make them feel worse about themselves.

I am brilliant at certain aspects of my job. I have read the books, had coaching etc. And yet today I still miss important meeting because I don't realise it is time to go...with a watch on my arm, outlook reminders popping up etc. I just hold attention so deep that I am never going to notice. It is what makes me great at my work. So now I am a manager I have developed some solutions. I hire people who compliment me, and I am open about my problem. It is normal for my team to walk in my office and say, 'are you coming to this meeting?'
by duskdozer | 2026-01-10 09:43:03+00:00
I think the idea that changing stated recommendations based on the public opinion is a questionable strategy that can just backfire into more distrust and behavior that follows the "true" best practices even less as they look for the 'sensible position between extremes'[1].

There are a lot of examples from the response to COVID: frequent early mixed messages around the effectiveness of masks for preventing infection and transmission not based on the actual understanding of said effectiveness but in order to manage supply shortages, arguable overstatement about the one-time long-term effectiveness of the initial vaccines against infection and transmission and not just severity of disease, overemphasis on ineffective measures like hand hygiene or six-foot-distancing over effective measures like air cleaning and masking based on the perceived willingness of the public to follow them, reduction of the stated duration of contagiousness without evidence of such.

It's one thing if it's genuinely not known what the best practices are, but knowing and misleading can confuse people who are willing to follow them and can further alienate skeptics who may seek out charlatans promising them the "real, unfiltered truth".

[1]https://en.wikipedia.org/wiki/Argument_to_moderation
by torginus | 2026-01-10 09:43:11+00:00
We live and have lived in a technological civilization for more than a hundred years. Legislators have NO EXCUSE to hide behind 'we don't understand the technology'. Sure computers are complex. But so are nuclear reactors, combustion engines and food safety.

If nuclear reactors cost 3x what they should, yet safety incidents occur 2x as often as they could because of stupid legislation, they shouldn't be able to hide behind 'we only have a legal diploma so we can't figure out what actuall works'.

For some reason, a lot of older folks consider computing as a 'low stakes game', as computers being either an annoyance or convenience but nothing more.

I don't know if the system is fundamentally flawed, and the people in charge are becoming less and less able to actually handle the reins of society and some major upheaval is necessary, or the system can be fixed as is, but this seems endemic and something should be done.
by Aldipower | 2026-01-10 09:43:47+00:00
Really nice!
Reminds me of my "Voyetra Sequencer Plus Gold" which I still have running on a 286, because it has great midi timing!
"Miditui" would need a descent recording feature besides easy keyboard roll editing, quantization and so. Any plans to implement this? So you actually could compose music with your real midi devices.
by matwood | 2026-01-10 09:44:48+00:00
It's not just Italy. The UK is also insane along with some cities in Spain. In the UK one of the rivalries supposedly goes back to the War of the Roses [1].

The way I describe EU football games to Americans is take the craziest student section at a US college football game and extrapolate that energy to the entire stadium.

[1] https://en.wikipedia.org/wiki/Leeds_United_F.C.–Manchester_U...
by dependsontheq | 2026-01-10 09:45:17+00:00
Let's be a bit more honest here, I think the Italian law is badly defined, but I also think the american perspective is wrong.

We (all tech people everywhere me included) argued for a lot of time for free speech on the internet, but the result currently is that we built a system that is free speech for Russian and Chinese bots and actors. In Europe we are under daily attack from Russian accounts that spread massive amounts of desinformation, deep fakes, just emotional appeals with the goal of destroying liberal democracy. The US government is actively trying to support them by fighting against any kind of European rules and spreading their part of desinformation.

This is not about normal politics, Europe is under siege.
by mannanj | 2026-01-10 09:47:24+00:00
Weird question. If a system you are using is intended to extract from you, and unwillfully and nonconsensually stealing your intellectual property because the unaccountable big companies do shady stuff (the "AI" companies) is it justified to use it for the productivity gains because it will 'eventually' get there anyway?

Does the potential gain as an early adopter make it morally ok.

Because thats what these tiered uses of these AI and how it's been getting better works imo. It got lots of training data from juniors and seniors using it the last 2 years, it got better. It gets more appealing and leverages human psychology and marketing to get higher level engineers to train it as it and the companies extract more data. It needs and gets more data from the people willfully complying and using it. Wondering if theres a game theory design for this conundrum - what typically happens in nature in these scenarios?
by wonnage | 2026-01-10 09:47:43+00:00
I think it's mainly that JS has a terrible developer experience when it comes to parallelism and shared data, which these other languages don't need to worry about. Most build tools are pretty amenable to being parallelized but with JS you end up either being constrained to process-level parallelism (e.g split the filesystem into chunks and just run the program multiple times) or you have a bunch of inefficient message passing between processes. Even worker threads are unable to share memory except through the weird and awkward-to-use SharedArrayBuffer and Atomics APIs.

On top of this, a lot of JS tools have crazy plugin systems that let you hook into performance-sensitive places and run arbitrary code. This is slow and also makes parallelism tricky. For example, babel plugins can make arbitrary changes to the AST. Ordering them is already kinda tricky; many plugins just give up and run their entire logic as a callback against the root AST node. The fact that swc, esbuild, etc. come batteries-included with transforms for module syntax, Typescript, etc. actually helps with performance; you can leverage assumptions about these fixed sets of transforms to run them all at once and avoid multiple passes over the entire AST.

So rewriting in a language with better ergonomics and being able to ditch some excessive flexibility is what gets you the massive speedup, it's not just magical Rust dust
by metalman | 2026-01-10 09:48:29+00:00
my stovetop coffee maker is, italian, stainless, somewhat customised, but my braun coffee grinder is the mate to the coffee maker in the article, and almost worn out, though I have a nos one stashed.
my mom had all the braun kichen gear, but as it is all plastic, it inevitably fails in some unrepairable fashion
by RMPR | 2026-01-10 09:48:55+00:00
> For Vim users, I also suggest enabling Vim mode in Zsh. It makes editing commands much faster.

I am also an avid Vim user but I disagree. The default readline is perfectly fine for single line commands (you do have to know your way around some basic commands though C-a/u/k/l/w...). To edit long commands in $EDITOR you can always do C-x C-e in bash/zsh (M-v in Fish). As a matter of fact everytime I pair program with my colleague I always think he is editing those short commands slower than I would have because he has to change modes all the time.
by porcoda | 2026-01-10 09:49:17+00:00
Let's break those links down against "nondeterminism".

- Preprocessor issues are affected by external parameters or state variables (e.g., OS version, current time, etc.). That's not non-determinism. The preprocessor will deterministically do its job, but some of the inputs it is using are dynamic.

- Linkers adding time stamps (or linkers doing other clever things like intentional randomization for vulnerability mitigation). Those are linkers. Not compilers. Linkers typically do not change the semantics of what they are linking.

- "Sometimes repositories contain additional operation that are performed outside of the compilation stage. " Exactly. A source of randomness outside the compiler. Again, not compilers - the person who wrote that was even kind enough to point out that it is "outside the compilation stage".

- Iteration order, sorting order, optimization. Most languages have some level of either undefined behavior, or semantics that leave some flexibility to the compiler. In the case of language features where the compiler can freely generate different code so long as some specified semantics are preserved, this is unpredictability in the generated low-level code (LLVM IR, assembly, etc.), but it is semantics preserving. Undefined behavior is a wart on languages precisely because it is not predictable (hence "undefined"). That is why it is generally avoided. This is also why some optimizations are to be avoided (e.g., -ffast-math) because they produce code that is unpredictable - and the compiler docs make that clear to anyone tempted to use it.

In all of these cases, the compiler itself is not nondeterministic unless it is allowed to be as defined by the language it is compiling or has explicitly informed the user that the code it will generate under specific optimizations will be unpredictable. In the case of most optimization (e.g., not stuff like -ffast-math), it is allowed to generate different code so long as it is semantics preserving. In the case of UB, it's, well, UB - all bets are off as defined by the language definition. The preprocessor and other external factors is also not the compiler's problem - if you make something dependent on something like the current time or date, obviously it's going to vary over ... time - you explicitly told it to. Generated headers? Obviously that's not predictable, and that is NOT the compiler's problem - the headers are inputs to the compiler, and are no different than generating code that varies each time you compile it.

None of these are the same as the nondeterminism that arises in LLMs - that is random (see: temperature parameter on models). It is not predictable, it is not defined as constrained to be semantics preserving, and it is not restricted to the parts of languages that are explicitly undefined. Not the same thing.

It is somewhat disingenuous to compare what amounts to "rand()" involved with code generation in LLMs to uncertainty that is documented, understood, and controllable in compilers.