They were doing their own custom language before Swift.

didn't know

> The browser and libraries are all written in C++. (While our own memory-safe Jakt language is in heavy development, it’s not yet ready for use in Ladybird.)

https://awesomekling.github.io/Ladybird-a-new-cross-platform...

only thing I could find - has it been actually used in Ladybird after all?

No, they never completed or adopted their own language. It was back in the SerenityOS days, before the browser forked into its own project.

https://github.com/SerenityOS/jakt

Apple’s own marketing speak has Swift as a cross platform language. Just like, I suppose, C# is a cross platform language.

Apple puts zero resources into making that claim reality, however.

Apple actually did put some resources behind it, the toolchain is reasonably pleasant to use outside macOS and Xcode, they have people building an ecosystem in the Swift Server Workgroup, and arguably some recent language design decisions don't seem to be purely motivated by desktop/mobile usage.

But in the end I can't help but feel Swift has become an absolute beast of a multi-paradigm language with even worse compile times than Rust or C++ for dubious ergonomics gains.

A language is more than a compiler. All of the Swift frameworks you would need to do anything actually useful or interesting in the language are macOS-only. You cannot develop in Swift for Windows/Linux/Android the way that you develop in Swift for macOS/iOS. That matters.

You don't need to convince me that Swift is poorly positioned there, but if you only care about server side (or possibly CLI) apps, the usable ecosystem on Linux isn't too shabby.

Does it make sense compared to C#, Go, Rust or a JVM language? I don't know, but it's there, and Apple put some resources behind the initiative.

I think it is comparable to C#, at least C# a decade or more ago. Back then it was a great language for developing GUI applications on Windows, Unity games, and that's about it. Now there's a blossoming community of cross-platform frameworks, but only because Microsoft invested in making those first-class. Apple hasn't been putting that effort into Swift.

Microsoft cross platform effort always pushed forward Web development and distributed systems, hardly "that's about it".

And if you mean before the whole .NET Core rewrite, many big corp server applications were already written in .NET, products like SharePoint, Sitecore, Optimizely, Dynamics 365, Four51,.... and plenty of server infrastructure for XBox and Windows games.

Was it Apple, or community driven projects?

> Just like, I suppose, C#

Have you actually used .NET on Linux/macOS? I have (both at home and work) and there isn't anything that made me think it was neglected on those platforms. Everything just works™

It didn't use to be that way, for a very long time.

It's been 10 years of it running on Linux.

People here need time to notice XD

When it wasn't that way, they never had any marketing speak that suggested that though?

What didn't work and when?

Because the ToS explicitly says the -p flag is fine, but the Agent SDK is not.

The Claude Agent SDK is explicitly disallowed from subscription use, as of a few days ago.

No it's not. You can't offer OAuth + the Claude Agent SDK in your own product, but you can use Claude Agent SDK locally by signing in through Claude Code.

It's no different than using Claude Code directly.

I’m aware of the tweet that says otherwise, but until they update their legal documentation, it’s still not allowed.

> OAuth authentication (used with Free, Pro, and Max plans) is intended exclusively for Claude Code and Claude.ai. Using OAuth tokens obtained through Claude Free, Pro, or Max accounts in any other product, tool, or service — including the Agent SDK — is not permitted and constitutes a violation of the Consumer Terms of Service.

https://code.claude.com/docs/en/legal-and-compliance#authent...

It's not about a tweet, just read your own quote.

You cannot authenticate with anything but Claude Code and Claude.ai.

But you do not need to authenticate with Claude Agent SDK (even though you can using env variables).

When you authenticate with Claude Code (allowed), Claude Agent SDK works without any further authentication.

It's really annoying that people keep trying to make this complicated because the inevitable end result is that they remove authless usage of the Agent SDK and save themselves the headache.

I really hate Clawdb-Moltb-OpenC-NanoCode or whatever half-baked project the grifters are on this week for ruining a good thing for the rest of us.

Did you read the second part? The ToS explicitly says that using the Agent SDK with Pro/Max authentication is disallowed. There is no ambiguity or interpretation here.

You do not need to give Agent SDK any credentials (completely optional)

But honestly, this is the side of intentionally misunderstanding that's actually preferable so: "You're absolutely right! You can't use your subscription to build yet another vibeslop harness, please refrain from doing so."

None of the pipes or valves are designed for hydrogen. It will steal leak. And leaking a very flammable gas isn’t great.

Let alone the compressors or the flow measurement equipment. Also significant portions of the pipesline (especially in neighborhoods / last mile) aren't metal anymore.

Well, Claude is here making .gitkeep files like nobody's business.

That’s not planned obsolescence. Your home network migrated to a new key exchange protocol that didn’t exist in 2011. That’s on you our your router manufacturer.

FYI a Twitter post that contradicts the ToS is NOT a clarification.

When your company happens upon a cash cow, you can either become a milk company or a meat company.

What is the point of developing against the Agent SDK after this change.