As a long time Dart/Flutter developer, I think Dart is slowly making its way to the server too. It’s more performant than Python (and I assume Ruby too), and nicer to work with than other statically typed languages (which I guess are mostly JVM or CLR based).

The third party package ecosystem is smaller but I think this will become less and less relevant as coding agents get better.

▲

autogn0me 10 hours ago | parent | next [-]

Agreed.

I feel like dart is where Python was 20 years ago. It’s exciting and its integration story is taking off.

▲

stephenhuey 8 hours ago | parent [-]

As a Ruby dev who has built a couple Flutter apps, I was surprised how pleasant Dart was compared to JavaScript and TypeScript, and I sincerely hope it largely replaces those on both client and server.

	▲	dismalaf 2 hours ago \| parent [-]
		Unfortunately Google gave up on Dartium a long time ago...

▲

solatic 8 hours ago | parent | prev [-]

> third party ecosystem is smaller... less and less relevant as coding agents get better

I disagree. The problem isn't with getting an implementation for some favored sort algorithm, it's about integrating with external systems. That's a million times easier when you're not crafting the equivalent of an untyped curl call dealing with raw JSON bodies and can instead use official SDKs provided by the external system provider.

Not even GCP offers a client SDK in Dart, let alone AWS or Azure. Sure, there's a Postgres package for Dart, but you're working with raw arrays on the result rows - no Dart support in sqlc. What about a payment provider like Stripe? Nope. Or an email provider like SendGrid? Also no.

I mean... this is one of the reasons why Go is so popular. You're practically guaranteed to find an SDK for the service you need to connect to. And that's not because the Go team at Google had some special marketing magic that the Dart team at Google didn't have access to, that's just organic growth. Do you really think services are going to wake up across the industry and start offering Dart SDKs??

▲

nmfisher 8 hours ago | parent [-]

That was my point about coding agents - as long as there's a standard protocol (usually HTTP REST), Claude Opus could roll out a client library in almost the same amount of time it would take me to find the right name for the official pip package. Equally, they make it a lot easier for providers to roll out official SDKs. I did this recently for Tencent's Hunyuan API and I didn't even have to think about it. This type of API integration will be trivially solvable in the near future.

	▲	solatic 5 hours ago \| parent [-]
		I see what you're saying, and I recognize that a coding agent will spit out something usable, but it still feels wrong. When a service provider puts out an SDK, they are responsible for it and are incentivized to update it when their API updates. If I ask an LLM to generate an SDK for me, then I am responsible for the SDK code despite the fact that I am not responsible for the API itself. This is not good Conway's Law alignment; it's the kind of thing you do when you have no other choice but to accept the debt that comes with it.