MurphyA/hacker-news huggingface dataset:
by pjmlp | 2026-02-06 08:56:34+00:00
They wanted to play and ignored other languages on purpose, that is all.

> Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own.

https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist...

Pity that in regards to secure programing practices in C, community also ignores the decisions of the authors.

> Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions.

Also to be noted that on Plan 9 they attempted to replace C with Alef for userspace, and while the experiment failed, they went with Limbo on Inferno, and also contributed to Go.

And that C compiler on Plan 9 is its own thing,

> The compiler implements ANSI C with some restrictions and extensions [ANSI90]. Most of the restrictions are due to personal preference, while most of the extensions were to help in the implementation of Plan 9. There are other departures from the standard, particularly in the libraries, that are beyond the scope of this paper.

https://doc.cat-v.org/plan_9/4th_edition/papers/compiler
by lelanthran | 2026-02-06 08:56:45+00:00
> We don't call architects 'vibe architects' even though they copy-paste 4/5th of your next house and use a library of things in their work!

Maybe not, but we don't allow non-architects to vomit out thousands of diagrams that they cannot review, and that is never reviewed, which are subsequently used in the construction of the house.

Your analogy to s/ware is fatally and irredeemably flawed, because you are comparing the regulated and certification-heavy production of content, which is subsequently double-checked by certified professionals, with an unregulated and non-certified production of content which is never checked by any human.
by imtringued | 2026-02-06 08:56:59+00:00
Yeah this is one of the weirdest takes ever.

"If you already know, terrific—but what are you meant to do if you don’t?"

You're supposed to look at the first gif that visualizes a waveform diagram. How are HDL designs tested? Testbenches (akin to unit tests) and model checking. With model checking you define the property you want to test and the model checker will try to find a counter example.

Said property is so obvious for fibonacci, that it is staring right at your face and you're consciously trying to avoid looking it in the eyes. Fibonacci is defined as fib(n) = fib(n-1) + fib(n-2), so that's what you need to test. This means you can simply test fib(1) = 1, fib(2) = 1, fib(3) = 2, for a fixed set of n to cover the edge cases, then choose a fixed set of random n and make sure that fib(n) = fib(n-1) + fib(n-2) is true. Obviously the only way to be 100% sure is to use a model checker and write code that is bounded in its runtime.
by tpm | 2026-02-06 08:57:05+00:00
> XE can be used for free

> XE has hard limits on size and limits on active CPUs

So no, it can't be used for free, you will pay for that with your time to keep it in usable state. We had to use it as our dev dbs because our customers used it and the size limit was a huge PITA. We mostly use MSSQL as dev db now because the other half of customers use that (we have to support both in the end) and it is way worse in every other way but there is no size limit for dev use.
by tirant | 2026-02-06 08:57:46+00:00
Fully agree on the root cause, but not on the solution.

We should strive for extremely limited power by our public representatives, so their corruption impact is reduced to a minimum. But not only limited power, but also limited budget access, as an extension to limit that power. And that actually means reduced taxation.

But at the same time, the budget for justice system needs to increase. It should be most probably the strongest branch of the government. Delayed justice is one of the most common ways of injustice.

Corruption within private companies is irrelevant, as the main ones to suffer from it are usually shareholders. Government has no say in that. That is unless companies break the law, and that's why a strong Justice system is necessary. With a reduced size of the state there's also way less risk of private companies and individuals to corrupt public representatives.

Monopolies are not always a negative outcome on a free market if the company in Monopoly situation reaches that position by offering better products within the law. However they can be specially dangerous when they're artificially created by the Government (e.g. allocation of a common resource to a specific company --> corruption almost always follows).
by wiseowise | 2026-02-06 08:57:46+00:00
> AI changed all of that. My low-effort issues were becoming low-effort pull requests, with AI doing both sides of the work. My poor Claude had produced a nonsense issue causing the contributor's poor Claude to produce a nonsense solution.
The thing is, my shitty AI issue was providing value.

Seems like shitty AI issue did more harm than good?
by HelloUsername | 2026-02-06 08:57:48+00:00
Previous discussions:

2023: https://news.ycombinator.com/item?id=38059961

2023: https://news.ycombinator.com/item?id=37514601

2022: https://news.ycombinator.com/item?id=31290789

2021: https://news.ycombinator.com/item?id=28988778

2017: https://news.ycombinator.com/item?id=15427848

2015: https://news.ycombinator.com/item?id=9595507

2013: https://news.ycombinator.com/item?id=6309696

2010: https://news.ycombinator.com/item?id=1494999

2009: https://news.ycombinator.com/item?id=776381
by repelsteeltje | 2026-02-06 08:58:21+00:00
> Also, the other side of it is that evolutionary projects are just more fun. I’ve preferred them. You’re not loaded down with all those messy dependencies. Way fewer meetings, so you can just get into the work and see how it goes. Endlessly arguing about fiddly details in a giant spec is draining, made worse if the experience around you is weak.

