root_axis

LLMs heavily rely on traditional search engines behind the scenes.

No he wasn't, stop spreading lies.

Because the model can output data in a manner optimized for training a new model, including outputs that were post-trained like RLHF and RLVR.

Same experience I have with bun in general. As an idea, it's the absolute best js runtime by a very large margin, but in terms of stability it's terrible and segfaults 20x as much as node (I base that number on newrelic telemetry)

Phones have gigabytes today.

Phones have zero HBM today.

There are famous laws of growth that put terabytes at just a few years away

I assume you're referring to Moore's law here, but if you are, it doesn't really apply to HBM in the same way, especially in a smartphone form factor where LPDDR is the only practical option due to heat and energy constraints, and a variety of architectural complexities specific to HBM that make a TB of it in a smart phone something far beyond what we can hope for in any timeline we can project today.

Not really. Models that can run on a $250 card may be able to produce a decent word doc sometimes, but the fidelity of such models is so poor that it's no longer very attractive for general use on those types of tasks.

But how many years do you guess? I personally do not think it will take even 10 years for the situation to be commonplace.

IMO it won't be possible for the foreseeable future. There's essentially zero possibility that phones will gain the hardware capacity to run today's Kimi, so the only other alternative is to squeeze the power of today's Kimi into something that can fit on a smartphone, which also seems fairly unlikely considering the current rate of progress.

Inflammatory partisan and identity politics activism.

Directly interfering in the u.s. government

A consistent pattern of grandiose over-promising and under-delivering in his products (FSD, robotaxis, electric-semi, boring company etc)

and plenty more

Doubtful for the same reasons. The frontier providers are working at a hardware scale that will make it impractical to undercut them.

I wouldn't rule out the possibility completely, but it won't be very common.

My prediction is that hardware costs will make open source models impractical for the foreseeable future.

Yes, tinkerers and enthusiasts will continue to make use of them, but frontier companies will maintain near total dominance because they will be the only ones with access to the hardware.

I recommend putting fingers on keyboard and just trying to find your way through the solution instead of complaining about how impossible life is.

I recommend you stop making stuff up online. We're 10 layers deep into this thread and you still can't explain how any of this works in a coherent way.

If any of this is real, why don't you attach a link from the node documention or an article that explains this technique that allows node to serve type stripped imports over http.

I'm not asking for a link to the http stack, I'm asking you to explain how you run a node app that consumes your typescript source code and serves it over http without a bundler.

You seem to think their behavior will change after an acquisition

No. I'm explaining that PayPal as a business has their own risk models and contractual relationships with merchants that allows them to serve these lines of business profitably. This is the reason why PayPal services these businesses in the first place.

After a Stripe acquisition, that doesn't change, PayPal's model continues to operate profitably for high risk merchants while Stripe's continues to be risky due to the fact that Stripe is just a payment processor, while PayPal operates more like a bank.

How is PayPal not subject to MC rules when MC is used as a funding source for a PP account that purchases cannabis-adjacent services

The card networks establish strategic partnerships with large businesses in order to cater to their needs. Since PayPal has already established a profitable risk model to service these merchants, the card networks are comfortable with more permissive checkout rules since PayPal is contractually on the hook for chargebacks and fraud.

taking a few billions in high-risk money puts their other even-larger billions at risk.

How does that money put their larger business at risk?

Risk mitigation is not "for no reason"

I'm not sure why everyone in this thread consistently ignores the fact that PayPal has been profitably servicing these types of businesses for years. The risk has already been mitigated.

If Stripe simply homogenizes contractual rules that match their contracts with Mastercard, etc, which side of the bet would that fall on?

That would be me losing the bet. What you and others in this thread seem to be missing is that Stripe's risk factors are not the same as PayPal's because Paypal works directly with merchants rather than as a proxy for the card rails like Stripe. The idea that Stripe would take ownership of the platform and start shutting off paying customers is absurd, and as of yet, I haven't seen anyone acknowledge this fact in their explanation of why Stripe would throw away free money.

The "anti-Elon thinking" comes from the things Elon says and does.

He spent $300 million in cash (more than any individual donor in history) to help elect the current president.

