MurphyA/hacker-news huggingface dataset:
by AgentME | 2025-07-23 06:26:31+00:00
I think Rust is a bad example, but I think the general idea that the design of a programming language can help with the weaknesses of LLMs makes sense. Languages with easy sandboxing (like Deno where workers can be instantiated with their own permissions) or capability-based security could limit the blast radius of LLM mistakes or insecure library choices made by LLMs, while also giving similar benefits to human programmers and code reviewers.
by oc1 | 2025-07-23 06:26:37+00:00
It's funny as i get older to see how all these patterns just repeat themselves. When i started out i worked in a team that used subversion and it was by default trunk-based development flow. no code reviews except the single big changeset from all devs. it was how things were done back then by many teams. Then there was a shift towards feature-request-based development with the rise of git and github. trunk-based development was now seen as "unprofessional" in corporate. totally fine and i was there to teach this mind shift.

while the feature-branch-based flow solved some problems it introduced many more like stall branches and out-of-sync code. this became the default as most devs simply weren't aware or had the discipline to merge early and cut their "tickets" to an appropriate size.

mostly for compliance reasons in corporate and big teams i would still advise feature-request-based flow. but as another colleague noted here - it slows you down and if it's a one or two people shop / product you will reap more benefits by doing basic trunk-based flow.
by bob1029 | 2025-07-23 06:27:09+00:00
If the whole team is available in one physical office, a centralized model like perforce can run circles around the various git flows. You typically see this in places like game development.

Being able to lock files centrally is a massive advantage as long as you have to be at the office to do it. This forces conflict resolution in a much more direct and immediate way than the passive aggressive PR submissions that are eventually reviewed for conflicts after all parties have already burned untold amounts of energy on potentially unmergable code.
by seec | 2025-07-23 06:27:25+00:00
Germany also generates very little electricity from solar in the winter, use quite a bit of coal plant and imports multiple Twh from its neighbors in the worst months.

So yeah sure, it can pretend to be ahead on green tech, as long as France invests in nuclear and sell it cheap electricity in the winter when it is most needed and most expensive.

I am so tired of the bullshit about Germany "success", I think they should be disconnected from the EU grid so they can walk the walk before talking the talk.
by stpedgwdgfhgdd | 2025-07-23 06:27:31+00:00
It probably depeds on the kind of software you create, but in our case:

When i add non-trivial code I want others of my team to review it first. When it is on trunk, it gets less easier to refactor as others already might use it. In this sense using a MR is really good way to get some quality checks before it goes to main and needs to be supported (in most cases) indefinitely. Next, we have system tests that i really want to avoid breaking on main and getting EVERYONE stuck.

The problem arises if I keep that branch for more than a week. Merge conflicts get harder, the financial investment is not leveraged, etc etc.

The problem is with long lived branches. This is something you should avoid, you can take it to the extreme, no branches. But extreme is almost never good.

PS CC is really good at rebasing and resolving merge conflicts.
by fsckboy | 2025-07-23 06:28:05+00:00
the stock market returns on average 7%. a 50% tax on on income means the stock market effectively returns 3.5%

a wealth tax of 1% reduces the return on the stock market for that year to 6%, but it compounds onto follow-on years; if you "wealth tax" every year, that effectively lowers the return on the market very dramatically. If the returns on the stock market are lowered dramatically, you will see a huge slowdown in the economy.

the point of this is, there isn't really such a thing as a "wealth tax", it's just a "multiplied income tax". it might be different in your head, but you're wrong, it's not different in reality. you are welcome for the free education.

the question is, why is the only thing you can think of "take money from people who have it". that's a zero sum game, no wealth creation. What makes market economies so wonderful to live in is their wealth creation.

Why does Elon have so much money? wealth creation. Here's why: without Tesla, the roads would not be empty of cars, people would just buy different cars. There are other car companies, GM, Ford, Nissan, Honda, Volkswagen, etc.