IMO the problem isn't discussing the spec per se. It's that the spec doesn't talk back the way actual working code does. On a "big upfront design" project, there is a high chance you're spending a lot of time on moot issues and irrelevant features.

Making a good spec is much harder than making working software, because the spec may not be right AND the spec may not describe the right thing.
by vanillameow | 2026-02-06 08:58:30+00:00
> If writing the code is the easy part, why would I want someone else to write it?

Exactly my takeaway to current AI developments as well. I am also confused by corporate or management who seem to think they are immune to AI developments. If AI ever does get to the point where it can write flawless code, what exactly makes them think they will do any better in composing these tools than the developers who've been working with this technology for years? Their job security is hedged precisely IN THE FACT that we are limited by time and need managed teams of humans to create larger projects. If this limitation falls, I feel like their jobs would be the first on the chopping block, long before me as a developer. Competition from tech-savvy individuals would be massive overnight. Very weird horse to bet on unless you are part of a frontier AI company who do actually control the resources.
by bob1029 | 2026-02-06 08:58:32+00:00
Carrying things on your head/shoulders is surprisingly efficient. Many people can unrack a barbell with double their body weight and just stand there for a bit without having done any strength training at all. The trouble is getting the load into that convenient orientation. Taking something from the ground and putting it over your own head is where all the bad stuff happens. Once it's up there it's not as big a deal.

You can make yourself bulletproof to most forms of hard physical labor by practicing the clean & jerk. This movement is entirely about "get heavy thing off ground and above head" as efficiently and safely as possible. There are advanced movements that can be even more efficient but you trade some injury risk for screwing up. That is to say, the actual amount of wear on your body is even lower if you really know what you're doing.
by qznc | 2026-02-06 08:58:42+00:00
> There are two main schools of thought in software development about how to build really big, complicated stuff.

That feels like a straw man to me. This is not a binary question. For each small design decision you have a choice about how much uncertainty you accept.

There are no "two schools". There is at least a spectrum between two extremes and no real project was ever at either of the very ends of it. Actually, I don't think spectrum is a proper word even because this is not just a single dimension. For example, speed and risk often correlate but they are also somewhat independent and sometimes they anti-correlate.
by pjmlp | 2026-02-06 08:58:45+00:00
> Unix wasn't the first operating system to be written in a high-level language. The Burroughs OS was written in Algol, Multics was written in PL/I, and much of VMS was written in BLISS. None of those languages became popular.

Of course, they weren't available as free beer with source tapes.

> Apple replaced the original Macintosh OS with a system based on a Unix.

Only because they decided to buy NeXT instead of Be.

Had they bough Be, that would not been true at all.
by klempner | 2026-02-06 09:00:09+00:00
This document being from 2010 is, of course, missing the C11/C++11 atomics that replaced the need for compiler intrinsics or non portable inline asm when "operating on virtual memory".

With that said, at least for C and C++, the behavior of (std::)atomic when dealing with interprocess interactions is slightly outside the scope of the standard, but in practice (and at least recommended by the C++ standard) (atomic_)is_lock_free() atomics are generally usable between processes.
by TrendSpotterPro | 2026-02-06 09:00:26+00:00
Discover another instant gaming spot: https://t3.baent.top!

Jump straight into a variety of fun, no-download HTML5 games. Perfect for a quick and easy play session anytime.

Click and play instantly:
https://t3.baent.top

#HTML5Games #FreeGames #InstantPlay #BrowserGames #QuickBreak #NoDownload #OnlineGames #T3Games
by pjmlp | 2026-02-06 09:00:28+00:00
The irony is that all wannabe C and C++ replacements are exactly the "Pascal model" brought back into the 21st century, go figure.

"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."

-- C.A.R Hoare's "The 1980 ACM Turing Award Lecture"
by pjmlp | 2026-02-06 09:01:21+00:00
No it had not,

> Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own.
by aucisson_masque | 2026-02-06 09:01:22+00:00
Substance abuse and rest.

If you lift weights Monday and Friday, you give your body time to recover and get stronger.

People whose job is to lift weight, they don't lift things heavy enough and they don't give their body time to recover. They work everyday, whatever if their quads are hurting or not. It has very little benefits and only destroy the joints.
by Markoff | 2026-02-06 09:01:45+00:00
I was not big fan of Liveleak, but I really enjoyed WatchPeopleDie community, one could learn a lot in the comments about how to be safer in the enviroment (I'm aware they moved to website, but it's not same anymore, too much friction to visit it)

after being the regular visitor of WPD I stand at the junction waiting for my turn shielded by the traffic lights pole and always look in the eye of the driver when crossing the road, especially if it's tall truck

