My comment was harsher than it needed to be and I'm sorry, I think I should have gotten my point across in a better way.
With that out of the way, parent was wondering why compaction is necessary arguing that "context window is not some physical barrier but rather the attention just getting saturated". We're trying to explain that 3+2=2+3 and you people are sitting in the back going "well, actually, not all groups are abelian".
To save others the trouble, it doesn't matter whether you use Chrome or Safari for the auth flow. It's broken on both. (I'm using a personal @gmail account.)
> The cardioprotective effects of semaglutide were independent of baseline adiposity and weight loss and had only a small association with waist circumference, suggesting some mechanisms for benefit beyond adiposity reduction.
Like a lot of people in this thread I prototyped something similar. One experiment just connected GPT to a socket and gave it some bindings to SQLite.
With a system prompt like “you’re an http server for a twitter clone called Gwitter.” you can interact directly with the LLM from a browser.
Of course it was painfully slow, quickly went off the rails, and revealed that LLM’s are bad at business logic.
But something like this might be the future. And on a longer time horizon, mentioned by OP and separately by sama, it may be possible to render interactive apps as streaming video and bypass the browser stack entirely.
So I think we’re a the Mother of All Demos stage of things. These ideas are in the water but not really practical today. Similarly to MoaD, it may take another 25 years for them to come to fruition.
"The Mother of All Demos" was a showcase of an early generation of technology that existed and had a practical purpose. There was never a question if and how the technology would improve. It was only a matter of time and solid engineering.
On the other hand, improvements to "AI" of similar scales are very much uncertain. We have seen moderate improvements from brute force alone, i.e. by throwing more data and compute at the problem, but this strategy has reached diminishing returns, and we have been at a plateau for about a year now. We've seen improvements by applying better engineering (MCP, "agents", "skills", etc.), but have otherwise seen the same tech demos in search of a problem, with a bit more polish at every iteration.
There's no doubt that statistical models are a very useful technology with many applications, some of which we haven't discovered yet. But given the technology we have today, the claim that something like it could be used to generate interactive video which could be used instead of traditional software is absurd. This is not a matter of gradual iterations to get there—it would require foundational breakthroughs to work even remotely reliably, which is as uncertain as LLMs were 10 years ago.
In any case, whatever sama and his ilk have to say about this topic is hardly relevant. These people would say anything to keep the hype-driven valuation pump going.
I don’t think speed dating is as popular as submarine[1] articles suggest. But the constraint of being in-person and with a limited set of options may be helpful for some people. The paradox of choice is a significant issue on apps.
I do agree that bandwidth is significantly higher in person, we’ve evolved efficient pattern detection, and wish it were more acceptable to meet up for a quick coffee immediately after matching. But a few bad apples spoil the bunch.
There’s an alternate explanation - that the fittest companies prioritize engagement and revenue until reaching some threshold of user dissatisfaction. The healthiest businesses often have customers who wish they could leave, but can’t.
Tangential from your point, but I don’t think this is a submarine article. This is just a single blogger. “Submarine article” typically refers to articles written by large news corporations (NYTimes eg) and incentivized by PR firms - none of which applies here.
The reason I mention this is that “submarine article” is typically used to cast suspicion at the aims of the article. I can’t see any reason to do that to this article.
I was suggesting OP may have been influenced by submarine articles since the popularity of speed dating is a potentially unfounded premise of their argument. (Personally, I know very few folks who’ve done speed dating but of course that’s anecdotal.)
It's only costly due to the waste heat from breaking. If you captured that energy with perfect regenerative breaking you could return to the same speed in the opposite direction. (In a spherical cow sense anyway.)
> He's also implying that Rails does not use web sockets to communicate with frontend which is not only wrong it should be evidently wrong to anyone who built a Rails app in the last 3 years.
I’m actually a rails dev but I’d reach for phoenix if my app required a large number of persistent sockets (e.g. high-volume MCP servers). I say this mostly because the hosting story is better for phoenix (gigalixir) than rails (heroku, or similar services that run behind a request router). Of course if you want your own infra this argument doesn’t apply. But a $100 gigalixir box can easily serve 100k persistent connections — even a few thousand persistent connections is a non-starter on Heroku.
In the local Rails community where I live we haven't used Heroku for a while now. Most of us have moved on to using Kamal with a VPS of our choice. The surprising benefit is that you can even host multiple rails app on a single VPS so it is ideal for playing around with multiple hosted apps.
As for raw performance I'm sure you'd get better deal with Elixir out of the box than Rails out of the box but if you wanted to keep all the benefits of Rails and scale websocket usage look into AnyCable.
I didn’t say that rails doesn’t use websockets. What i meant is that liveview comes with websockets fully integrated into the framework. This doesn’t mean rails can’t use websockets, but liveview has implemented it more seamlessly at the core. I’ve also mentioned that rails and laravel are both great frameworks, but after using phoenix, i felt that liveview offered advantages in terms of performance and implementation. I’ve worked with all three frameworks and chose the one that worked best for my project. Have you had a chance to try phoenix? If not, do try it out then you’ll get what I meant.
A sustainable business can pay more employees than a failed startup. And pivoting with 150 employees is nearly impossible; all those people were hired for a different business.
A bit underwhelming when you see what's actually on offer. "Apps" are really just MCP servers, with an extension to allow returning HTML.
A lot of the fundamental issues with MCP are still present: MCP is pretty single-player, users must "pull" content from the service, and the model of "enabling connections" is fairly unintuitive compared to "opening an app."
Ideally apps would have a dedicated entry point, be able to push content to users, and have some persistence in the UI. And really the primary interface should be HTML, not chat.
As such I think this current iteration will turn out a lot like GPT's.
MCP has this in the spec: it's called "elicitation", and I'm pretty confident this push from OpenAI sets the stage for them to support it.
Once a service can actively involve you and/or your LLM in ongoing interaction, MCP servers start to get real sticky. We can safely assume the install/auth process will also get much less technical as pressure to deliver services to non-technical users increases.
I also see a lot of discussion on Github around agent to agent (a2a) capabilities. So it's a big use case, and seems obvious to the people involved with MCP.
reply