Tesla is not taking your money. Tesla is offering an alternative car to buy with your money. With no Tesla, you would plunk your money down on one of those other brands, but if you like Tesla's better, you buy one of those. That creates happiness, you are happier spending your money on a Tesla than on the alternatives. That's the money that Elon is collecting, GM's money and some extra for your excitement/satisfaction. And he deserves it because he created it and you are happy that he did. You would not be richer without Tesla. You would buy a different brand, and be out the same amount of money, and enjoy your car less. So when you think "we need to take Elon's money" you are essentially saying "I wish Elon didn't exist and I want the crappy Nissan for less money". That's a spiral into the ground because the other company's don't put as much value into their cars as Tesla and if you paid them less, they'd produce less.

If your response to this is "I would never buy a Tesla, I don't even like them", then I will just shake my head sadly at your inability to learn even more.
by ZenoArrow | 2025-07-23 06:28:48+00:00
> These older districts were also doubtless considered bland and character-less when built.

It's not about the buildings, it's about the human interactions. The buildings that replace the ones at risk may be more aesthetically pleasing, but it seems very unlikely to support something that is as interesting to visit as what they currently have in that area. Gentrification rarely leads to a blossoming of culture.
by ropable | 2025-07-23 06:28:51+00:00
Good article, but I found it a little too abstract to derive much actionable information. IMO the most useful point is this quote:

So when you encounter someone whose worldview seems impenetrable, remember: you’re not just arguing with a person, you’re engaging with a living, self-stabilizing information pattern—one that is enacted and protected by the very architecture of human cognition.
by wirrbel | 2025-07-23 06:29:40+00:00
> I think this is a very lopsided way of looking at pull requests. They are about a lot more than just trust. Reviewing and being reviewed is a great way of learning from colleagues, making common practices gel in a team, and keeping up to date with changes to the codebase. It’s not just a barrier.

I am old enough that my first 2 jobs were subversion-based (repo side, client side git-svn) and both teams didn't care about branching. It might have to do with how awkward subversion branches felt.

Anyway, we would commit (in git lingo pull-rebase & commit) directly and we basically maintained the id of the last reviewed commit and jointly did PR reviews commit-by-commit with the code on the projector in the office.

We had a joint look at code, everyone voiced their feedback ("I don't understand a variable name like `xzc`"), "where is the unit test", "I read in a blog post recently you are supposed to not use classes...". etc. pp. Sometimes fixes would be pushed right in the PR review session so you had the variable renamed 4 commits further.

Anyway, in retrospect it worked surprisingly well at helping the team to develop a joint understanding of values & virtues that the team would like to maintain in their code base. This might of course be nostalgia of a dev looking back into their junior years.

When we finally got pull-requests, we really felt thrown into the future. It was just great. But after a while I started to miss the direct conversations about code with fellow humans.

And honestly I couldn't tell whether PR really improved the quality of the code base in the long run. They lowered the probability of bad code being committed to the code base, but also lowered the probability for a dev to just fix awkward things while they stumbled over them.
by tomhow | 2025-07-23 06:29:43+00:00
> Politely, stop peddling horseshit.

You can't comment like this on Hacker News, no matter what you're replying to.

The comment you're replying to would be easy to respond to with a link containing refuting evidence. We understand this topic is an important one, and one that people get passionate about. But any topic that's important deserves to be discussed with solid evidence rather than personal abuse. Please make an effort to observe the guidelines if you want to keep commenting here.

https://news.ycombinator.com/newsguidelines.html
by crinkly | 2025-07-23 06:29:53+00:00
I wonder how all these absolutist methodologies really work when you take subjectivity and our general inability to measure anything reliably away? I say this because we've tried all of them after someone read an article on a blog saying it'd solve all our problems. And we always have the same problems afterwards despite people promoting that it solved them. Sometimes even worse ones.

The root cause in my company is we hire the lowest cost outsourcing outfit we can find, which hires inexperienced juniors and pretends they are senior and has a huge staff turnover because who the hell wants to work like that for more than 12 months. But of course changing the repo structure and process will compensate for that.

My observation is that a good engineering team will self-organise a methodology that works. The methodology is unimportant compared to getting a good engineering team. I am fortunate that I work in a small niche pocket in the organisation that has good engineers and has resisted normalising with the process churn of the rest of the organisation.

