I'm building a product on the Claude Agent SDK, and it is the best in a specific way.
Codex and Open Code are competition for coding, but if we talk about an open-ended agentic harness for doing useful work... well it was bad enough a year ago I'd consider anyone even claiming one exists to be a grifter and now we have one.
And while being first might not matter, I think having both post-training and the harness being developed under the same roof is going to be hard to beat.
There's also a meta aspect here, where the leading third party harness in this discussion is run someone who's chronically steeped in Twitter drama and is definitely not rushing to put this to bed.
Add in various 2nd/3rd place players (Codex and Copilot) with employees openly using their personal accounts to cash in on the situation and there's a lot of amplification going on here.
Yea, SMS and phone apps are quite numerous. I don't think it's a problem, the subsystems all the apps use is open enough and not hard to build against.
Except for RCS, that's completely locked down and is pretty solidly becoming literally just Google. Fuck RCS.
Not just Google is the problem, the entire industry is the problem. Almost all of the cell-based standards are locked away and purely depend on the operators, major infrastructure companies like Motorola, Ericsson and Huawei and modem implementors like Qualcomm, Apple or Broadcom.
Implementing them independently is extremely difficult and even if you manage to do it you cannot have them commercially available due to radio regulation and patents. Even academic research can only be done with collaboration of those huge companies.
It is impossible to make a phone that is LTE capable completely independently (or even without nation state support). You cannot implement VoLTE or RCS without support from the carriers. They all have their own proprietary protocol on top of the standards.
Google has basically infinite money and their own patents and industry relationships and government support so they can figure out RCS. An indie company, even with infinitely motivated engineers and good funding do not have any of it.
I disagree. The bare minimum they could have done in all these years was build a proper high quality, tightly coupled component library instead of riding this "copy paste your way to a result" trend.
Not stuff like shadcn and Tailwind Catalyst, but a proper versioned, tightly coupled UI library with rich theming capabilities made for the 99% of users who aren't skilled enough at design to be cobbling together their own design systems or editing a Button component directly.
Instead they rode the wave (despite being best positioned to redirect the wave) and they're paying the price.
If it wasn't AI it'd be the first version of MUI that moves on from Material Design 2 as a default. Or Hero UI v3. Or literally anyone who brings sanity back to the space of component libraries and leaves "copy and paste code snippets" behind
There are more knobs to turn when you have an actual library, and you become a lot less fungible than a random collection of TW classes.
HeroUI faces the same problem, and now their React Native library includes an optional (paid) conpiler solution that makes it faster.
MUI has the same problem but besides templates they have their MUI X data components which aren't limited in complexity to what can be ergonomically copy and pasted to a clipboard.
Splitting example is way too much indirection, but capturing what the code does in the code itself is a preference for me. In any high level language don't know why the middleground wasn't explored:
Technically this performs worse because you lose short-circuiting, but in performance-sensitive contexts code styling is less a concern anyways. And I also wouldn't rely on short-cutting alone to avoid a really expensive operation or side-effect: at some point someone will fail to notice it.
The compiler would have to determine that these are pure calls which I wouldn't rely on if performance actually matters
I just tested a recent gcc at -O2 with a contrived example using strings in an unordered_set: a look-up always occurs if not relying on short-circuiting
I like your version, and it's certainly possible to split too much without any practical result just for the dogma. But wrt the particular example I can see what's going on with a glance over the split part, while I have to focus at the commented one. Comments themselves can be helpful, but they can also be misleading cause code and coder's thoughts are not guaranteed to be in harmony all the time.
Darts pretty good. It has a lot of modern features, nullable types, pattern matching, sum types, and factory constructors; some really good build tooling. It can compile fully AoT.
Eh, it's getting there, slowly at first but more rapidly now. It now got tearoffs, I explained in another comment but
> if you have an `enum Color { red, blue }` and a function takes `Color`, you can just do `f(.red)` not `f(Color.red)`
Dart is getting new features pretty fast, they really started focusing on the DX more after Dart 2 and now especially after Dart 3. Macros were supposed to ship but it was incompatible with the goals of fast compilation, so other sorts of smaller features will ship instead.
Big turnoff with Dart is the lack of json (de) serialization -- kind of shocking to have to resort to source code generation libraries in a modern language.
Also, statement based instead of expression based, and not immutable by default are kind of a drag; not the end of the world but a bit unpleasant, IMO.
Serialization support is coming, probably this year. As for statements vs expressions, it does have some expressions such as if and for inside lists but changing it wholesale to an expression based language would be too much of a breaking change.
Serialization support has been coming for years, I lost patience.
Otherwise, yes, some support for expressions, some support for immutability, no support for optional semi-colons, no privacy modifiers so "_" littered everywhere.
I just found it to be an exceedingly ugly language when I used it a couple of years ago. Yes, some more pleasant modern functionality has been bolted on since then, but it's unfortunate that Dart was chosen as the backing language for Flutter, which is an awesome mobile framework.
Serialization has always been possible via libraries, so most people were doing fine with that, what is coming is native serialization support, but in practice it will be functionally the same, ie rather than you running build_runner, the compiler will do it for you. I'm not sure what you used but that's what you were hung up on, there were always ways to solve it.
Dart is a pragmatic language, it has everything you need and has a lot of benefits too, such as sound null checking (very few languages have this, Rust comes to mind), JIT and AOT support (Javascript / TypeScript such as for React Native doesn't, and Kotlin is just getting there with Kotlin Native but it still has a lot of issues), and now more functional programming concepts with algebraic data types via sealed classes and pattern matching.
What language would you have chosen when Flutter came out circa a decade ago, or, we can be even more charitable and ask what language would you use today if you were to implement Flutter? I'm curious because everyone has their own ideas but they all don't work for one reason or another.
isn't this just because Dart is way newer than those? it's from the 2010s. it's really modern in comparison (same generation as Kotlin swift and typescript)
Dart is hands down the best modern language out there for app development right now what are you even talking about? I understand that maybe a lot of people haven’t used it or maybe haven’t used it in years and that probably drives a lot of the FUD but for those who use it, it has stupidly high ratings from developers who use it and has for years.
Great progress! But smells a lot like the language I had it pegged for when "underscore as a wildcard" lands in February 2025, 2 years after pattern matching lands.
How did they ship pattern matching in 2023, with a million examples of how to do it right already hashed out and in the wild... and then not figure out a wildcard symbol for 2 years?
-
* Dart was awful, lost to Javascript because no one rated it highly enough to justify moving off Javascript, and was practically dead until Flutter dusted off the corpse and pivoted away from their browser goals... so super weird revisionism to act like we're talking about some beloved evergreen language.
> How did they ship pattern matching in 2023, with a million examples of how to do it right already hashed out and in the wild... and then not figure out a wildcard symbol for 2 years?
We shipped support for `_` as wildcards in patterns with Dart 3.0 when pattern matching first shipped.
However, prior to Dart 3.0, `_` was already a valid identifier (as it is in most other languages). The feature you're mentioning from last year was to remove support for uses of `_` as an identifier outside of patterns. This way `_` consistently behaves like a wildcard everywhere in the language. We didn't ship that in 3.0 because it's a breaking change and those are harder to roll out without causing a lot of user pain.
It's OK to not like Dart. There are multiple popular languages for a reason. But it is helpful when communicating about a language to others to be accurate so that they can make their own informed opinions.
Dart wasn’t awful. It wasn’t adopted at the time because it had a distinct runtime that would require splitting web in two which nobody wanted. On top of that it gave Google too much power, because now they would control both runtime (V8) + language (Dart).
TypeScript won and became king because it was pretty much JS 2.0 instead of JS++ like Dart.
In your version of history Dart was always a great language... but Google was simultaneously too powerful for other vendors to allow Dart to proliferate, but also too weak to sustain it themselves despite Chrome going on to do just that for many many web standards.
I'm sure that's a really cozy idea, but doesn't pass the "common sense" test: a bit like your random misuse of the term FUD.
-
The simple reality is it wasn't very good, so no one was rushing to use it, and that limited how hard Google could push it. ES6 made Javascript good enough for the time being.
Dart 1.x had a weak type system, and Dart 2 was adding basics Kotlin already had almost 2 years earlier: that was also around the time I first crossed paths with Flutter, and honestly Flutter by itself was also pretty god awful since it was slowly reinventing native UI/UX from a canvas.
(It was a lot like Ionic: something you used when you had a captive user-base that literally couldn't pick a better product. Great for Google!)
> In your version of history Dart was always a great language... but Google was simultaneously too powerful for other vendors to allow Dart to proliferate, but also too weak to sustain it themselves despite Chrome going on to do just that for many many web standards.
"In my version of history"
It takes two seconds to find this if you weren't there when it happened. Google had a fork of Chromium with Dart VM called Dartium, it wasn't a matter of resources. Industry flipped Google off, plain and simple.
Educate yourself before making such claims, the decision to not adopt Dart wasn't because of its technical merits as a language.
The rest of your comment is just your opinion, so you do you. I'm not a Dart or Flutter devrel team to sell you their product.
I guess this is the Dunning-Kruger effect everyone talks about!
To understand just enough to regurgitate what happened, but miss why it happened... and then assume someone who's pointing at the much more relevant why is just plain wrong.
Because the why requires actually understanding of things like developer mindshare rather than regurgitating search results.
-
The hint I'll leave if you're willing to consider maybe you don't know everything ever... look at who's feedback is being promoted when Chrome wants to do obviously unpopular things on the web: https://github.com/webmachinelearning/prompt-api/blob/main/R...
And model for yourself what happens if developer interest exceeds vendor refusal in magnitude, so Google just ships the thing, without a feature flag, to a massive percentage of the web-going world.
I feel like programmers model the law as a programming language, while it only works like that in very limited contexts.
They said Raspberry PI, but the spirit of the rule is "electronic looking thing that we can't immediately determine the function of". You could probably show up with an unpopulated PCB and get turned away because it's green.
Codex and Open Code are competition for coding, but if we talk about an open-ended agentic harness for doing useful work... well it was bad enough a year ago I'd consider anyone even claiming one exists to be a grifter and now we have one.
And while being first might not matter, I think having both post-training and the harness being developed under the same roof is going to be hard to beat.
reply