Hacker News Reader

Comment by masukomi | Hacker News Reader

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/

View on HN

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

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.

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.

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.

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

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.

> Is Crystal a superset of Ruby where any valid Ruby project is a valid Crystal project

No. So the idea pretty much stops there.

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.

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).

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.

Thank you for the correction, I was not aware of this.

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

Reply on news.ycombinator.com