We run a "dark ages" team really. We were on SVN until 2020-ish, because, well it worked fine for us. Now we're on github on commandment but it is used like SVN. We have light feature branches. Master is always stable. Releases are tagged off master. At no point do we use any other github features not even PRs. CI is makefiles. Push to ECR/S3 by human. Deployment is makefiles. Comms is email because Slack is too distracting and demands immediacy. Issue tracking is a 17 year old JIRA project with a default workflow. We have the lowest defect rate, the lowest time to market and highest ROI per head in the entire org and we don't have or need a platform/sre/devops team supporting us.

We are a disliked because we didn't do anything for over 10 years other than deliver software.
by notpushkin | 2025-07-23 06:29:58+00:00
Kagi, PurelyMail, and a VPS of your choice to host everything else you might need (I’ve settled on SSDNodes [1], good performance and pretty cheap). Probably also something for backups (Backblaze B2 or rsync.net seem decent).

[1]: https://ale.sh/r/ssdnodes (affiliate link)
by seszett | 2025-07-23 06:30:23+00:00
Radon is measurable, my CO2 detector also mesures radon. There is none in my well-insulated house.

Now in a basement in Brittany things would be different, but for most houses in most places, radon is negligible.

There also isn't a notable difference in cancers between radon-rich granitic places like Brittany and the rest of France. I feel like at least in France, the potential dangers of radon are well known.
by Disposal8433 | 2025-07-23 06:30:32+00:00
You misunderstood everything to the point I think you're doing it on purpose.

I like TBD, but the article is NOT about TBD.

> are you saying I just imagined

I use TBD for everything and I like it. I was talking about the writer of the article, not you. The article is, again, NOT about TBD and the writer, most likely an overpriced consultant, is very confused about branching strategies, and most likely believe that a daily standup or some pair programming is part of that strategy. His other articles confirm this.
by anotherpaul | 2025-07-23 06:31:34+00:00
Yes, I was also stumped by the use of windows and then even the use of windows shell. Seems like asking for trouble.

But I am glad they tested this, clearly it should work. In the end many more people use windows than I like to think about. And by far not all of them have WSL.

But yeah, seems like agents are even worse when they are outside of the Linux-bubble comfortzone.
by lstamour | 2025-07-23 06:31:53+00:00
Good points. And it probably isn’t formaldehyde. The only thing I’ll add is that formaldehyde can inhibit or kill bacteria. And I also recently learned the hard way that limonene or other terpenes (from fruits or cleaning products or air fresheners for example) can react with ozone and produce formaldehyde even in the absence of combustion. And I’ve a strong opinion now that science and society ignores the dangers of formaldehyde and VOCs about as much as we used to ignore germs and other things we can’t usually see. Until heat pumps with fresh air exchanges are considered standard or specified by housing code, we will probably always have to deal with VOCs as we don’t have an accurate way to measure them and identity their sources except in industrial contexts. Saying this because while an open window is the cheapest way to get fresh air, it often isn’t the temperature or humidity we expect.
by zabil | 2025-07-23 06:32:36+00:00
Used trunk-based dev a lot. Not a fan. It sounds good on paper, but in practice, it gets messy fast and code quality is hard to maintain, especially when teams are remote.

What actually works is trunk-based deployments — keep main always deployable, and ship from there. Simple.

PRs, are underrated. They’re great for sharing context. You get inline comments, CI runs, you can test stuff in isolation by spinning up infra, and teammates actually see what’s changing.

Stacked diffs make juggling multiple PRs manageable. And yeah, PR reviews can slow you down, but honestly, I think that's a plus. Slowing down just enough to have another human look at the code pays off more often than not.
by minebreaker | 2025-07-23 06:32:43+00:00
I don't know. I started my career as a Java dev, but what made me grow as a software developer was learning Scala. I learned a lot about functional programming, algebraic data types, effects, and so on.

