lucasyvas

Guys, are we poor? I just ran out after a 20 minute refactoring exercise for the next 4.5 hours lol.

Isn’t this flawed anyway? If an application communicates with Claude Code over ACP (like Zed), it works fine?

Instead of using SDKs, this will just shift the third party clients to use ACP to get around it - Claude Code is still under the hood but you’re using a different interface.

This all seems pretty idiotic on their part - I know why they’re trying it but it won’t work. There will always be someone working around it.

Well they don’t have to wait for Rust in the way they said - they’ve already been forked by Turso which has been moving along for a while now. I wouldn’t mind hearing from them how that’s been going.

I also think love is the wrong word here.

But I will agree with the overall sentiment - in most places I’ve worked in software when I thought to myself “fuck that customer”, I was wrong. It was actually our fault because we weren’t meeting their needs or didn’t set a clear boundary on service expectation we were willing to provide to them.

So I see it as more “respect the needs of your customer and be prepared to part ways amicably”.

If you want to call that love, sure. But I think some customers can be abusive as well so I don’t agree with that word choice.

I work in a vertical right now where prospective customers are desperate to switch from the incumbent because of abusive lock-in contracts and poor service levels for obscene pricing based on ancient processes. So, overall, I have to agree with Brian’s sentiment even if I think it comes off as too idealistic.

Did it win? Against just Perl, or everything else?

This was just about the worst case scenario.

Well let me avoid those that don’t understand it. It’s literally Rust 101.

These are all non-issues - don’t allow an end user to determine a serial primary key as always.

And the amount of information it leaks is negligible - they might know the oldest and the newest and there’s an infinite gulf in between.

It’s better and more practical than SERIAL or BIGSERIAL in every way - if you need a random/external ID, add a second column. Done.

This is like saying you don’t like nails because you don’t understand how to use a hammer though. Developers are not understanding how to use the hints properly which is causing you a personal headache. The hints aren’t bad, the programmers are untrained - the acknowledgement of this is the first step into a saner world.

Among the requirements of the DMA is that Apple ensures that headphones made by other brands will work with iPhones. It said this has been a block on it releasing its live translation service in the EU as it allows rival companies to access data from conversations, creating a privacy problem.

This sounds bogus right? If all the headphones can do is transmit audio via first party operating system features how is this creating a data privacy issue? How are headphones going to exfiltrate data unless they have their own Wi-Fi connection or application that can serve as a bridge? Just disallow both.

We all work at companies and know how it works - you get away with what you can. You bet wrong and nobody will believe otherwise. If it was a mistake, it’s fireable.

You could make money off of this if you are able to pair willing manufacturers to realistic and popular ideas that get generated. It could become a real market place.

Hilarious project.

Edit: I did both Mouthwash Ramen and Time Machine to the Present. I’m now addicted to this, thanks.

I understand the user pool comment but don’t understand why you wouldn’t be able to have a rust layer that’s the same as the Python one API-wise.

I say this as a user of neither - just that I don’t see any inherent validity to that statement.

If you are saying Rust consumers want something lower level than you’re willing to make stable, just give them a higher level one and tell them to be happy with it because it matches your design philosophy.

I reached this conclusion pretty quickly. With all the hand holding I can write it faster - and it’s not bragging, almost anyone experienced here could do the same.

Writing the code is the fast and easy part once you know what you want to do. I use AI as a rubber duck to shorten that cycle, then write it myself.

Difference between work and personal. For personal, you’re right because there is nothing to bootstrap off of.

But in corporate it’s provisioned to a user account that exists first.

My personal bootstrap is two Yubikeys (for redundancy) that contains the password and 2FA for my Proton Pass. This plays the role of what IT would in a company with a user directory.

They should re-market as an anti-AI documentation company that uses analogue capture techniques. Use film!

Just become a black hat then. It will be easy to find problems in everything but the very top percent of AI generated software.

PHP is a DeLorean. I think I encountered 10 segfaults in it within 1 year which is a complete joke. This was only two years ago.

It also includes breaking changes in point releases which is a nonsensical maintenance strategy - this is in stark contrast to the reputation of stability in a Corolla.

While PHP may have some strengths, it immediately fails this particular comparison.

It’ll become a paid offering lol. What’s the license?

Require per visit biometric authentication via your device and the bot can’t sign in unless it compromises the device.

The web has no choice but to move to a paid access model in my view. It was fought against for years but I don’t see another option left.

Maybe after sign up, biometric authentication being mandatory is the only thing that would potentially work. The security and offline privacy of those devices will become insanely valuable.

Anyone not authenticating in this way is paywalled. I don’t like this but don’t see another way.

I’m not using the web if I’m bombarded by captcha games… shit becomes worthless over night if that’s the case. Might as well dump computing on the Internet entirely if that happens.

AI will be ridden with ads - just disguised as answers.

And without the web there is no new datasets for AI so it’ll grind to a halt.

LLMs offer access to good enough help at cost, scale and availability that human practitioners can only dream of.

No

OK that’s super confusing but makes sense. I can choose between Apple Pay and other options in literally every app I use and was very confused.

I fail to see how this won’t just result in UA string or other obfuscation.

Social obligations are inherently weak is the point I’m trying to make. Make it easy for active users of your software to distribute it and make it harder for free-loaders. The problem solves itself.

Ubuntu literally has LTS releases where they guarantee fixes for security issues and the like for absolutely no charge.

If there’s a bug in SSH libraries that Canonical ships in Ubuntu, that is their distribution of that library even if they are not the primary authors. Canonical guarantees support for the software it ships, so they are obligated to fix it no matter what. Fixes are upstreamed to the primary author - the author never asked for their software to be included in that distribution so it’s not their problem to fix it for Ubuntu users.

This is a model that solves the problem the author is discussing.

It seems artificial at face value but the distribution model has existed for decades under the same conditions.

The argument is that we should split these two concerns explicitly to create a delineation of roles and responsibilities. We have a model for this but don’t adopt it elsewhere in the name of simplicity, but the outcome is more complex because you can’t point the finger at anyone.

It should work as you say, but it doesn’t and arguably never will. So I suggest we deliberately change everything to the distribution model to make it explicit. It then becomes clearer that the distributor is who you go to for support. If the author is the distributor, go to them. If it’s someone else, go to the entity that distributes it. If there is no distributor, it’s on you to build it and support it yourself.

It forces the build process onto the distributor which makes them best set up to deploy fixes, therefore it’s more clearly their responsibility. The shifting of where it builds actually goes a long way to solving this problem. If you are building and publishing it yourself, you are set up to fix the issue immediately which indicates you should fix it first and then upstream it.

Counter-argument to the author: If you publish a package you are a supplier full stop. If you don’t want to be considered a supplier, do not publish a built version of your software.

Allow someone else to build and publish it on your behalf (i.e. a separate distributor entity), then they become the supplier. They assume the risk - they can establish those business relationships.

This is how software distribution has worked in Linux forever. For example, it’s Debian’s or Red Hat’s problem to fix a bug in a library they ship and they can upstream it back to you if they want.

Do not publish your package, only provide the source. Publish it for only yourself privately if you wish to consume it. Promote it, provide build scripts… whatever. But don’t publish it.