Hacker Newsnew | past | comments | ask | show | jobs | submit | dualvariable's commentslogin

> It is sad that this has become a topic of the culture wars. Nothing good comes out of this, certainly not a rational weighing of the pros and cons of nuclear power.

For at least the past decade, about all I've seen argued about nuclear is that it is not economical. I've been arguing that for around 15 years now.


People have been arguing nuclear is too expensive and soon renewables will be so cheap they will push fossil fuels out of the grid for 30 years, if not more. Meanwhile during those 30 years, while waiting for the price of renewables to drop sufficiently, the world has built massive amounts of fossil power generation and emissions have been going up and up.

That being said, it seems finally solar+wind+storage+a little bit of other stuff is becoming cheap enough that it's starting to make a dent in the emissions. Which is fantastic, don't get me wrong. But it's also sad we've lost decades.


And nuclear has still sat there being too expensive and solving nothing, proving the point, but apparently this is evidence of the opposite.

My argument was that while waiting for renewables to become cheap, we could have built nuclear instead of fossil capacity and avoided a shitton of emissions. The Messmer plan being an existence proof that such a thing would have been possible.

Renewables passed nuclear a long time ago. If the economics of renewables weren't making sense, the economics of nuclear were worse.

Seems like if you're small enough, a monorepo is the right way to go because it doesn't matter at that scale, and if you're big enough, you'll have the resources to throw at making monorepos scale.

Mono vs poly at scale needs resources. You have different compromises with each and so the resources go to different places. However there is no clear cut winner despite a few mono repo at scale advocates trying to claim otherwise - they are always completely ignoring the issues with a monorepo setup.

Multirepo at scale also needs resources, there's an enormous amount of work required for version bumping and synchronizing everything. People always completely ignore all those chores. Generally, you have either a massive amount of tech debt or you have one person doing nothing but running around doing all that work for everyone else (works great if all that work seems to magically appear for you). You can also be furiously working at automating all those chores, but that's the same level of effort you'd have to throw at scaling out a monorepo--just different.

That was my point - there are issues with both at scale. Trying to pretend that one is better for everyone is wrong. You just choose your tradeoffs.

Exactly because monorepos have least overhead when they’re small, monorepos generally win because you need to be small for a long while until you get big.

By the time you’re “at scale” (who knows), and all these monorepo at scale problems start to overwhelm, you can switch strategy, because the economy of polyrepos is so obvious by then.

So far, I’ve started a new job a handful of times by collapsing a premature polyrepo strategy: people were not experienced enough to merge two git repos without a common root.

I’ve only once went the other way, and it incurred so much overhead, it decreased developer productivity by some small but not insignificant percentage.

To be clear: I’m not a maximalist. All of my open-source work is exceedingly compartmentalised. My DNS library is separate from my external-dns webhook is separate from my fork of external-dns. They could all live in one repo. But FOSS encourages reusability, commercial software encourages clumping and vendoring.


> By the time you’re “at scale” (who knows), and all these monorepo at scale problems start to overwhelm, you can switch strategy, because the economy of polyrepos is so obvious by then.

Conversely to your experience, I have worked at a handful of places who have a monorepo that has been creaking under its own weight for years, but its structure as a monorepo now underpins the business, and so migration to a polyrepo simply never happens, and developers are now checking out a 50GB repo in its entirety periodically.


I'm on the other side of this problem, with a company that went multi repo for bad reasons (political, not technical) and I would give you serious money if you could solve my problems by just forcing me to check out 50gb every now and then...

Instead I deal with a 30+ repo clusterfuck (technically we have 60+ services, but I only have to run half...) that is held together by hopes and prayers, takes literal hours of actual effort to bring everything up to date on master, and has become a fractured hellscape where people are afraid to leave their tightly constrained silos of service combinations.

Long story short... I will take a bad monorepo over bad multirepo any day of the week.


I suspect that your hours of effort to get everything up to date would exist in a monorevel, too. It would exist in a different form, and so it would be harder to measure, but a large part of the work has to be done either way. It's just that certain parts of the work become very visible.

Yeah, compared with the maintenance effort of running around to 100 different repos, keeping everything in sync and the deps all updated, I'd always take the pain of 50GB checkouts.

"Okay, everyone is overworked, and we need you to hire more people for this team. We have too much tech debt, and we can't predict which bit of it will explode next week. The change needs to start with the attitudes of our executive leadership."

Oops, now I'm fired.


Yeah, I think the article assumes the employees doing the work have the leverage to implement the changes themselves. How often is that the case?

>> "The requirements changed three days before launch."

> Of course they did! What happens when requirements change inside the launch window?

What answer is wanted here? "Moving forward, we'll ignore the VP of Marketing's last minute 'must haves'"?


> What answer is wanted here?

"We will be more proactive and agile, and volunteer to work during the entire weekend to keep our customers happy, sir!"

"Good, good, but don't bother me with the details."


"We are under-qualified"

Those metrics don't amount to wisdom. Wisdom is something like realizing that you don't have to special-case some code over <here>, you just need to create a new reusable primitive over <there> that fixes two bugs with one stone, and you'd probably wind up needing it anyway. Both bits of code could sail through all the measurements of code maintainability you could come up with, and an agent suggest to me the brittle solution, but I came up with the more maintainable one.

If AI/LLMs are so great, why isn't Apple using them to better organize all these settings?

Given how bad vibecoded apps are, I would say they do. It is just doing a shitty job.

> it's a spy operation from the KGB.

time-travelling KGB operatives from 1991.


Isn't this proven incorrect by CP-violating processes that also violate T-symmetry (preserving CPT)?

Any regulation will be geared toward protecting the profits of the AI companies, and not toward consumer protection.

Maybe it's time you all voted for people who might change that? It's really amazing to me how on the one hand people in the US seem to crow about democracy all the time, yet also just accept as a fact that their government will never actually work to help them.

I threw money behind getting Bernie nominated over Biden--none of this shit is my fault.

They want to steal all the information in the world to train their models, spend a trillion dollars on the datacenters to do the training, then block open source models under the guise of "AI safety" and jack up the prices to recover all the costs and rack up profits.

Same reason why new cars cost $80k+ in the US and there are 100% tariffs on BYD.

Shitty business models get market protections and a captive market of consumers to fleece.


> Additionally, they've redefined that a pandemic is (removing severity from the definition)

2009 pandemic H1N1 was not severe, and was called a pandemic.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: