5 ms·

Crystal really does feel like Ruby without the annoying parts, plus the macro system feels like a _better_ meta programming facility. On the other hand I've re

Crystal really does feel like Ruby without the annoying parts, plus the macro system feels like a _better_ meta programming facility. 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. Not sure what there is to do about that other than bisecting the codebase into shared libraries over time.

unixhero 9y ago
What are some annoying parts of Ruby?
- look_lookatme 9y ago
  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.
  - odammit 9y ago
    Yep. It’s not annoying in libraries or frameworks, but when you see engineers meta programming business logic it makes me sad.
    - VeejayRampay 9y ago
      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.
      - odammit 9y ago
        So can composition. It makes me sad for the reason you said, it’s most often abused.
  - unixhero 9y ago
    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.
dualogy 9y ago
> 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?
- vanderZwan 9y ago
  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 https://www.youtube.com/watch?v=xbdVs4FhZac&t=16m
RX14 9y ago
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 https://github.com/crystal-lang/crystal/issues/4864
- nerdponx 9y ago
  They also have a very detailed blog post about how their compiler works: https://crystal-lang.org/2015/03/04/internals.html https://crystal-lang.org/2015/03/04/internals.html

unixhero 9y ago

What are some annoying parts of Ruby?

look_lookatme 9y ago
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.
- odammit 9y ago
  Yep. It’s not annoying in libraries or frameworks, but when you see engineers meta programming business logic it makes me sad.
  - VeejayRampay 9y ago
    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.
    - odammit 9y ago
      So can composition. It makes me sad for the reason you said, it’s most often abused.
- unixhero 9y ago
  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.

dualogy 9y ago

> 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?

vanderZwan 9y ago
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 https://www.youtube.com/watch?v=xbdVs4FhZac&t=16m

RX14 9y ago

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 https://github.com/crystal-lang/crystal/issues/4864

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