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

UPDATE: I misunderstood the question :-/ You can ignore this.

I love playing with compilers for fun, so maybe I can shed some light. I’ll explain it in a simplified way for everyone’s benefit (going to ignore the stack):

When an object is passed between functions in Python, it doesn’t get copied. Instead, a reference to the object’s memory address is sent. This reference acts as a pointer to the object’s data. Think of it like a sticky note with the object’s memory address written on it. Now, imagine throwing away one sticky note every time a function that used a reference returns.

When an object has zero references, it can be freed from memory and reused. Ensuring the number of references, or the “reference count” is always accurate is therefore a big deal. It is often the source of memory leaks, but I wouldn’t attribute it to a speed up (only if it replaces GC, then yes).


what at all does this comment have to do with what it's replying to?

I misread the original comment, thinking it was a question about what is refcount elimination, than how it affects the JIT's performance(?).

It’s definitely not Kagi’s fault. The AI slop is simply taking effect and I feel sorry for them. I never expected them to match Google’s quality, but I was impressed with how close it was when I used it a few years ago.

Kagi used to use Google's search API. They discuss the current state of their index here: https://blog.kagi.com/waiting-dawn-search

Buried under a lot of complaints about fairness, Kagi mentions they are still using Google search results, just without authorization.

> Because direct licensing isn't available to us on compatible terms, we - like many others - use third-party API providers for SERP-style results (SERP meaning search engine results page).

So in one sense, yes, Kagi isn't quite Google, but in another sense, it very much still is.


This sounds great on paper till you realize the amount of time and effort that goes into coordinating so many humans is significant. Also quarterly reporting and TLS certs are worlds apart. There are things like SOX compliance in public companies. It is a mandatory requirement that necessitates so much ceremony surrounding how information is captured and decisions signed off. Then for the execs themselves, it is at least a week of effort easy leading up to the quarterly result call. Prepping for the investor deck, QnAs, being open to more frequent regulator scrutiny. Doing this every month would have diminishing returns for everyone involved.

Source: worked at public companies, helped executives prepare for said calls.


I think it shifts the skillset of executives a little bit. At publicly traded companies the quarterly shareholder meetings and the preparation that goes into it becomes such an outsized portion of the job that being good at that one thing is highly valued. I don’t think moving quarterly to bi-annually changes that much besides making the CEO and CFOs and some other folks jobs a bit easier.

As long as it’s gated and not turned on by default, it’s all good. They could also add a warning/sanity check similar to “allow pasting” in the console.

Relying on warnings or opt-ins for something with this blast radius is security theater more than protection. The cleverest malware barely waits for you to click OK before making itself at home, so that checkbox is a speed bump on a highway.

Chrome's 'allow pasting' gets ignored reflexively by most users anyway. If this agent can touch DevTools the attack surface expands far faster than most people realize or will ever audit.


Cool findings. However, considering the endangered nature of bumblebees in North America, it is sad and frustrating to see the number of Queens sacrificed in the name of research. Hundreds if not more.

This was the most grotesque part of the research, that sacrificed 20 bees right here:

> They froze five bees at each stage of the experimental process: before submersion, after four days underwater, after eight days underwater and after one week of post-submersion recovery. The researchers then ground up the frozen queens and measured the concentration of lactate in the resulting mush.

This could have been done without needing to kill the Queen bees. One such method has been known since 2017, that draws their blood through their antennae:

https://pmc.ncbi.nlm.nih.gov/articles/PMC5268409/


1) there are millions of honeybee hives in north america. Therefore thare a millions of queens associated with those hives

2) its very easy/straightforward to take a honeybee larve and raise it to be a queen (i.e. let it feed on royal jelly).

If you find animal research to be problematic, none of this changes anything. However, this did nothing to hurt honeybee colonies in north america.


Ti me it seems that the opinion is the result of anthropomorphizing bees. They exist in a different social order. Their survival depends on things that, if people were organized in such way, it would seem very wrong to people. Their survival depends on numbers much more than human survival. They’re just not equivalent.

I don’t think it’s the case if we’re referring to my personal opinion. But to be certain, I will dwell on it a bit longer.

Not to take from the thrust your comment but just so you know, bumblebees and honeybees are not the same species.. Bumblebee nests are somewhat different than hives, and the way in which they develop is different also.

