4 ms·

That's true, but according to my experience, it's usually better to perform gradual migrations like from Ruby to Crystal, if it can't solve the problem, try som

by htfy96 8y ago

That's true, but according to my experience, it's usually better to perform gradual migrations like from Ruby to Crystal, if it can't solve the problem, try some other GC-based languages like Go. Things like Rust should be the last resort, especially when there is no Rust expert in your team. EDIT: as some people explained below, this is certainly another trade-off. My experience is based on a case where the team was made of non-talented engineers and many of them stick to the same language in their whole career path.

skywhopper 8y ago
Meh, expertise can be cultivated internally with strong, open minded engineers. They won’t get it all right first thing but it’s just another tradeoff.
james_s_tayler 8y ago
Crystal isn't exactly something I'd run in production. Besides it's crippled as a language due to never allowing anything to be null, so there isn't any powerful metaprogramming you can do with it. That is a big turn off for me. Otherwise Crystal would be such a nice sweet spot IMO .
- realusername 8y ago
  Not allowing NULL & having weak metaprogramming options sounds like advantages to me. you still have metaprogramming using language templates & scope shadowing, that's not at runtime but it's clearly good enough. The problem with Crystal is more with the small community than the concept itself which is pretty good IMO.
  - james_s_tayler 8y ago
    I'm not feeling it. Compile time only metaprogramming just doesn't feel powerful enough. Just a personal thing. I'm definitely a fan of Crystal of though as a project and would really like to see a bigger community and more libraries etc.
    - realusername 8y ago
      They don't do it because runtime metaprogramming has a lot of disadvantages, it's difficult to optimize so it runs poorly, it throws away the static typing out of the window and it's difficult to debug. I spent hours debugging Rails code in the past because of the layers of monkey patching.
      - james_s_tayler 8y ago
        It also has a lot of advantages. It's as powerful as it is dangerous. The real reason they don't do it is because they can't. It's inherently unsafe. In order to always be sure something is never null you have to be aware of what all it's inputs are so you can reason about it. That's not possible with runtime metaprogramming techniques. I dunno I guess I just think it's an odd choice. Don't get me wrong, it's a neat experiment and I value it. I'm just slightly miffed that that particular experiment had to mixed in with what amounts to a statically typed language with the beauty and simplicity of Ruby but the friendliness and discoverability of static typing.
    - galfarragem 8y ago
      > would like to see a bigger community and more libraries Better Windows support could make wonders.
- icebraining 8y ago
  Why would you need nulls to do metaprogramming?
  - james_s_tayler 8y ago
    Because it usually involves doing a lot of things that are unsafe. Take reflection for instance. There is no way to guarantee at compile time that a string whose value is only known at run-time is actually a real method in the code that can be invoked. To get the level of safety they have gone for they have to disallow anything that could potentially blow up.
    - icebraining 8y ago
      Why would that require nulls? They could use an Option type or just throw an exception.
- yxhuvud 8y ago
  Uh, it allows stuff to be nil if you declare the type of something to include nil. But then you also have to handle it. In practice, it make my code better.
SomethingOrNot 8y ago
Many HN readers seem to be perpetually surrounded by non-talented engineers and all other sorts of mediocre people. https://xkcd.com/610/ https://xkcd.com/610/
- htfy96 8y ago
  This xkcd comic is not the case - I also consider myself as a mediocre people
unrealhoang 8y ago
To migrate gradually (and gain performance along the way) is exactly why they chose Rust. Go and Crystal have a runtime and thus can’t be easily cross-language called as they need to be run separately and communicate over network or other type of IPC, whereas it’s just a function call (and type conversion) in case of Rust FFI.

by htfy96 8y ago

skywhopper 8y ago

Meh, expertise can be cultivated internally with strong, open minded engineers. They won’t get it all right first thing but it’s just another tradeoff.

james_s_tayler 8y ago

Crystal isn't exactly something I'd run in production. Besides it's crippled as a language due to never allowing anything to be null, so there isn't any powerful metaprogramming you can do with it. That is a big turn off for me. Otherwise Crystal would be such a nice sweet spot IMO .

realusername 8y ago
Not allowing NULL & having weak metaprogramming options sounds like advantages to me. you still have metaprogramming using language templates & scope shadowing, that's not at runtime but it's clearly good enough. The problem with Crystal is more with the small community than the concept itself which is pretty good IMO.
- james_s_tayler 8y ago
  I'm not feeling it. Compile time only metaprogramming just doesn't feel powerful enough. Just a personal thing. I'm definitely a fan of Crystal of though as a project and would really like to see a bigger community and more libraries etc.
  - realusername 8y ago
    They don't do it because runtime metaprogramming has a lot of disadvantages, it's difficult to optimize so it runs poorly, it throws away the static typing out of the window and it's difficult to debug. I spent hours debugging Rails code in the past because of the layers of monkey patching.
    - james_s_tayler 8y ago
      It also has a lot of advantages. It's as powerful as it is dangerous. The real reason they don't do it is because they can't. It's inherently unsafe. In order to always be sure something is never null you have to be aware of what all it's inputs are so you can reason about it. That's not possible with runtime metaprogramming techniques. I dunno I guess I just think it's an odd choice. Don't get me wrong, it's a neat experiment and I value it. I'm just slightly miffed that that particular experiment had to mixed in with what amounts to a statically typed language with the beauty and simplicity of Ruby but the friendliness and discoverability of static typing.
  - galfarragem 8y ago
    > would like to see a bigger community and more libraries Better Windows support could make wonders.
icebraining 8y ago
Why would you need nulls to do metaprogramming?
- james_s_tayler 8y ago
  Because it usually involves doing a lot of things that are unsafe. Take reflection for instance. There is no way to guarantee at compile time that a string whose value is only known at run-time is actually a real method in the code that can be invoked. To get the level of safety they have gone for they have to disallow anything that could potentially blow up.
  - icebraining 8y ago
    Why would that require nulls? They could use an Option type or just throw an exception.
yxhuvud 8y ago
Uh, it allows stuff to be nil if you declare the type of something to include nil. But then you also have to handle it. In practice, it make my code better.

SomethingOrNot 8y ago

Many HN readers seem to be perpetually surrounded by non-talented engineers and all other sorts of mediocre people. https://xkcd.com/610/ https://xkcd.com/610/

htfy96 8y ago
This xkcd comic is not the case - I also consider myself as a mediocre people

unrealhoang 8y ago

To migrate gradually (and gain performance along the way) is exactly why they chose Rust. Go and Crystal have a runtime and thus can’t be easily cross-language called as they need to be run separately and communicate over network or other type of IPC, whereas it’s just a function call (and type conversion) in case of Rust FFI.