3 ms·

ok this is going to sound snarky but it's an honest question: Why not just use Crystal[1]? It's basically just compiled ruby with static types, and it can infe

ok this is going to sound snarky but it's an honest question: Why not just use Crystal[1]? It's basically just compiled ruby with static types, and it can infer types correctly in most cases without you explicitly noting which they are. The best argument for this (instead of Crystal) is keeping access to ruby gems. [1]: https://crystal-lang.org/ https://crystal-lang.org/

CGamesPlay 8y ago
My 100k LOC code base is already written in ruby though. I have to rewrite everything?
- masukomi 8y ago
  yeah. that's a pretty compelling reason, but on the other hand, there's a lot of value to be had from modularizing your codebase and microservices so... you could do all future dev in a new language, and if you wanted, gradually convert your existing modules. Sadly, few places think far enough ahead to see the values of modularity (even ignoring language switching) and end up with giant monolithic codebases so language switching just isn't an option without a complete rewrite.
  - mmartinson 8y ago
    While you have some good points, I'm not sure monolith and modularity are mutually exclusive. Some places I'm sure think some places think far ahead, and determine that the cost of microservices isn't worth the later benefit while they're trying to bootstrap a project.
parvenu74 8y ago
Is Crystal a superset of Ruby where any valid Ruby project is a valid Crystal project -- just lacking type definition? If Crystal can do that then I think adoption of Crystal would benefit greatly.
- chrisseaton 8y ago
  > Is Crystal a superset of Ruby where any valid Ruby project is a valid Crystal project No. So the idea pretty much stops there.
- masukomi 8y ago
  As @chrisseaton said, no, BUT some ruby is valid Crystal. I think it would be more accurate to say that a subset of Crystal is valid Ruby, and a subset of Ruby is valid Crystal.
  - freedomben 8y ago
    That's correct. You can run your Crystal programs with the Ruby interpreter, but you can't compile your Ruby to Crystal (simple scripts usually work, but bigger things that use use gems probably won't).
    - djur 8y ago
      You can't run a lot of Crystal code in Ruby, either. They implement keyword arguments completely differently (Crystal does it more like Python, where all arguments can be specified by name or position) and of course Ruby doesn't support Crystal syntax relating to types. Crystal also has a tuple type with a literal syntax ({1, 2, 3}) that isn't valid Ruby. But otherwise it's fairly close.
      - freedomben 8y ago
        Thank you for the correction, I was not aware of this.
naiyt 8y ago
For me it would have the same things that make Typescript appealing: - Full access to a large and mature ecosystem (one that Crystal doesn't quite have) - The ability to gradually add typing to an existing Ruby codebase. No need to rewrite an entire application. Just gradually add types to new code and during refactors. If I was starting a new project I would definitely be considering Crystal, but I still feel like something like this would be great. Typescript has been a godsend for my frontend development life, and I would love to have something like this for my backend Ruby development.
- creyes 8y ago
  I've been working with Lucky and working with a bit of Crystal - it's still not quite there yet. When we were working on a recent release of Lucky we found a kinda breaking in the compiler that the team fixed pretty quickly but it still shows just how new it is. I'm optimistic for 1.0 though That said, Flow style gradual/optional typing in Ruby would be awesome
jashmatthews 8y ago
It’s not just compiled Ruby, but a completely different language with a superficially similar syntax. You can’t really port anything.

CGamesPlay 8y ago

My 100k LOC code base is already written in ruby though. I have to rewrite everything?

masukomi 8y ago
yeah. that's a pretty compelling reason, but on the other hand, there's a lot of value to be had from modularizing your codebase and microservices so... you could do all future dev in a new language, and if you wanted, gradually convert your existing modules. Sadly, few places think far enough ahead to see the values of modularity (even ignoring language switching) and end up with giant monolithic codebases so language switching just isn't an option without a complete rewrite.
- mmartinson 8y ago
  While you have some good points, I'm not sure monolith and modularity are mutually exclusive. Some places I'm sure think some places think far ahead, and determine that the cost of microservices isn't worth the later benefit while they're trying to bootstrap a project.

parvenu74 8y ago

Is Crystal a superset of Ruby where any valid Ruby project is a valid Crystal project -- just lacking type definition? If Crystal can do that then I think adoption of Crystal would benefit greatly.

chrisseaton 8y ago
> Is Crystal a superset of Ruby where any valid Ruby project is a valid Crystal project No. So the idea pretty much stops there.
masukomi 8y ago
As @chrisseaton said, no, BUT some ruby is valid Crystal. I think it would be more accurate to say that a subset of Crystal is valid Ruby, and a subset of Ruby is valid Crystal.
- freedomben 8y ago
  That's correct. You can run your Crystal programs with the Ruby interpreter, but you can't compile your Ruby to Crystal (simple scripts usually work, but bigger things that use use gems probably won't).
  - djur 8y ago
    You can't run a lot of Crystal code in Ruby, either. They implement keyword arguments completely differently (Crystal does it more like Python, where all arguments can be specified by name or position) and of course Ruby doesn't support Crystal syntax relating to types. Crystal also has a tuple type with a literal syntax ({1, 2, 3}) that isn't valid Ruby. But otherwise it's fairly close.
    - freedomben 8y ago
      Thank you for the correction, I was not aware of this.

naiyt 8y ago

For me it would have the same things that make Typescript appealing: - Full access to a large and mature ecosystem (one that Crystal doesn't quite have) - The ability to gradually add typing to an existing Ruby codebase. No need to rewrite an entire application. Just gradually add types to new code and during refactors. If I was starting a new project I would definitely be considering Crystal, but I still feel like something like this would be great. Typescript has been a godsend for my frontend development life, and I would love to have something like this for my backend Ruby development.

creyes 8y ago
I've been working with Lucky and working with a bit of Crystal - it's still not quite there yet. When we were working on a recent release of Lucky we found a kinda breaking in the compiler that the team fixed pretty quickly but it still shows just how new it is. I'm optimistic for 1.0 though That said, Flow style gradual/optional typing in Ruby would be awesome

jashmatthews 8y ago

It’s not just compiled Ruby, but a completely different language with a superficially similar syntax. You can’t really port anything.