I suppose I’m still not fully onboard, but I appreciate the thoughtful comment. It provides more perspective.

AFAIK Grok still doesn’t have a CLI coding agent that works with a subscription. That’s a shame. Grok Code Fast 1 was pretty impressive when it came out - for what it did, and they never followed it up with a new version.

You can use cursor with grok, though my experience is that grok is the worst of the API providers cursor supports.

Early thoughts - this is very interesting and quite possibly revolutionary. If they have legitimately emulated a computer with memory reliably inside a transformer - that will open up an entirely new world for research.

I don’t want to say too much too soon, but I am pretty excited about this.


TL;DR the premise for the calculation is completely flawed even if the conclusion is correct

> Qwen 3.5 397B-A17B is a good comparison point. It's a large MoE model, broadly comparable in architecture size to what Opus 4.6 is likely to be.

I stopped reading here. Frontier models have been rumoured to be in TRILLIONS of parameters since the days of GPT-4. Besides, with agents, I think they’re using more specialized models under the hood for certain tasks like exploration and web searches.

So while their cost won’t be $5000 or anywhere close, I still think it would be in the hundreds for heavy users. They may very well be losing money to the top 5-10% MAX users. Their real margin likely comes from business API customers.

Here’s an interesting bit - OpenAI filed a document with the SEC recently that gave us a peek into its finances. The cost of all infrastructure stood at just ~30% of all revenue generated. That is a phenomenal improvement. I fell off the chair when I first learned that.


That’s a shallow way to get people to own up to their code. I haven’t read the original link but going by the title, a blanket no-LLM is bad. Driven by human and supported by AI should be the way.

Precisely. “AI” contributions should be seen as an extension of the individual. If anything, they could ask that the account belong to a person and not be a second bot only account. Basically, a person’s own reputation should be on the line.

Reputation isn't very relevant here. Yes, for established well known FOSS developers, their reputation will tank if they put out sloppy PRs and people will just ignore them.

But the projects aren't drowning under PRs from reputable people. They're drowning in drive-by PRs from people with no reputation to speak of. Even if you outright ban their account, they'll just spin up a new one and try again.

Blocking AI submissions serves as a heuristic to reduce this flood of PRs, because the alternative is to ban submissions from people without reputation, and that'd be very harmful to open source.

And AI cannot be the solution here, because open source projects have no funds. Asking maintainers to fork over $200/month for "AI code reviews" just kills the project.


Well, the problem you just outlined is a reputation (+ UI) problem: why are contributions from unknown contributors shown at the same level as PRs from known quality contributors, for example?

We need to rethink some UX design and processes here, not pretend low quality people are going to follow your "no low quality pls i'm serious >:(" rules. Rather, design the processes against low quality.

Also, we're in a new world where code-change PRs are trivial, and the hard part isn't writing code anymore but generating the spec. Maybe we don't even allow PRs anymore except for trusted contributors, everyone else can only create an issue and help refine a plan there which the code impl is derived?

You know, even before LLMs, it would have been pretty cool if we had a better process around deliberating and collaborating around a plan before the implementation step of any non-trivial code change. Changing code in a PR with no link to discussion around what the impl should actually look like always did feel like the cart before the horse.


