Comment by solatic
11 hours ago
> Ruby really needs a plan
If there was a plan to be had here, it would be to merge with Crystal and focus on building native apps for phones. Nobody is really happy with any of the options there - Dart/Flutter were close, but fail on the server side. Kotlin Multiplatform is making a serious go at it but it's still too complicated. Bringing the ease of Rails development to native mobile app development would be huge.
What does "merge with Crystal" mean, when Ruby is a deeply dynamic language and Crystal is statically typed? Write/endorse a Ruby implementation in Crystal? Create frameworks for various kinds of applications that let you easily use Ruby for some components and Crystal for others? Other general work on interop?
Merge with Crystal meaning, recognize that both projects have more in common from a language and culture perspective than they are different, get the committers and steering folk to talk together, collaborate together, combine the work. Think for example how Python has a great C FFI, you have a highly dynamic Python layer that can sit on top of C code for optimized hotpath code. Now imagine you instead have a highly dynamic Ruby layer with great integration with a Crystal layer for optimized hotpath code, where because the Ruby and Crystal folks are working together, everything is a first class citizen, all the code is in the same language family, using the same build toolchain, packaging toolchain, etc. Write standard Crystal libraries for compiling to native mobile platforms and write Rails-style views in Ruby for mobile app views, for example.
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.
Agreed.
I feel like dart is where Python was 20 years ago. It’s exciting and its integration story is taking off.
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.
1 reply →
> 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??
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.
1 reply →
I know it’s not exactly what you’re looking for, but many years ago I tinkered with RubyMotion, and in recent years I have successfully launched in the app stores with the mobile versions of Jumpstart Pro using way less effort than a Swift or Kotlin developer would due to the way Jumpstart Rails integrates nicely with their iOS and Android templates.
https://jumpstartrails.com/
[dead]