some ppl don't realize how many lives actually WPD saved, but hey now we have victory nobody is exposed to this disturbing content and making silly jokes about death, right?
by pooper | 2026-02-06 09:01:46+00:00
> The fact is allowing any type of unsigned update on HTTP is a security flaw in itself.

Reminds me about ten years or so ago when I was installing Debian or something and I noticed the URL for the apt install mirrors were http and not https. People helpfully pointed out this is a non issue because the updates are signed.

Ok I guess but then why did Debian switch to https?
by somenameforme | 2026-02-06 09:02:19+00:00
Deporting illegal aliens as literally every single country in existence does has no need of justification. You're the one that needs to justify claims of deporting people, for free, back to their home country as being an 'unjustifiable genocide', but in the end that's fundamentally illogical which leaves you with hyperbole, misrepresentation, and of course these sort of semantic games.
by frankharrison | 2026-02-06 09:02:39+00:00
If you're at a games studio that values build-times, value that. I worked at a very good SRE-mindset studio and missed it, deeply, after I left. Back then I expected everyone to think and care about such things and have spent many, many hours advocating for best-in-class, more efficient, cheaper development practices.

WRT github actions... I agree with OOP, they leave much to be desired, esp when working on high-velocity work. My ci/cd runs locally first and then GHA is (slower) verification, low-noise, step.
Ask HN: Do you use LLM memory features?
by grigio | 2026-02-06 09:03:33+00:00
I've been experimenting with AI assistants and their "memory" features, but I'm finding them opaque and unreliable.

Instead, I've switched to keep important context in .md files that I explicitly reference when I need or when I have to recall them. This gives me:

Full visibility into what's in context
No mystery recalls from weeks ago
Easier debugging when behavior drifts
Predictable token usage
The downside is manual maintenance, but it feels more reliable than hoping the system remembered correctly.

Do you use built-in memory features? Or do you manage context explicitly through files/RAG/other methods? What's working for you?
by thombat | 2026-02-06 09:04:10+00:00
Indeed, this is such a central point that it's made clear in the first chapter:

The
telescreen received and transmitted simultaneously. Any sound that Winston
made, above the level of a very low whisper, would be picked up by it,
moreover, so long as he remained within the field of vision which the metal
plaque commanded, he could be seen as well as heard. There was of course
no way of knowing whether you were being watched at any given moment. How
often, or on what system, the Thought Police plugged in on any individual
wire was guesswork. It was even conceivable that they watched everybody all
the time. But at any rate they could plug in your wire whenever they wanted
to. You had to live--did live, from habit that became instinct--in the
assumption that every sound you made was overheard, and, except in
darkness, every movement scrutinized.

Remarkable that Asimov could overlook this.
by bpev | 2026-02-06 09:05:06+00:00
I’ve used many brands of these at various price points (and also usb-c headphones). They work fine for like a month, but the connection degrades over time (maybe it wears out or gets dirty?), and I haven’t found a way to recover stability once it starts to randomly disconnect. It’s super annoying because when it disconnects, the software doesn’t handle it well, and I usually have to unplug it, plug it back in, unpause the music, and hope it doesn’t do it again as I gingerly place it back in my pocket. Basically, I think that USB-c is just not as consistent or sturdy of a port when you’ve got the playback device moving around in your pocket.
by anupamchugh | 2026-02-06 09:05:49+00:00
I've been thinking about this as three maturity levels.

Level 1 is what Mitchell describes — AGENTS.md, a static harness. Prevents known mistakes. But it rots. Nobody updates the checklist when the environment changes.

Level 2 is treating each agent failure as an inoculation. Agent duplicates a util function? Don't just fix it — write a rule file: "grep existing helpers before writing new ones." Agent tries to build a feature while the build is broken? Rule: "fix blockers first." After a few months you have 30+ of these. Each one is an antibody against a specific failure class. The harness becomes an immune system that compounds.

Level 3 is what I haven't seen discussed much: specs need to push, not just be read. If a requirement in auth-spec.md changes, every linked in-progress task should get flagged automatically. The spec shouldn't wait to be consulted.

The real bottleneck isn't agent capability — it's supervision cost. Every type of drift (requirements change, environments diverge, docs rot) inflates the cost of checking the agent's work.

Crush that cost and adoption follows.
by Lemaxoxo | 2026-02-06 09:06:08+00:00
Hello HN. 5 years ago I posted an article about text classification via data compression. I got helpful and educative comments in response. Now that Python have shipped zstd in 3.14, I thought it would be time to revisit this approach. The throughput figures are much better. This means you can do baseline machine learning with Python's standard library!
by Symbiote | 2026-02-06 09:06:10+00:00
You can ask an AI or StackOverflow or whatever for the correct way to start a standby replica, though I think the PostgreSQL documentation is very good.