Because until now, unknown contributors either submitted obvious junk which could be closed by even an unskilled moderator (I've done triage work for OS projects before) or they submitted something that was workable and a good start.

The latter is where you get all known contributors from! So if you close off unknown contributors the project will eventually stagnate and die.


In the long distant past of 4-5 years ago, it simply wasn't a problem. Few projects were overwhelmed with PRs to begin with.

And for the major projects where there was a flood of PRs, it was fairly easy to identify if someone knew what they were talking about by looking at their language; Correct use of jargon, especially domain-specific jargon.

The broader reason why "unknown contributor" PRs were held in high regard is that, outside of some specific incidents (thank you, DigitalOcean and your stupid tshirts), the odds were pretty good of a drive by PR coming from someone who identified a problem in your software by using it. Those are incredibly valuable PRs, especially as the work of diagnosing the problem generally also identifies the solution.

It's very hard to design a UX that impedes clueless fools spamming PRs but not the occasional random person finding sincere issues and having the time to identify (and fix them) but not permanent project contribution.

> and the hard part isn't writing code anymore but generating the spec

My POV: This is a bunch of crap and always has been.

Any sufficiently detailed specification is code. And the cost of writing such a specification is the cost of writing code. Every time "low code" has been tried, it doesn't work for this very reason.

e.g. The work of a ticket "Create a product category for 'Lime'" consists not of adding a database entry and typing in the word 'Lime', it consists of the human work of calling your client and asking whether it should go under Fruit or Cement.


I don’t know why you got downvoted. Those are good points.

Contrary to popular belief, I believe open-source projects are poised for a significant windfall. If a project lacks the ability to transform a good problem into an advantage, that’s their prerogative, but it shouldn’t be the norm (I hope not).

I like to think of it as a stranger/volunteer using their tokens to give the project maintainers a choice. Imagine each issue having 3-4 PRs - it’s a brave new world that demands new solutions!

From a place of scarcity - to now picking from multiple PRs, not a bad problem to have. This is turning into a signal vs noise optimization problem. Could it be solved with agents specially fine-tuned for this use-case? Maybe. Why not?

Also many projects on GitHub do have discussions (typically in a long Issues thread) before someone opens a PR.


> because the alternative is to ban submissions from people without reputation, and that'd be very harmful to open source.

Hmmm, no? That's actually very common in open source. Maybe "banning" isn't the right word, but lots of projects don't accept random drive-by submissions and never have. Debian is a perfect example, you are very unlikely to get a nontrivial patch or package into Debian unless you have some kind of interaction or rapport with a package maintainer, or commit to the process of building trust to become a maintainer yourself.

I have seen high profile GitHub projects that summarily close PRs if you didn't raise the bug/feature as an issue or join their discord first.


Setting aside "make an issue first" because those too are flooded with LLMs.

> you are very unlikely to get a nontrivial patch or package into Debian unless you have some kind of interaction or rapport with a package maintainer

I did mean the "trivial" patches as well, as often it's a lot of these small little fixes to single issues that improve software quality overall.

But yes, it's true that it's not uncommon for projects to refuse outside PRs.

This already causes massive amounts of friction and contributes (heh) heavily to what makes Open Source such a pain in the ass to use.

Conversely, many popular "good" open source libraries rely extensively on this inflow of small contributions to become comprehensively good.

And so it's a tradeoff. Forcing all open source into refusing drive-by PRs will have costs. What makes sense for major security-sensitive projects with large resources doesn't make sense for others.

It's not that we won't have open source at all. It's that it'll just be worse and encourage further fragmentation. e.g. One doesn't build a good .ZIP library by carefully reading the specification, you get it by collecting a million little examples of weird zip files in the wild breaking your code.


You can literally just attach a patch to a bugreport on debian…

I don't see why we can't have AI powered reviews as a verification of truth and trust score modifier. Let me explain.

1. You layout policy stating that all code, especially AI code has to be written to a high quality level and have been reviewed for issues prior to submission.

2. Given that even the fastest AI models do a great job of code reviews, you setup an agent using Codex-Spark or Sonnnet, etc to scan submissions for a few different dimensions (maintainability, security, etc).

3. If a submission comes through that fails review, that's a strong indication that the submitter hasn't put even the lowest effort into reviewing their own code. Especially since most AI models will flag similar issues. Knock their trust score down and supply feedback.

3a. If the submitter never acts on the feedback - close the submission and knock the trust score down even more.

3b. If the submitter acts on the feedback - boost trust score slightly. We now have a self-reinforcing loop that pushes thoughtful submitters to screen their own code. (Or ai models to iterate and improve their own code)

4. Submission passes and trust score of submitter meets some minimal threshold. Queued for human review pending prioritization.

I haven't put much thought into this but it seems like you could design a system such that "clout chasing" or "bot submissions" would be forced to either deliver something useful or give up _and_ lose enough trust score that you can safely shadowban them.


The immediate problem is just cost. Open Source has no money, so any fancy AI solution is off the table immediately.

In terms of your plan though, you're just building a generative adversarial network here. Automated review is relatively easy to "attack".

Yet human contributors don't put up with having to game an arbitrary score system. StackOverflow imploded in no small part because of it.


> Precisely. “AI” contributions should be seen as an extension of the individual.

That's an OK view to hold, but I'll point out two things. First, it's not how the tech is usually wielded to interact with open-source software. Second, your worldview is at odds with the owners of this technology: the main reason why so much money is being poured into AI coding is that it's seen by investors as a replacement for the individual.


I know. But the irony is, agents, that is AI, need to collaborate with other agents, so other AI, to get any work done. Collaboration is at the core of how work takes place. As humans or as machines. So I don’t necessarily think Open Source will disappear. It will evolve and turn into something very different and more powerful.

Interesting argument for AI ethics in general. It takes the form of "guns don't kill people - people kill people".

An argument that I have some sympathy for, while still being moderately+ in favor of gun control (here in the USA where I'm a citizen).

It seems that gun control—though imperfect—in regions that have implemented it has had a good bit of success and the legitimate/non-harmful capabilities lost seem worth it to me in trade for the gains. (Reasonable people can disagree here!)

Whereas it seems to me that if we accept the proposition that the vast majority of code in the future is going to be written by AI (and I do), these valuable projects that are taking hard-line stances against it are going to find themselves either having to retreat from that position or facing insurmountable difficulties in staying relevant while holding to their stance.


> these valuable projects that are taking hard-line stances against it are going to find themselves either having to retreat from that position or facing insurmountable difficulties in staying relevant while holding to their stance.

It is the conservative position: it will be easier to walk back the policy and start accepting AI produced code some time down the road when its benefits are clearer than it will be to excise AI produced code from years prior if there's a technical or social reason to do that.

Even if the promise of AI is fulfilled and projects that don't use it are comparatively smaller, that doesn't mean there's no value in that, in the same way that people still make furniture in wood with traditional methods today even if a company can make the same widget cheaper in an almost fully automated way.


The AI hype machine is pushing the "inevitability" and "left behind" sentiments to make it a self-fulfilling prophecy, like https://en.wikipedia.org/wiki/Pluralistic_ignorance, and they have the profit and power incentives to do so and drive mass adoption. It is far from certain that AI will be indispensable or that people will "fall behind" for not using it.

Why would the AI-fans even care if others who decide not to use it fall behind? Wouldn't they get to point and laugh and enjoy the benefits of "keeping up"? Their fervor should be looked at with suspicion.


If you're addressing this to me: you need to separate my description of how I perceive things from any effort/desire on my part to make that come to pass. I don't expect to stand to gain if AI continues to get better at coding — most likely just the opposite; this is the first time in my career that I've ever felt much anxiety about whether I'd be able to find work in my field in the future.

There are many others like me who share this expectation, and, while we certainly may be wrong, it's not because of some sinister plan to make the prophecy come true. (There are certainly some who do have sinister/profit-seeking motives, of course!)


> It seems that gun control—though imperfect—in regions that have implemented it has had a good bit of success and the legitimate/non-harmful capabilities lost seem worth it to me in trade for the gains.

This is even true despite the fact that there are bad actors only a few minutes drive away in many cases (Chicago->Indiana border, for example).


Unfortunately ChatGPT turned “text continuation” into “separate entity you can talk to”

The desire to anthropomorphize LLMs is super interesting. People naturally anthropomorphize technology (even printers: "why are you not working!?"). It's a natural and useful heuristic. However, I can easily see how chatGPT would want to intensify this tendency in order to sell the technology's "agency" and the promise that it can solve all your problems. However, since it's a heuristic, it papers over a lot of details that one would do well to understand.

(as an aside - this reminds me of the trend of Object Oriented Ontology that specifically /tried/ to imbue agency onto large-scale phenomena that were difficult to understand discretely. I remember "global warming" being one of those things - and I can see now how this philosophy would have done more to obscure the dominion of experts wrt that topic)


I don't think any side on the issue of gun ownership has ever claimed that statement is false, so I'm not sure what your point is.

The point is thst this is a common pro-gun argument to deflect from the fact that making guns harder to own does in fact reduce gun violence. Which is how much of the rest of the world works.

But post Sandy Hook, it's clear which side prevailed in this argument.


Except it seems to be arguing in the exact opposite direction, and about the other side of the problem?

Those in favor of gun control aren't trying to lower human responsibility, they're trying to place stricter limits on the guns than the status quo. Those against gun control are trying to loosen limits on the guns.

Here this person is proposing making individual responsibility stricter compared than what it is today. And they're not arguing for loosening limits on the tech either.

Isn't that practically the opposite of your analogy?


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

Search: