11 ms·

Would a developer looking a Zig/C++/Rust really also consider Crystal? I figured Crystal was for Ruby developers who want a good static type system.

Doctor_Fegg 6y ago
Crystal's appeal, for me at least, is the productivity of Ruby with the memory efficiency and execution speed of C++. Static typing is just a way of achieving that, it's not something I'm seeking per se.
- straight-shoota 6y ago
  Remember static typing is also really useful for code quality and avoiding hidden bugs. Some code in Ruby requires a ton of specs to discover bugs caused by type issues, while the Crystal compiler tells you immediately that something doesn't work out. I love Crystal's type system really for productivity reasons.
  - sjwright 6y ago
    I haven’t ever understood the argument against static typing. I’ve never declared a variable and not simultaneously thought “this is going to be a float, always a float, never not a float.” The only exception to this is untrusted input, but for that an string is usually always fine.
    - pansa2 6y ago
      > I’ve never declared a variable and not simultaneously thought “this is going to be a float, always a float, never not a float.” Never written generic/template code? Making that much easier is one of the main benefits of dynamic typing.
      - viraptor 6y ago
        Change it to "this variable is always going to be a T, never not a T" and it still stands.
      - sjwright 6y ago
        It's possible—nay likely—that I don't understand the true value of generics. It's something that I've looked into on occasion and it never seemed all that useful to me. Most examples I've come across in the past were C++ and seemed like formalised workarounds for deficiencies in the C++ type system rather than being actually useful. I'm sure I've failed to grok them—or based on the code I write I'm not the target audience for them. I have no problem when a language allows the programmer to explicitly opt for a variable to be an undefined/dynamic type, whether as part of generics or as part of a defensive ingest of untrusted data. I admit this is previously unspecified nuance but in my mind this doesn't break my rule: "this variable is always going to be a dynamic type, never not a dynamic type." This means you know when to interact with it defensively. The thing I'd like in a hybrid static-dynamic language is type assertion blocks which restore some benefits of static typing while dealing with dynamic typed variables. E.g.: declare x as dynamic; x = untrusted_source(); if (x IS_A string) { // Inside here, x behaves as a statically typed string. // The compiler knows it and checks types appropriately. // Passing x elsewhere will send a static typed string. function_that_demands_a_string(x); } else if (x CAN_SAFELY_BECOME_A uint) { // True for any non-negative integer regardless of data type. // Inside here, x is always a statically typed uint. // If it was some other type, it was converted for me. } (This probably already exists in some language somewhere but my familiarity with languages is narrow.)
        ezrast 6y ago
        Crystal does some of what you want: https://tio.run/##ZVDBbsIwDL33KywmrRcaUXbbhHbeaYdpJ4RQaA1kCkllO6Ps57skBalshyQv7z3bT27owqLtMLS4h@CEAgu2W/aBGiwA1vEAzDSwkHGH2Tz/63p812VfzqG8pOun3IxkVS8Wqo5wo1ifOosFurYoGquZ4X33hY1EMc0TumzFb8PTMhcSSiAHjDZFsRjtCStC7rxrOXpf4XlSsMODcRndFau7ntwEvHqSmGEKNN45Wr1QYk7I0PpI97D6twk1iRotjWaEPoLzER185NXkxl0Qhl6FLjlu@uebk2ucUYfHCuolwEOMdwhWE1RA2nBM4B34b6S99eeXZDMMckQ4k@66OASixsa7W@s/u9kbYpkGuRFoGae83vFkAcPwCw https://tio.run/##ZVDBbsIwDL33KywmrRcaUXbbhHbeaYdpJ4RQaA1kCk... Note how the language is pretty smart about flow-typing variables as you narrow down their types. `x` here is typed as a tagged union (String | Int32 | Array(Char) | Float64 | UInt32), but by the time the program gets to the final `else` the compiler has figured out that the String and Array cases have already been dealt with (even though we never mentioned Array by name, just asked if the object implements a method that only Array implements), so it lets us call `x.abs`, which only works for numeric types. Of course, `abs` has different implementations for Int32 and Float64, but the signatures are compatible so the compiler lets it fly, resorting to dynamic dispatch at runtime. The missing part is that there's nothing like a CAN_SAFELY_BECOME_A operator so I had to implement that test myself (as `try_to_u32`) and call it early to get the flow typing to work. The Wikipedia article for the concept is https://en.wikipedia.org/wiki/Flow-sensitive_typing https://en.wikipedia.org/wiki/Flow-sensitive_typing
  - ncmncm 6y ago
    If all you get from static typing is runtime performance and correctness, your type system is not pulling its weight. In any serious statically-typed language, the type system does real heavy lifting. In practice that means that libraries execute code at compile time that, in effect, generate the code you would otherwise need to write (again) yourself. C, Pascal, and Go are examples of statically typed languages whose type system does only trivial work.
- onlyrealcuzzo 6y ago
  Is static typing really necessary for speed? The fastest JavaScript engines and LuaJIT are closer in speed to Crystal than Crystal is to C. Granted - all these languages are really fast - and unless you're doing something INSANELY performance dependent and you REALLY know what you're doing - I think familiarity trumps all. You're almost certainly going to write faster Crystal code if you're a Crystal expert than you would write C, C++, or Rust.
  - viraptor 6y ago
    It's not necessary strictly speaking, but it make things MUCH easier. JS in v8 has 3 (4?) layers of compilers already and each time some type changes at runtime you're taking a hit to go back to the interpreted version while functions jit compile again. There's a crazy amount of engineering effort that has to counteract a missing "this has one parameter and it's either a string or a float" annotation. In practice if you don't have a world class well funded team - yes, static typing is necessary for performance.
    - socialdemocrat 6y ago
      That is because JS was not built for JIT compilation. With a dynamic language like Julia built for JIT compilation from the very start you get both much simpler and cleaner design and higher performance. It uses a method JIT so it is deterministic and easy to analyze unlike JavaScript. You can lookup ahead of time how each function will get compiled with given input types.
      - viraptor 6y ago
        I'm not sure what you mean by this. Why do you think Julia was made for JIT from the beginning? You can't analyse functions like this ahead of time: function foo(x) x + y end You've got an Any type interacting with an Any global. There's no better answer than you'd get from JS analysis.
        eigenspace 6y ago
- socialdemocrat 6y ago
  As an old Ruby fan, you should seriously check out Julia. It had a lot of the same meta programming goodies as Ruby but with performance that often rivals C/C++. Actually I think Julia will frequently pull off being faster. It is crazy how good JIT compilation works today with a language specifically designed designed for it.
yellowapple 6y ago
I mean, as someone who previously looked at Rust and is currently looking at Zig, Crystal is certainly on my radar. That said, my current dayjob is around a Rails codebase, so I might not be representative of the normal systems programming crowd.
straight-shoota 6y ago
Crystal comes from a Ruby background, but it's far more than compiled Ruby. As a general purpose language mainly aiming at application development it can surely compete with any of the above in that field. The main objective inherited from Ruby is the focus on developer hapiness. While doing that it doesn't back down on performance or interoparability.
nwmcsween 6y ago
Ruby is a great language, the only nits I have with it are error handling, types and a bit of the perlisms and shellisms that crept in. If Crystal fixed these I would be interested
- cutler 6y ago
  Ruby stole elegant word lists %w(tic tac toe) and the regex operator =~ from Perl so I'll keep my Perlisms, thank you very much.
tomc1985 6y ago
Ruby 3 does static typing, so that would be the quickest path for static types. Crystal is interesting to me because its a systems language, using Ruby syntax and idioms. I'm a Rails developer by trade but I've been pining to go back into desktop GUI development. Right now the only viable cross-platform options seem to be Swing and Electron. I'm not sure what the desktop story is with Crystal but if it there is a workable solution based on GTK or something similar I'd be very happy!
- zem 6y ago
  still no windows support :( desktop gui development was my main wish for crystal too, but ruling out a bunch of end users right out of the box was not an option.
  - tomc1985 6y ago
    It looks like Windows support is preliminary. They are working on it...
    - atraac 6y ago
      https://github.com/crystal-lang/crystal/issues/5430 https://github.com/crystal-lang/crystal/issues/5430 this issue tracks Windows progress, it hasn't been really updated in a while. I've been following Crystal Windows port for over a year, nothing changed yet.
- viraptor 6y ago
  Ruby 3 has static typing, but it's opt-in and doesn't affect the runtime. Here it's both enforced and directly translates to better performance.
- iomcr 6y ago
  > Ruby 3 does static typing Categorically, what I've seen of this falls closer to "lintable comments" than it does "actual static types". Static types are a foundational aspect of crystal, it's not like a sticker slapped on as an after thought.
ljm 6y ago
I'd consider it more seriously now it's 1.0. You've basically got an ecosystem of Ruby-likes: - Ruby itself - Crystal - Elixir I'm massively keen on Zig, too, but it still feels like early days for the language itself. The C-interop is utterly astounding but I don't want to write Zig as syntax-sugar around C libraries.
- ksec 6y ago
  And Julia as well.
  - forgotpwd16 6y ago
    Julia if anything is unlike Ruby. The very first Ruby example on the official site showcases its object-oriented nature. Julia instead of objects has multiple dispatch.
    - cbkeller 6y ago
      On one hand you're absolutely correct in that Julia is dispatch-oriented, and doesn't have ton in common with what is commonly considered OOP today. However, as far as I understand it there is also an argument to be made that multiple dispatch is at least as close to Alan Kay’s original intent for OO (e.g. [1]) than is the currently-ubiquitous class-based version of OO that leads to things like `RequestProcessorFactoryFactory` s with `RequestProcessorFactoryFactory.getRequestProcessorFactory(Class)` methods. [1] https://medium.com/javascript-scene/the-forgotten-history-of-oop-88d71b9b2d9f https://medium.com/javascript-scene/the-forgotten-history-of...

Doctor_Fegg 6y ago

Crystal's appeal, for me at least, is the productivity of Ruby with the memory efficiency and execution speed of C++. Static typing is just a way of achieving that, it's not something I'm seeking per se.

straight-shoota 6y ago
Remember static typing is also really useful for code quality and avoiding hidden bugs. Some code in Ruby requires a ton of specs to discover bugs caused by type issues, while the Crystal compiler tells you immediately that something doesn't work out. I love Crystal's type system really for productivity reasons.
- sjwright 6y ago
  I haven’t ever understood the argument against static typing. I’ve never declared a variable and not simultaneously thought “this is going to be a float, always a float, never not a float.” The only exception to this is untrusted input, but for that an string is usually always fine.
  - pansa2 6y ago
    > I’ve never declared a variable and not simultaneously thought “this is going to be a float, always a float, never not a float.” Never written generic/template code? Making that much easier is one of the main benefits of dynamic typing.
    - viraptor 6y ago
      Change it to "this variable is always going to be a T, never not a T" and it still stands.
    - sjwright 6y ago
      It's possible—nay likely—that I don't understand the true value of generics. It's something that I've looked into on occasion and it never seemed all that useful to me. Most examples I've come across in the past were C++ and seemed like formalised workarounds for deficiencies in the C++ type system rather than being actually useful. I'm sure I've failed to grok them—or based on the code I write I'm not the target audience for them. I have no problem when a language allows the programmer to explicitly opt for a variable to be an undefined/dynamic type, whether as part of generics or as part of a defensive ingest of untrusted data. I admit this is previously unspecified nuance but in my mind this doesn't break my rule: "this variable is always going to be a dynamic type, never not a dynamic type." This means you know when to interact with it defensively. The thing I'd like in a hybrid static-dynamic language is type assertion blocks which restore some benefits of static typing while dealing with dynamic typed variables. E.g.: declare x as dynamic; x = untrusted_source(); if (x IS_A string) { // Inside here, x behaves as a statically typed string. // The compiler knows it and checks types appropriately. // Passing x elsewhere will send a static typed string. function_that_demands_a_string(x); } else if (x CAN_SAFELY_BECOME_A uint) { // True for any non-negative integer regardless of data type. // Inside here, x is always a statically typed uint. // If it was some other type, it was converted for me. } (This probably already exists in some language somewhere but my familiarity with languages is narrow.)
      - ezrast 6y ago
        Crystal does some of what you want: https://tio.run/##ZVDBbsIwDL33KywmrRcaUXbbhHbeaYdpJ4RQaA1kCkllO6Ps57skBalshyQv7z3bT27owqLtMLS4h@CEAgu2W/aBGiwA1vEAzDSwkHGH2Tz/63p812VfzqG8pOun3IxkVS8Wqo5wo1ifOosFurYoGquZ4X33hY1EMc0TumzFb8PTMhcSSiAHjDZFsRjtCStC7rxrOXpf4XlSsMODcRndFau7ntwEvHqSmGEKNN45Wr1QYk7I0PpI97D6twk1iRotjWaEPoLzER185NXkxl0Qhl6FLjlu@uebk2ucUYfHCuolwEOMdwhWE1RA2nBM4B34b6S99eeXZDMMckQ4k@66OASixsa7W@s/u9kbYpkGuRFoGae83vFkAcPwCw https://tio.run/##ZVDBbsIwDL33KywmrRcaUXbbhHbeaYdpJ4RQaA1kCk... Note how the language is pretty smart about flow-typing variables as you narrow down their types. `x` here is typed as a tagged union (String | Int32 | Array(Char) | Float64 | UInt32), but by the time the program gets to the final `else` the compiler has figured out that the String and Array cases have already been dealt with (even though we never mentioned Array by name, just asked if the object implements a method that only Array implements), so it lets us call `x.abs`, which only works for numeric types. Of course, `abs` has different implementations for Int32 and Float64, but the signatures are compatible so the compiler lets it fly, resorting to dynamic dispatch at runtime. The missing part is that there's nothing like a CAN_SAFELY_BECOME_A operator so I had to implement that test myself (as `try_to_u32`) and call it early to get the flow typing to work. The Wikipedia article for the concept is https://en.wikipedia.org/wiki/Flow-sensitive_typing https://en.wikipedia.org/wiki/Flow-sensitive_typing
- ncmncm 6y ago
  If all you get from static typing is runtime performance and correctness, your type system is not pulling its weight. In any serious statically-typed language, the type system does real heavy lifting. In practice that means that libraries execute code at compile time that, in effect, generate the code you would otherwise need to write (again) yourself. C, Pascal, and Go are examples of statically typed languages whose type system does only trivial work.
onlyrealcuzzo 6y ago
Is static typing really necessary for speed? The fastest JavaScript engines and LuaJIT are closer in speed to Crystal than Crystal is to C. Granted - all these languages are really fast - and unless you're doing something INSANELY performance dependent and you REALLY know what you're doing - I think familiarity trumps all. You're almost certainly going to write faster Crystal code if you're a Crystal expert than you would write C, C++, or Rust.
- viraptor 6y ago
  It's not necessary strictly speaking, but it make things MUCH easier. JS in v8 has 3 (4?) layers of compilers already and each time some type changes at runtime you're taking a hit to go back to the interpreted version while functions jit compile again. There's a crazy amount of engineering effort that has to counteract a missing "this has one parameter and it's either a string or a float" annotation. In practice if you don't have a world class well funded team - yes, static typing is necessary for performance.
  - socialdemocrat 6y ago
    That is because JS was not built for JIT compilation. With a dynamic language like Julia built for JIT compilation from the very start you get both much simpler and cleaner design and higher performance. It uses a method JIT so it is deterministic and easy to analyze unlike JavaScript. You can lookup ahead of time how each function will get compiled with given input types.
    - viraptor 6y ago
      I'm not sure what you mean by this. Why do you think Julia was made for JIT from the beginning? You can't analyse functions like this ahead of time: function foo(x) x + y end You've got an Any type interacting with an Any global. There's no better answer than you'd get from JS analysis.
      - eigenspace 6y ago
socialdemocrat 6y ago
As an old Ruby fan, you should seriously check out Julia. It had a lot of the same meta programming goodies as Ruby but with performance that often rivals C/C++. Actually I think Julia will frequently pull off being faster. It is crazy how good JIT compilation works today with a language specifically designed designed for it.

yellowapple 6y ago

I mean, as someone who previously looked at Rust and is currently looking at Zig, Crystal is certainly on my radar. That said, my current dayjob is around a Rails codebase, so I might not be representative of the normal systems programming crowd.

straight-shoota 6y ago

Crystal comes from a Ruby background, but it's far more than compiled Ruby. As a general purpose language mainly aiming at application development it can surely compete with any of the above in that field. The main objective inherited from Ruby is the focus on developer hapiness. While doing that it doesn't back down on performance or interoparability.

nwmcsween 6y ago

Ruby is a great language, the only nits I have with it are error handling, types and a bit of the perlisms and shellisms that crept in. If Crystal fixed these I would be interested

cutler 6y ago
Ruby stole elegant word lists %w(tic tac toe) and the regex operator =~ from Perl so I'll keep my Perlisms, thank you very much.

tomc1985 6y ago

Ruby 3 does static typing, so that would be the quickest path for static types. Crystal is interesting to me because its a systems language, using Ruby syntax and idioms. I'm a Rails developer by trade but I've been pining to go back into desktop GUI development. Right now the only viable cross-platform options seem to be Swing and Electron. I'm not sure what the desktop story is with Crystal but if it there is a workable solution based on GTK or something similar I'd be very happy!

zem 6y ago
still no windows support :( desktop gui development was my main wish for crystal too, but ruling out a bunch of end users right out of the box was not an option.
- tomc1985 6y ago
  It looks like Windows support is preliminary. They are working on it...
  - atraac 6y ago
    https://github.com/crystal-lang/crystal/issues/5430 https://github.com/crystal-lang/crystal/issues/5430 this issue tracks Windows progress, it hasn't been really updated in a while. I've been following Crystal Windows port for over a year, nothing changed yet.
viraptor 6y ago
Ruby 3 has static typing, but it's opt-in and doesn't affect the runtime. Here it's both enforced and directly translates to better performance.
iomcr 6y ago
> Ruby 3 does static typing Categorically, what I've seen of this falls closer to "lintable comments" than it does "actual static types". Static types are a foundational aspect of crystal, it's not like a sticker slapped on as an after thought.

ljm 6y ago

I'd consider it more seriously now it's 1.0. You've basically got an ecosystem of Ruby-likes: - Ruby itself - Crystal - Elixir I'm massively keen on Zig, too, but it still feels like early days for the language itself. The C-interop is utterly astounding but I don't want to write Zig as syntax-sugar around C libraries.

ksec 6y ago
And Julia as well.
- forgotpwd16 6y ago
  Julia if anything is unlike Ruby. The very first Ruby example on the official site showcases its object-oriented nature. Julia instead of objects has multiple dispatch.
  - cbkeller 6y ago
    On one hand you're absolutely correct in that Julia is dispatch-oriented, and doesn't have ton in common with what is commonly considered OOP today. However, as far as I understand it there is also an argument to be made that multiple dispatch is at least as close to Alan Kay’s original intent for OO (e.g. [1]) than is the currently-ubiquitous class-based version of OO that leads to things like `RequestProcessorFactoryFactory` s with `RequestProcessorFactoryFactory.getRequestProcessorFactory(Class)` methods. [1] https://medium.com/javascript-scene/the-forgotten-history-of-oop-88d71b9b2d9f https://medium.com/javascript-scene/the-forgotten-history-of...