> despite having virtually infinite processing power, money

Just because they have the money doesn't mean that they spend it excessively. OpenAI and Anthropic are both offering coding plans that are possibly severely subsidized, as they are more concerned with growth at all cost, while Google is more concerned with profitability. Google has the bigger warchest and could just wait until the other two run out of money rather than forcing the growth on that product line in unprofitable means.

Maybe they are also running much closer to their compute limits then the other ones too and their TPUs are already saturated with API usage.

Java is for the modding user-base. If they would kill that, there is a good chance that the whole Youtube/Twitch creator ecosystem around the game dies, and with that it's popularity.

Bedrock is more performant and more portable across platforms (e.g. on consoles where you couldn't mod anyways).

Wrong kind of death. Taking mods away after a decade and a half of the game being modded inside out would massively reduce the creative scope of the game for players. It would become "boring" and die out

What can bite them in this case though is alternate providers at the same price point that can bridge the gap. e.g. you currently get a lot more bang for your buck with the $20 OpenAI Codex subscription than you get for the $20 Claude Code subscription.

> If I'm paying for usage

You are not paying for usage. You are paying for usage via their application.

If their business plan is based on how quickly a human can enter requests and react to the results, and Claude Code is optimized for that, why should you be allowed to use an alternative client that e.g. always tries to saturate the token limits?

Btw API is not for coding, it's designed for pipelines, automation, products. They just kill competition making better software like opencode.

Is that your belief to what their API should be used for?

But a) I'm not doing that and b) they can just ban that, like they have rate limits. Why ban OpenCode?

They have rate limits, but they also want to control the nozzle, and not all their users use all their allocation all the time.

In reality, heavy subscription users are subsidized by light subscription users. The rate limits aren't everything.

If agent harnesses other than Claude Code consume more tokens than average, or rather, if users of agent harnesses other than CC consume more tokens than average, well, Anthropic wouldn't be unhappy if those consumers had to pay more for their tokens.

> If agent harnesses other than Claude Code consume more tokens than average, or rather, if users of agent harnesses other than CC consume more tokens than average

Do they, though?

The speculative reasoning I've seen is that they have optimizations in their CC client that reduces their costs. If that's true, I think it's fair that they can limit subscription usage to their client. If you don't want those optimizations and prefer more freedom, use the API.

They rather have yolo permissions to run arbitrary code on your machine and phone home all the time, then opencode having it and phoning home all the time.

> anyone editing by hand would instinctively delete the extra spaces to align those

I think as a human I am significantly more likely to give up on senseless pixelpushing like this than an LLM.

And the $3 plan also has significant latency compared with their higher tier plans.

They seems to be a strong overlap of people behind both projects, so that likely explains the similarities.

I can't speak for the status quo, but for at least the first ~5 years (so until 3 years ago when I last attempted to use it), the JS implementation of Fluent was a mess. Constant issues with incomplete API, wrong TS typings (which at that point were external) and build/bundling issues to the point where we opted for a homebrew solution.

I imagine that I probably wasn't the only one driven away by that (and I gave it many attempts!).

Care to explain why you think it's infeasible? Then one could provide targeted counter-optimism ;)

I don't see what's infeasible about it. It doesn't seem too different from .po files (gettext catalogs) meshed with hooks for post-processing as would see in e.g. a handlebars, both of which have individually found great adoption.

> why you think it's infeasible?

GP based his opinion on the assumption that this spec new and no implementations for it exist.

ICU4C and ICU4J have implementations. We also have a JS polyfill and will be working on ICU4X impl this quarter.

So, you don't know if it has produced anything valuable yet?

It's the same story with these people running 12 parallel agents that automatically implement issues managed in Linear by an AI product team that has conducted automated market and user research.

Instead of making things, people are making things that appear busy making things. And as you point out, "but to what end?" is a really important question, often unanswered.

"It's the future, you're going to be left behind", is a common cry. The trouble is, I'm not sure I've seen anything compelling come back from that direction yet, so I'm not sure I've really been left behind at all. I'm quite happy standing where I am.

And the moment I do see something compelling come from that direction, I'll be sure to catch up, using the energy I haven't spent beating down the brush. In the meantime, I'll keep an eye on the other directions too.

> Instead of making things, people are making things that appear busy making things.

Sounds like a regular office job.

Yeah I'm not sure I understand what the goal here is. Ship of Harkinian is a rewrite not just a decompilation. As a human reverse engineer I've gotten a lot of false positives.This seems like one of those areas where hallucinations could be really insidious and hard to identify, especially for a non-expert. I've found MCP to be helpful with a lot of drudgery, but I think you would have to review the llm output, do extensive debugging/dynamic analysis, triage all potential false positives, before attempting to embark on a rewrite based on decompiled assembly... I think OoT took a team of experts collectively thousands of person-hours to fully document, it seems a bit too hopeful to want that and a rewrite just from being pushy to an agent...

Step 1: Decompile into C that can be recompiled into a working ROM. In theory, it could be compiled into the same ROM that we started with. Consistent ROM hash is the main success criteria for the OoT decompilation project. Have it grind until it succeeds.

Step 2: Integrate libultraship. Launching the game natively is the next criteria. Then ideally we could do differential testing on a frame by frame basis comparing emulated vs native.

Step 3: Semantic documentation of source. If it gets this far, I will be very impressed.

This is absolutely an experiment. It's a hard problem with low stakes. There a lot to learn from it.

Not yet. But what's the actual goal here? It's not to have a native Wave Race 64. It's to improve my intuition around what sort of tasks can be worked on 24/7 without supervision.

I have a hypothesis that I can verify the result against the original ROM. With that as the goal, I believe the agent can continue to grind on the problem until it passes that verification. I've seen it in that of other areas, but this is something larger and more tedious and I wanted to see how far it could go.

That sound like being a manager IRL.