Hacker News Reader

Comment by torben-friis | Hacker News Reader

This idea of "here's the beta, I'll release the code in a few weeks" sounds counter intuitive to me. is it normal in open source? Any reason for it?

View on HN

In the past, we've done that because we've tended to do large refactors, many of which we've backed out of. For that reason, we've kept our own internal development version, which is ahead of the public version. Then when whatever we're developing is ready for public use, then we open source it

I'm not sure I follow the reasoning here, sorry.

Why not keep that internal version as a dev branch separate from main? I can see the appeal of keeping things out of master/main for a while, but not why you would keep that part of development hidden.

But most importantly, why let out the binary and not the source? presumably if something is not ready for public use, the artifact being out is worst of both worlds - unready code is out and the public can't check what it does.

Not trying to argue mind you, but if this was not a deliberate attempt to hide the binary's behavior I think I'm missing the alternative upsides that justify that flow.

The dev process carries over from when we constantly rewrote the codebase from scratch every few weeks[0]. We ran many experiments, most of which we threw away. A small number became part of "pgrust". It didn't seem worth it to maintain public branches with all of our development effort when we knew 80% of it was going to be thrown away

[0] https://malisper.me/postgres-in-rust-regression-suite/

But you can make the branch public without committing to maintaining an experimental branch, this doesn't make sense.

It makes sense. Just because one can do a thing doesn’t mean they must want to do it.

It’s like everyone who squash merges for a clean timeline. You want you dev process to look prestine and communicate what changes were kept, not every experiment that failed.

If you've been accused of cheating it is a very different scenario.

Have you happen to have seen the 3 commits? They are over 1000 file diffs, that is not pristine or communicating changes the way devs do.

No, it's the old school cathedral "throw code over the wall" style commits that some companies were famous for.

That model of development is what led to Eric Raymond’s seminal The Cathedral and the Bazaar essay.

“Cathedral” refers to development behind closed doors, where you just get a release and a source dump to go with it.

“Bazaar” refers to development done in the open, where you have constant access to the bleeding edge.

At the time of the essay, GCC and Emacs were ESR’s examples of Cathedral-style development, and Linux was the premiere example of the Bazaar style.

The Cathedral style has become a lot less common over the years, but it’s still how e.g. SQLite operates, I think? E.g. Google definitely operates like that with AOSP, but that's arguably more a fruit of them being maliciously compliant with their Open Source promises.

Some projects do, for example the Lua programming language does their work in private, between releases.

Other projects do it less successfully, making grandiose claims and later releasing things in a partially working state, for example the V-programming language.

It's not super-common, but just those two examples off the top of my head show it's not entirely unheard of.

Not normal. This a new trend of people who use too much Ai, or maybe more specifically the Claw/Ralph loops where you end up with a few commits touching 1000s of files. For about the last year, many Show HN to github projects are often just a single commit

We need to think more about what we are doing as an industry, instead of letting the machines think for us (imo)

I am getting increasing disillusioned by the number of peers I am seeing completely hand over their thinking to a tool. Agents are great, but if you can't explain to me how your PR changes a system and why design choices were made you are no longer an engineer.

Agreed. Used to be prevalent in the frontend world (now I think it's the only thing that exists seemingly), where programmers would copy-paste stuff from Stack Overflow until things worked, and when you asked "So why did this actually fix the issue?" they usually said "I'm not sure, but it works now, that's what matters". This seems to be standard practice across the entire stack now.

I've even wasted my time jumping on calls (requested by the other party) where after 5 minutes of conversation, it's extremely clear this "technical founder" doesn't even understand the basics of their own design and architecture of the product itself, even less the technical parts.

This seems more a product of the incentives we have in society, namely seeing the rich and wealthy on social media and then wanting that quick and easy. So many of those cases are not people with passion for the problem.

Good things take real effort, bring back the TLC!

> Good things take real effort, bring back the TLC!

Ain't no one willing to reward the real effort any more. I take pride in not using LLMs beyond the capability of IntelliJ's advanced autocomplete, but then again, I only code for fun these days given I fled IT for electrical engineering.

> Ain't no one willing to reward the real effort any more.

A product of the times we currently live in, but which can also be changed.

This is a recent Michael Sandel talk I watch that has my brain gears turning on this subject

https://www.youtube.com/watch?v=Vp5qsEuUOWo

What we don't want to do is mirror the partisan political environment in the Ai yay, nay, or how. We need to be able to talk to each other in understanding and a shared reality of facts. Too much hyperbole right now, starting from the top of the big US labs. They need to step down a few ego and sycophancy pegs

Let any who read this be aware: You should be immediately suspicious of AI code that is much much faster than established code bases. AIs are even better at benchmarkmaxxing than humans are, and humans were already pretty good.

It is by no means impossible for an AI-written code base to be faster than a conventionally-written one, of course. It's just a time to be suspicious. Especially if there's little to no evidence that the human has subjected the code base to any further testing of their own. AIs seen to be able to benchmarkmax even in the presence of a lot of unit tests that would generally speaking have prevented a human from going too far down that road.

The project author seems to have prompted Claude to add a test to catch Claude cheating, but will Claude change this test as a workaround in a future commit, no one knows because no one is reading the project code...

https://github.com/malisper/pgrust/blob/38634b408dea373f3944...

Reply on news.ycombinator.com