| ▲ | 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. |
|
| ▲ | pxc 5 hours ago | parent | next [-] |
| 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? |
| |
| ▲ | solatic 5 hours ago | parent [-] | | 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. |
|
|
| ▲ | nmfisher 11 hours ago | parent | prev | next [-] |
| 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. | | |
| |
| ▲ | 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. |
|
|
|
|
| ▲ | stephenhuey 8 hours ago | parent | prev | next [-] |
| 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/ |
|
| ▲ | pamcake 8 hours ago | parent | prev [-] |
| [dead] |
