5 ms·

They "why" is basically having a language with the aesthetics and usability of Ruby, but fully statically typed with global type inference, and impressive perfo

They "why" is basically having a language with the aesthetics and usability of Ruby, but fully statically typed with global type inference, and impressive performance. The downside being a relatively slow compiler. It's the necessary trade-off for the type inference.

elviejo 6y ago
thank you! this summary is enough for me to try it!
deleted 6y ago
[deleted]
Thaxll 6y ago
The "downside" you forgot to mention a lot of important things: - tooling is abyssmal ( IDE etc ... ) - no mutli threading - no real support, I'm not even sure if there is one paid guy anymnore on the project - it's still immature - they break the API all the time
- haolez 6y ago
  Besides funding (and maybe multithreading), I'd say that every new language will suffer from these limitations. They are difficult to avoid.
- ibraheemdev 6y ago
  It is a relatively new language, all of the points you listed are expected. The last one should be taken care of now that they released 1.0.
- gravypod 6y ago
  > - tooling is abyssmal ( IDE etc ... ) As others have mentioned this is a side effect of how young it is. > - no real support, I'm not even sure if there is one paid guy anymnore on the project If paid support is all that counts then most languages would fall into that. > - it's still immature Tautological. Nothing can become mature without first being immature. > - they break the API all the time Isn't that what a 1.x is for? A stable major version?
  - offtop5 6y ago
    >If paid support is all that counts then most languages would fall into that. Can you name another recent programming language that wasn't developed in-house at a major company. Go , Dart , and Rust all started out with paid teams of programmers working on them. Not sure if Crystal will be able to progress at a rate fast enough to keep people interested. Likewise, you'd have to be insane to try and pitch this to your project manager. I consider myself to be a risk taker, but even for my own side projects I stick to older better known programming languages. it feels like we keep trying to solve the same problems over and over again instead of utilizing solutions which already exist
    - chillfox 6y ago
      I feel like it would be easier and cheaper to negotiate a support contract with Manas (Crystal) than with Google (Go, Dart) if your company wants paid support.
    - gravypod 6y ago
      Do zig, python, elisp, Clojure, Haskell (mostly a research project), etc fit the bill?
      - offtop5 6y ago
        Out of those Pythons the only one that's widely used in production, and it's been around for a long time. Python itself is an extremely simple language, which I think can work as one person passion project. Modern python has grown significantly from its first release in the 90s though. I don't think that can happen today, we all want too much out of our programming languages.
        lgessler 6y ago
        I can't speak to the others on the list but it seems odd to say Clojure isn't being used widely in production. Clojure's been powering big businesses for years now and Nubank, which primarily uses Clojure, is valued at $24bn: https://www.pymnts.com/news/investment-tracker/2021/brazilian-fintech-nubank-raises-400-million-in-series-g/#:~:text=Nubank's%20total%20funding%20to%20date,billion%20in%202019%2C%20TechCrunch%20reported https://www.pymnts.com/news/investment-tracker/2021/brazilia....
- Trasmatta 6y ago
  Those downsides aren't intrinsic to the design of the language, and are likely to be present for any new, immature language. The compile times are largely a side effect of the underlying language design, and it isn't likely to get significantly better, which is why I mentioned it.
- straight-shoota 6y ago
  Crystal is sponsored by https://manas.tech/ https://manas.tech/ and the company actively provides paid support to a number of commercial clients. Breaking changes have been really low lately. I have a couple of shards that work on 1.0 as well as they did on 0.27 or so (that's 10 major dev releases ago). And with 1.0 there is a guarantee to not have breaking changes until 2.0. I don't agree to the other points too, but that's more subjective.
- caspianbaska 6y ago
  Multithreading has been present behind a compiler flag for a solid 7 minor versions (since 2019). The feature is maturing for a release in the 1.0 -> 2.0 range.