But if you were in my team I'd expect you to have read at least some of the documentation for any service you provision (self-hosted or cloud) and be able to explain how it is configured, and to document any caveats, surprises or special concerns and where our setup differs / will differ from the documented default. That could be comments in a provisioning file, or in the internal wiki.

That probably increases our baseline complexity since "I pressed a button on AWS YOLO" isn't accepted. I think it increases our reliability and reduces our overall complexity by avoiding a proliferation of services.
by dhruv_ahuja | 2026-02-06 09:07:34+00:00
Hi HN,

I had recently done a write-up on OpenTelemetry baggage, the lesser-known OpenTelemetry signal that helps manage metadata across microservices in a distributed system.

This is helpful for sending feature flags, parameter IDs, etc. without having to add support for them in each service along the way. For example, if your first service adds a `use_beta_feature` flag, you don't have to add logic to parse and re-attach this flag to each API call in the service. Instead, it will be propagated across all downstream services via auto-instrumentation, and whichever service needs it can parse, modify and/or use the value.

I'd love to discuss and understand your experience with OTel baggage or other aspects you found that maybe weren't as well-discussed.
by Gioppix | 2026-02-06 09:08:29+00:00
Location: Italy

Remote: yes, though prefer in-person

Willing to relocate: US (preferred), EU

Technologies: TypeScript, Node, Rust, Kubernetes, Terraform, PostgreSQL, ScyllaDB, SvelteKit, LLM Agents

Résumé/CV: https://www.linkedin.com/in/feltrin-giovanni/

Email: info <a> giovannifeltrin.com

Exited founder & former Tesla intern dropping out of Masters to build.

Kuba Labs (Founder/Exit): Built/scaled e-com automation platform & an "omniscient" AI agent with complex tool use.
Tesla: Led a major internal migration to TypeScript + implemented observability.
Infra: Built autoscaling K8s clusters & Rust HA monitors for fun.

I own the stack from metal to product. Looking for a high-intensity pre-Seed/Seed team.
by vanillameow | 2026-02-06 09:08:41+00:00
I mean I understand that you want your business to not fall behind right now, sure. But I don't understand people in management who are audibly _excited_ about the prospect of these developments even behind closed doors. I guess some of them imagine they are the next Steve Jobs only held back by their dev teams, but most of them are in for a rude awakening lol. And I guess a lot are just grifting. The amount of psychotic B2B SaaS rambling on Twitter is already unbearable as is.
by aucisson_masque | 2026-02-06 09:08:50+00:00
> L’agriculture européenne, en revanche, risque d’être pénalisée. Selon les dernières estimations effectuées en décembre 2020 par la London School of Economics pour le compte de l’Union européenne, l’accord pourrait faire baisser jusqu’à 1,2 % sa production de viande de bœuf et de mouton, et 1 % celle de sucre.

Déjà je met en doute les 1,2%. C'est une estimation... Mais surtout, c'est pas sur la baisse de production immédiate que ça va se jouer mais sur les prix. 1kg de boeuf vendu pour 70% du prix d'un kg français, ça va pousser les prix vers le bas.

Avec 30 fermes en moins chaque jours, ça va accélérer fortement la perte de production agricole et donc notre souveraineté.

Je suis content de voir que ton lien confirme mon propos.
by globular-toast | 2026-02-06 09:09:10+00:00
This is probably about extremes being bad. Having an extremely sedentary lifestyle is bad, but also having an extremely strenuous one is bad too.

I used to lift weights regularly. I'd go to the gym three times a week for an hour or two at a time. I'm pretty strong naturally and thought my training was going quite well being able to bench 1.5x my bodyweight, squat and deadlift more than 2x etc.

Then I paid some guys to move house for me. Actually, my job paid, I have still yet to pay for this service myself. They were lifting whole chests of drawers without even emptying them. It was crazy. I've since done plenty of this work myself (moved house three times by myself), but I do take the drawers out etc. Basically I work more intelligently and take more time.

What the moving guys were doing is harder, less safe, and they are doing this day in, day out. Add to that poor diets (both seemed to be fuelled on crisps, Coke and fags) and the differences become more clear.

So, like with anything, don't be too extreme. Too much heavy lifting will be just as bad for you as too little.
by radarsat1 | 2026-02-06 09:09:11+00:00
Additionally it's not like you're constrained to write it in bash. You could use Python or any other language. The author talks about how you're now redeveloping a shitty CI system with no tests? Well, add some tests for it! It's not rocket science. Yes, your CI system is part of your project and something you should be including in your work. I drew this conclusion way back in the days where I was writing C and C++ and had days where I spent more time on the build system than on the actual code. It's frustrating but at the end of the day having a reliable way to build and test your code is not less important than the code itself. Treat it like a real project.