Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Embed Crystal code directly in Ruby

github.com

Post reply on HN
Print view View original

21–30 of 65 posts

Re: Embed Crystal code directly in Ruby

#21

Post by mathverse »

celdon25 wrote: post #11
edvinbesic wrote: post #3

What is the current state of crystal toolchain? Last time I used it I really enjoyed the language but the compilation times were a bit of a turn off.

You won't ever see fast compilation times with it, and here's why: > type annotations are rarely necessary, thanks to powerful type inference. This keeps the code clean and feels like a dynamic language.[1] I prefer Sorbet[2] for Ruby, which is pretty fast and a reasonable compromise. People complain about the verbosity, but you can't have both speed and type inference. Pick one. Some of the verbosity in Sorbet, howe…

Could not in theory the stdlib and most used libraries be heavily type annotated to assist the compiler?

Re: Embed Crystal code directly in Ruby

#22

Post by jpgvm »

celdon25 wrote: post #11
edvinbesic wrote: post #3

What is the current state of crystal toolchain? Last time I used it I really enjoyed the language but the compilation times were a bit of a turn off.

You won't ever see fast compilation times with it, and here's why: > type annotations are rarely necessary, thanks to powerful type inference. This keeps the code clean and feels like a dynamic language.[1] I prefer Sorbet[2] for Ruby, which is pretty fast and a reasonable compromise. People complain about the verbosity, but you can't have both speed and type inference. Pick one. Some of the verbosity in Sorbet, howe…

Kotlin strikes a good middle ground on the fast compilation inference continuum IMO. within function bodies you rarely need to think about the typing system. Function return types can be inferred for expression bodies and star projections can make some of the more tricky parts of generics more tractable.

Inference is a big part of what increases Kotlin ergo over Java and while it does compile slower you are going from a very fast base so it doesn't feel slow relative to other options.

Re: Embed Crystal code directly in Ruby

#23

Post by Alifatisk »

yxhuvud wrote: post #17

Very, very impressive. It will be very interesting to see how much of crystal is supported, of IO and fibers and gc etc.

Yeah, I was wondering the same here. How much of Crystals feature can I use here? If it is everything then this is a game changer.

Re: Embed Crystal code directly in Ruby

#25

Post by celdon25 »

nextaccountic wrote: post #20
celdon25 wrote: post #11

Earlier quoted context omitted.

You won't ever see fast compilation times with it, and here's why: > type annotations are rarely necessary, thanks to powerful type inference. This keeps the code clean and feels like a dynamic language.[1] I prefer Sorbet[2] for Ruby, which is pretty fast and a reasonable compromise. People complain about the verbosity, but you can't have both speed and type inference. Pick one. Some of the verbosity in Sorbet, howe…

> You won't ever see fast compilation times with it, and here's why: > > type annotations are rarely necessary, thanks to powerful type inference. This keeps the code clean and feels like a dynamic language.[1] There are fast type inference implementations. For example, the OCaml compiler is pretty fast No reason Crystal couldn't improve this part of compile time in future

I suspect that doesn't hold true for some larger projects (10K+ LOC) with no annotations but point taken.

My experience with F# (which was way back in version 2.0, but based on OCaml which does type inference very similarly), was that the inference would become slower as the size of the project increased, eventually taking multiple seconds. I eventually adopted a habit of adding type annotations to commonly-used functions because it mitigated the problem. These projects were not huge by any means (5-10K LOC).

There is probably a good compromise to be found here. It should be possible for a tool to suggest areas to add annotations where it would do the most good for performance. But maybe those are non issues with modern implementations.

Re: Embed Crystal code directly in Ruby

#26

Post by freilanzer »

virtualwhys wrote: post #19
celdon25 wrote: post #11

Earlier quoted context omitted.

You won't ever see fast compilation times with it, and here's why: > type annotations are rarely necessary, thanks to powerful type inference. This keeps the code clean and feels like a dynamic language.[1] I prefer Sorbet[2] for Ruby, which is pretty fast and a reasonable compromise. People complain about the verbosity, but you can't have both speed and type inference. Pick one. Some of the verbosity in Sorbet, howe…

> but you can't have both speed and type inference. Pick one. With OCaml you can pick two :)

But then Id have to use Ocaml. ;)

Re: Embed Crystal code directly in Ruby

#27

Post by Alifatisk »

I read that during the first run, it will be slower because of the crystal code being compiled. Is the compiled code stored somewhere?

I am asking this because in that case, can’t I run it myself and share the code with the precompiled parts so others don’t have to experience the slow start?

Re: Embed Crystal code directly in Ruby

#28

Post by aardvark179 »

celdon25 wrote: post #12
mdaniel wrote: post #9

Earlier quoted context omitted.

> to ruby. I also worry that it would make it too magical and difficult to figure out what code is running, where and when Coming from both python and statically-typed languages, your description 100% squares up with every experience I've had with ruby Folks are free to throw stones at the Spring Framework similarly, it's not out of bounds, but ruby seems to embrace the monkeypatch

> ruby seems to embrace the monkeypatch How recent were your experiences with this? In recent years I've seen monkeypatching treated as more of an antipattern. If you are on a project where people are doing that without very good reasons, that says more about the team than the language.

It is still prevalent enough that when developing Ruby JITs it can be worthwhile delaying compilation until the framework has started up and finished invalidating all your method lookups, or changing your invalidation strategy to handle new methods being defined on Object without invalidating all your inline caches.

Re: Embed Crystal code directly in Ruby

#29

Post by actionfromafar »

mathverse wrote: post #21
celdon25 wrote: post #11

Earlier quoted context omitted.

You won't ever see fast compilation times with it, and here's why: > type annotations are rarely necessary, thanks to powerful type inference. This keeps the code clean and feels like a dynamic language.[1] I prefer Sorbet[2] for Ruby, which is pretty fast and a reasonable compromise. People complain about the verbosity, but you can't have both speed and type inference. Pick one. Some of the verbosity in Sorbet, howe…

Could not in theory the stdlib and most used libraries be heavily type annotated to assist the compiler?

The compiler could grow a cache of sorts, analysing "bubbles" of code which does not touch other bubbles and keep type info (and compilation output!).

Re: Embed Crystal code directly in Ruby

#30

Post by rco8786 »

MatmaRex wrote: post #6

Everything old is new again… https://github.com/seattlerb/rubyinline (2002)

I don’t think the author is claiming that code interop is new.

But this does seem to be the first attempt at interop between crystal and Ruby, which is notable because crystal is effectively a typesafe Ruby.

Post reply on HN