- postmodern_mod3 6y ago
  - tooling: there is a VS Code plugin for Crystal (https://marketplace.visualstudio.com/items?itemName=crystal-lang-tools.crystal-lang https://marketplace.visualstudio.com/items?itemName=crystal-...). There is also syntax highlighting for most popular editors, if you prefer a text-editor to a fully-loaded IDE. - no multi threading: Crystal has lightweight green threads for lightweight concurrency. However, Crystal does have experimental native multi-threading guarded by a compiler flag. The ultimate goal is to have multiple native threads each running multiple green threads for maximum concurrency. Currently, with just green threads, Crystal is competitive with Go or Rust wrt throughput. You can checkout benchmarks on crystal-lang.org or search Google for "Go vs Crystal benchmark" blog posts. - no real support: Manas Tech is the corporate sponsor for Crystal (https://manas.tech/projects/crystal/ https://manas.tech/projects/crystal/) and employs many of the core developers; the project also accepts donations on Open Collective. There is a crystal-lang IRC channel, Gitter, Discord, Discourse forum, sub-reddit, and even a "Matrix" channel where developers frequently ask and answer questions. - still immature: a 1.0.0 version is a significant milestone for any project. Companies are already running Crystal in production, which was discussed during the Raw Crystal 2020 virtual-conference (videos on YouTube). - API breakage: Crystal 1.0.0 was released to stabilize the API (SemVer)
dkarras 6y ago
See, when you add "performance" to those properties it piques my interest. I'd love me a high performance language that is sanely typed, allows for metaprogramming, feels like an interpreted language while doing so etc. However the main page says absolutely nothing about performance. I even don't care about compile times. So what is the performance like?
- Trasmatta 6y ago
  You can find some benchmarks here: https://github.com/kostya/benchmarks https://github.com/kostya/benchmarks With the caveat of course being that benchmarks don't always reflect real world performance.
  - _joel 6y ago
    Also Crystal based web frameworks tested here (key: Cry) same caveat as above. https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/
- weatherlight 6y ago
  It's at least on par with Go, for solving similar problems, micro benchmarks, etc.
Zababa 6y ago
> The downside being a relatively slow compiler. It's the necessary trade-off for the type inference. I'm curious about that, MLs usually have fast compilers (OCaml for example) and have type inference. I thought that the slow compilation times were due to LLVM .
- Trasmatta 6y ago
  Crystal's type inference is more powerful than most other languages. Maybe the most powerful of any fully statically typed language? (I would love to hear of any others that have taken the same approach as Crystal.) You can almost write Crystal like a dynamically typed language, and yet everything is still fully statically typed. I believe you can speed up your compile times a bit by being explicit with annotations (which I often prefer anyway), but there's still a lot of overhead for the global type inference.
  - fishmaster 6y ago
    > Maybe the most powerful of any fully statically typed language? Compared to Haskell, Ocaml, Scala, F#, ...? Writing it like a dynamically typed language is standard for full type inference.
    - asterite 6y ago
      Those functional languages don't have function overloading or named arguments. The type inference in Crystal works very differently. The type of a method can only be computed from explicit calls to it. In those functional languages the type can be computed independent of a call because it's trivial to do so if a function name always refers to a single entity.
      - Zababa 6y ago
        > Those functional languages don't have function overloading or named arguments. Scala has both, F# too (though function overloading is possible, I think it's not idiomatic), OCaml has named arguments, Haskell has overloading.

elviejo 6y ago

thank you! this summary is enough for me to try it!

deleted 6y ago

[deleted]

Thaxll 6y ago

The "downside" you forgot to mention a lot of important things: - tooling is abyssmal ( IDE etc ... ) - no mutli threading - no real support, I'm not even sure if there is one paid guy anymnore on the project - it's still immature - they break the API all the time

haolez 6y ago
Besides funding (and maybe multithreading), I'd say that every new language will suffer from these limitations. They are difficult to avoid.
ibraheemdev 6y ago
It is a relatively new language, all of the points you listed are expected. The last one should be taken care of now that they released 1.0.
gravypod 6y ago
> - tooling is abyssmal ( IDE etc ... ) As others have mentioned this is a side effect of how young it is. > - no real support, I'm not even sure if there is one paid guy anymnore on the project If paid support is all that counts then most languages would fall into that. > - it's still immature Tautological. Nothing can become mature without first being immature. > - they break the API all the time Isn't that what a 1.x is for? A stable major version?
- offtop5 6y ago
  >If paid support is all that counts then most languages would fall into that. Can you name another recent programming language that wasn't developed in-house at a major company. Go , Dart , and Rust all started out with paid teams of programmers working on them. Not sure if Crystal will be able to progress at a rate fast enough to keep people interested. Likewise, you'd have to be insane to try and pitch this to your project manager. I consider myself to be a risk taker, but even for my own side projects I stick to older better known programming languages. it feels like we keep trying to solve the same problems over and over again instead of utilizing solutions which already exist
  - chillfox 6y ago
    I feel like it would be easier and cheaper to negotiate a support contract with Manas (Crystal) than with Google (Go, Dart) if your company wants paid support.
  - gravypod 6y ago
    Do zig, python, elisp, Clojure, Haskell (mostly a research project), etc fit the bill?
    - offtop5 6y ago
      Out of those Pythons the only one that's widely used in production, and it's been around for a long time. Python itself is an extremely simple language, which I think can work as one person passion project. Modern python has grown significantly from its first release in the 90s though. I don't think that can happen today, we all want too much out of our programming languages.
      - lgessler 6y ago
        I can't speak to the others on the list but it seems odd to say Clojure isn't being used widely in production. Clojure's been powering big businesses for years now and Nubank, which primarily uses Clojure, is valued at $24bn: https://www.pymnts.com/news/investment-tracker/2021/brazilian-fintech-nubank-raises-400-million-in-series-g/#:~:text=Nubank's%20total%20funding%20to%20date,billion%20in%202019%2C%20TechCrunch%20reported https://www.pymnts.com/news/investment-tracker/2021/brazilia....