Yeah, IMO they are just making stuff up. Even as explained what they're saying makes no sense. Ultimately, there needs to be some entrypoint into the client-side script, node has no built in way to serve source code it's type-stripped over http.

The term scam is definitely inflammatory, but I think the sentiment is fair considering the unprecedented and extreme overvaluation and the unrealistic justification for it. It's even worse when you consider Elon's consistent track record of over-promising and under-delivering. Taken together with Elon's role in gutting regulations and coordinating to change listing rules, it's totally fair to characterize what's going on as intentional dishonesty for profit - i.e. a scam.

Why does it matter? Agent harnesses aren't doing anything that would make a compiled language more suitable than a scripting language.

It's disappointing that you're now descending into sarcastic quips rather than address the substance of my reply. You could have just abandoned the conversation without the snarky announcement.

Anyway, if that's the quality of conversation you're offering then abandoning the conversation makes sense. Have a good one.

Paypal earned 30b net revenue in 2025, without any specific numbers, it's a safe bet that high-risk merchants are at least several billion of that total.

However, even if it were only in the hundred millions, there's no reason to throw away millions of dollars. The reason PayPal services these lines of business in the first place is because they make money doing so (since unlike Stripe, PayPal's product isn't subject to the constraints of the card rails).

So your prediction is that Stripe will throw away billions for no reason based on your anecdotal experiences.

I'll take the bet that you're totally wrong.

I think that Stripe will shut off paying customers BECAUSE I HAVE SEEN THEM DO IT. That is what first hand knowledge is.

You are overindexing on your anecdotal experience to draw conclusions that make no sense. Paypal earns roughly 6x the net revenue of Stripe while processing a similar volume of transactions. Paypal has obviously figured out how to service these businesses profitably, yet for some reason you think Stripe would throw away billions for no reason.

Make that logic make sense.

I'm sure that PayPal does serve them (first hand knowledge). I'm sure that Stripe selectively restricts them (first hand knowledge).

Correct. But do you understand why that is? What is the theory of mind you have that makes you believe Stripe would come in and shutting off paying customers?

I do believe that Stripe will execute they same Stripe pattern in the merged company which will reduce choices in the market for businesses.

Why would they do that? This doesn't make any sense unless you actually think morals are involved.

You seem to care more about the aesthetics of the sentence than the meaning behind it.

Excuse me for interpreting the comment as written, but either way, the comment only makes sense if you believe that Stripe is going to take over paypal and shutoff profitable lines of businesses based on moral principles - otherwise, what's the problem?

If you actually understand that this is all about money, then it's obvious that this is not going to happen.

Yes, hence the value of an acquisition that has found a way to service these lines of business very profitably.

The tone of your original comment suggests you believe they're going to take over and start shutting off morally unacceptable money printers.

Why do people think this? Since when do giant corporations care about morals?

As usual, everything is about money. You can be sure that part of the interest in a paypal acquisition is paypal's consumer wallet product which allows them to extend into lines of business that are currently constrained by Stripe's model.

You said:

I just write my code and then point node at the main file, and this even includes front-end code for the browser.

Then you said:

I never said Node is did anything for the front end.

So which is it?

It only takes a few microseconds and I don't need any bundlers

And yet you're using one. Esbuild is one of the most popular bundlers in the js ecosystem, your workflow is functionally identical to any other bundler workflow except that the example you provided is worse than the typical workflow because it builds the ts file on every request rather than just once when the source code changes.

I don't know what tooling you're using in go, but node does not do any kind of transformation to assets it serves over http. Running logic written in TypeScript on the front end requires some kind of bundler so that the browser can run the code.

In such a future where LLMs hypothetically dominate the SDLC, the trade would be much more like pottery than medicine - i.e. a commodity in such obscene abundance that its functional utility would be entirely divorced from its creation.

In such a future there would be a handful of lucky well paid artisans, a healthy community of hobbyists, and the overwhelming population of the planet who would be perfectly content to delegate their entire software diet to generative superplatforms that script themselves to perform any arbitrary software function. The idea of paying for individual bespoke software programs would become an anachronism for an era where software was so difficult to produce that entire teams spent years painstakingly tweaking programs to spec.