I'd say Java is a great production language, mostly because it's so simple that I don't need to "learn" it (when you know better than using madness like `==` or Serializable).
by JNRowe | 2025-07-23 06:32:47+00:00
There is even a Damien Hirst¹ haphazardly spread about the surface for that purpose.

One of the great gifts Pillinger² had was being able to shake up public interest via pop culture; there was also call sign by Blur for Beagle 2.

¹ https://www.researchgate.net/figure/Spot-Painting-Beagle-2-C...

² https://en.wikipedia.org/wiki/Colin_Pillinger
by KronisLV | 2025-07-23 06:34:03+00:00
> I'm most excited for the smaller sizes because I'm interested in locally-runnable models that can sometimes write passable code, and I think we're getting close.

Likewise, I found that the regular Qwen3-30B-A3B worked pretty well on a pair of L4 GPUs (60 tokens/second, 48 GB of memory) which is good enough for on-prem use where cloud options aren't allowed, but I'd very much like a similar code specific model, because the tool calling in something like RooCode just didn't work with the regular model.

In those circumstances, it isn't really a comparison between cloud and on-prem, it's on-prem vs nothing.
by illiac786 | 2025-07-23 06:34:40+00:00
It’s called the waterbed effect and is an oversimplification actually. The pollution is not simply modeled with theses credits, there’s more to it.

The waterbed effect is something often cited, even by environmentalists, especially economists that think they have modelled pollution and feel obligated to publish a book about it, I noticed.

To be clear, I am not saying you are either of these things, just putting some context around the concept. I fell hard for the waterbed effect but I came back from it =)
by jonplackett | 2025-07-23 06:36:00+00:00
This is comparing BUYING a new gas car to BUYING a new electric car.

I already have the gas car from 8 years ago.

From what I can tell keeping this is way better than buying any new car - of course if I do buy a new one it’ll be electric. But keeping an existing car uses way less co2 than buying a new one.
by almosthere | 2025-07-23 06:36:26+00:00
I pay for GH Copilot, but mostly because I haven't bothered to stop. I'm probably going to switch to paying for Cursor.

I used to pay for the following:

* Home Designer Pro (upgraded to fully purchased at some point) * JRebel (circa 2010ish)

I will never pay for

* Youtube Premium
by jrflowers | 2025-07-23 06:36:40+00:00
> Whatever you need to tell yourself to keep eating meat buddy.

I’m not the one that brought up moralizing or food. I can’t really comment on your relationship with your diet but it kind of seems like you saw somebody mention power usage and unprompted shared “well I don’t eat meat or cheese or yogurt” so I guess keep that up while you use enough energy to power your home to write some code slower than you would without it?

https://www.infoworld.com/article/4020931/ai-coding-tools-ca...

I gave a little more detail to my point about climate impact here

https://news.ycombinator.com/item?id=44654552
by vixen99 | 2025-07-23 06:37:35+00:00
Interesting that this is happening in concert with "a persistent and widespread increase of growing season integrated LAI (greening) over 25% to 50% of the global vegetated area, whereas less than 4% of the globe shows decreasing LAI (browning)."

The paper suggests "CO2 fertilization effects explain most of the greening trends in the tropics, whereas climate change resulted in greening of the high latitudes and the Tibetan Plateau. LCC contributed most to the regional greening observed in southeast China and the eastern United States. "

https://www.nature.com/articles/nclimate3004
by Kon5ole | 2025-07-23 06:37:59+00:00
>This comparison makes no sense at all since both factors: the huge delays for nuclear and small delays for solar are direct results of policy

It's not policy it's physical logistics. Just building the roads to the site where you want the nuclear plant takes months and it's hard to transport anything else to the site before you have those.

You also need to sign thousands of workers who need to be physically on location, meaning you need housing, parking, plumbing, salary administrators, doctors, catering, janitors etc.

Solar is entirely trivial by comparison. Any small town has enough carpenters and electricians to assemble megawatts of capacity in weeks. Which is why it grows so much faster than anything else.
by lelanthran | 2025-07-23 06:38:13+00:00
> And nonsmoker cancers are a nontrivial proportion since they account for 10-25 percent of lung cancer worldwide, please just read the article.

