The actual memory usage is coming from the number of instantiated methods. If you write a method, it gets an entirely new implementation of it copied and compiled for every different list of argument types. For example,

    def foo(bar)
      bar + bar
    end
    
    bar1 : Int32
    foo(bar1)
    
    bar2 : String
    foo(bar1)
    
    bar2 : Int32 | String
    foo(bar1)

The above code gives you three methods to generate code for: foo(Int32), foo(String), foo(Int32 | String).

This isn't really a problem for small projects, but with large projects (60k+ loc), you end up with some methods such as puts, Array(T)#<<, etc with thousands of instantiations.

We have some edge-case semantics (we don't cast arguments to their restriction types, which we plan to remove before 1.0) which also prevent us from allowing only instantiating foo(Int32 | String) when we change the definition to `def foo(bar : Int32 | String)`. Hopefully in the future, we can allow the compiler to take advantage of method argument type restrictions to reduce the number of instantiated methods and speed up the compiler.

That doesn't mean the compiler will be super slow if you don't annotate your methods, it just means that the stdlib and shards' public API will start annotating it's method arguments more (which gives you better docs and error messages anyway).

For more info: https://github.com/crystal-lang/crystal/issues/4864

They also have a very detailed blog post about how their compiler works: https://crystal-lang.org/2015/03/04/internals.html

> On the other hand I've read reports that sufficiently large codebases begin to hit machine memory limits for the compiler because they have to scan and construct every possible union type in the codebase

I'd be interested why a compiler would even need to do so in the first place --- constructing every possible one instead of every one it encounters as clearly needed right now.

Edit: OK I see it now, you can have stuff like Int32|String. Still though.. TS can "handle" that too?

Maybe we're confusing type inference with code generation here? TypeScript doesn't compile to machine code ahead of time, it only has to verify the types.

Here is one of the creators of the language talking about the global type inference of Crystal:

https://www.youtube.com/watch?v=xbdVs4FhZac&t=16m

What are some annoying parts of Ruby?

It's a personal preference, but I'm talking specifically about most meta programming functionality (eval, define_method, etc...). It can lead to obtuse code in the hands of both experts and beginners who are looking for the most clever way to DRY up code.

And if it that were the worst part of meta programming, that might be ok, but it's not because the existence of meta programming puts ceiling on just how fast the Ruby runtime can be.

Yep. It’s not annoying in libraries or frameworks, but when you see engineers meta programming business logic it makes me sad.

Why does it? If the metaprogramming is readable and sound, I don't see where the problem is. Most of the time, good meta-programming can turn 30 lines into 5, which is not systematically better for the reader, but can help avoid some of the most mundane repetition.

It's true that it shouldn't be abused and it most often is, but it does have its place.

So can composition.

It makes me sad for the reason you said, it’s most often abused.

Thank you for the insightful response.

I'll never ever touch upon these areas, so I still hold Ruby to a high regard. It simply is fun.