Trasmatta 6y ago
Those downsides aren't intrinsic to the design of the language, and are likely to be present for any new, immature language. The compile times are largely a side effect of the underlying language design, and it isn't likely to get significantly better, which is why I mentioned it.
straight-shoota 6y ago
Crystal is sponsored by https://manas.tech/ https://manas.tech/ and the company actively provides paid support to a number of commercial clients. Breaking changes have been really low lately. I have a couple of shards that work on 1.0 as well as they did on 0.27 or so (that's 10 major dev releases ago). And with 1.0 there is a guarantee to not have breaking changes until 2.0. I don't agree to the other points too, but that's more subjective.
caspianbaska 6y ago
Multithreading has been present behind a compiler flag for a solid 7 minor versions (since 2019). The feature is maturing for a release in the 1.0 -> 2.0 range.
postmodern_mod3 6y ago
- tooling: there is a VS Code plugin for Crystal (https://marketplace.visualstudio.com/items?itemName=crystal-lang-tools.crystal-lang https://marketplace.visualstudio.com/items?itemName=crystal-...). There is also syntax highlighting for most popular editors, if you prefer a text-editor to a fully-loaded IDE. - no multi threading: Crystal has lightweight green threads for lightweight concurrency. However, Crystal does have experimental native multi-threading guarded by a compiler flag. The ultimate goal is to have multiple native threads each running multiple green threads for maximum concurrency. Currently, with just green threads, Crystal is competitive with Go or Rust wrt throughput. You can checkout benchmarks on crystal-lang.org or search Google for "Go vs Crystal benchmark" blog posts. - no real support: Manas Tech is the corporate sponsor for Crystal (https://manas.tech/projects/crystal/ https://manas.tech/projects/crystal/) and employs many of the core developers; the project also accepts donations on Open Collective. There is a crystal-lang IRC channel, Gitter, Discord, Discourse forum, sub-reddit, and even a "Matrix" channel where developers frequently ask and answer questions. - still immature: a 1.0.0 version is a significant milestone for any project. Companies are already running Crystal in production, which was discussed during the Raw Crystal 2020 virtual-conference (videos on YouTube). - API breakage: Crystal 1.0.0 was released to stabilize the API (SemVer)

dkarras 6y ago

See, when you add "performance" to those properties it piques my interest. I'd love me a high performance language that is sanely typed, allows for metaprogramming, feels like an interpreted language while doing so etc. However the main page says absolutely nothing about performance. I even don't care about compile times. So what is the performance like?

Trasmatta 6y ago
You can find some benchmarks here: https://github.com/kostya/benchmarks https://github.com/kostya/benchmarks With the caveat of course being that benchmarks don't always reflect real world performance.
- _joel 6y ago
  Also Crystal based web frameworks tested here (key: Cry) same caveat as above. https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/
weatherlight 6y ago
It's at least on par with Go, for solving similar problems, micro benchmarks, etc.

Zababa 6y ago

> The downside being a relatively slow compiler. It's the necessary trade-off for the type inference. I'm curious about that, MLs usually have fast compilers (OCaml for example) and have type inference. I thought that the slow compilation times were due to LLVM .

Trasmatta 6y ago
Crystal's type inference is more powerful than most other languages. Maybe the most powerful of any fully statically typed language? (I would love to hear of any others that have taken the same approach as Crystal.) You can almost write Crystal like a dynamically typed language, and yet everything is still fully statically typed. I believe you can speed up your compile times a bit by being explicit with annotations (which I often prefer anyway), but there's still a lot of overhead for the global type inference.
- fishmaster 6y ago
  > Maybe the most powerful of any fully statically typed language? Compared to Haskell, Ocaml, Scala, F#, ...? Writing it like a dynamically typed language is standard for full type inference.
  - asterite 6y ago
    Those functional languages don't have function overloading or named arguments. The type inference in Crystal works very differently. The type of a method can only be computed from explicit calls to it. In those functional languages the type can be computed independent of a call because it's trivial to do so if a function name always refers to a single entity.
    - Zababa 6y ago
      > Those functional languages don't have function overloading or named arguments. Scala has both, F# too (though function overloading is possible, I think it's not idiomatic), OCaml has named arguments, Haskell has overloading.