I read the article, but I can't tell if there's a real problem or not. Having "nonsmokers accounts for 10% - 25% of lung cancer worldwide" doesn't leave me any wiser or more informed. Maybe I missed it in the article, so the rest of my comment is pointless, but ...

What's the percentage of lung cancer in nonsmokers? 10% of the pop? 1%? 0.00001%? Whatever the answer is, why isn't it in the article? Then we can see what "10% - 25% of $BASE_RATE" actually is. If we're seeing "10%-25% of 0.0001%", then that sorta tracks as fine, TBH.

The article seems almost designed to mislead: What's the base rate of lung cancer in nonsmokers? What's the base rate of lung cancer in smokers?

For example, if the base rate of lung cancer in smokers is 25% and the base rate of lung cancer in nonsmokers is 0.1%, then I don't see a problem here; funds directed to eliminating the remaining causes of lung cancer will be better spent on other research.

OTOH, if the base rate of lung cancer in smokers is 25% and the base rate of lung cancer in nonsmokers is %15, then I see a real problem here: maybe we need to direct more research funds towards lung cancer[1].

My expectation is that, with smoking so rare, lung cancer in the combined population must be very low, compared with the time when smoking was not rare.

-----------------------------------

[1] Actually the problem is worse than that: if there was a singular cause for that 15% in my example, then we it would have been cheaper to target that cause instead of spending dollars reducing smoking.
by mk89 | 2025-07-23 06:38:35+00:00
The nice thing about democracy and politics in general is that everyone can have an opinion and a way to see something.

Many MAGA hats don't all mean the same. I doubt all of his supporters like the tariffs, or how he is dealing with Russia, or Israel, or, or or...

However, I believe that some of the core policies (hard on immigration, etc) somehow find a common agreement. And even in those core policies, some might like different approaches. And yet in total they do feel they support this administration.

The issue is when people let all happen because one of the core problems must be solved at all costs. Meaning the administration solves that one core problem you really wanted fixed, but the price to pay is equally bad, and yet you just look down and let it all happen, because it's convenient and doesn't affect you in the short term.

In my opinion, this has become more and more common with whichever party we elect, except some are more vocal about it than others.
by ravirajx7 | 2025-07-23 06:38:41+00:00
I’ve been working as a backend developer for close to six years now, but reading this brought me right back to college.

Like many others, I started with C. It taught me the basics - memory, pointers, writing data structures from scratch - but most of the time it felt like I was just trying not to break things. Solving problems became more about handling the language than understanding the logic.

Then I came across Java, and something just clicked. It felt structured, readable, and intentional. Almost like reading good English. For the first time, I could focus on the actual problem instead of building the tools to solve it. Collections, built-in libraries, and a reliable runtime made coding feel productive, not just painful.

Even now, years later, Java still feels like home. It’s not perfect, but it gave me the space to learn, grow, and build things that last. I really appreciated this article - it captures that quiet strength Java has, and the care so many people have put into making it better over time. It reminded me why I still enjoy writing Java after all these years.
by yorwba | 2025-07-23 06:38:43+00:00
Johnson-Lindenstrauss is an example of a probabilistic existence argument: the probability of a random projection having low error is nonzero, therefore a low-error projection must exist. That doesn't mean any given random projection can be expected to have low error, although if you keep rerolling often enough, you'll eventually find one.

The existence argument does only provide a lower bound on the number of dimensions that can be represented with low error, but there's not necessarily much room for improvement left.
by globular-toast | 2025-07-23 06:39:19+00:00
We learn natural languages by listening and trying things to see what responses we get. Some people have tried to learn programming the same way too. They'd just randomly try stuff, see if it compiles then see if it gives what they were expecting when they run it. I've seen it with my own eyes. These are the worst programmers in existence.

I fear that this LLM stuff is turning this up 11. Now you're not even just doing trial and error with the compiler, it's trial and error with the LLM and you don't even understand what it's output. Writing C or assembly without fully reasoning about what's going on is going to be a really bad time... No, the LLM does not have a working model of computer memory, it's a language model, that's it.