3 ms·

Another thing though: If at least one of your constraints are speed, a dynamically language probably shouldn’t be your first choice. If you need to maintain me

Another thing though: If at least one of your constraints are speed, a dynamically language probably shouldn’t be your first choice. If you need to maintain memory safety, Java or Rust would be more applicable. That being said, once you have a codebase written in a certain language, you might just be stuck there due to hired talent being familiar with it. I don’t think I’ve really seen a company pull off a polygot move cheaply. Instead, a parallel move to something like Crystal may require minimal re-training. … just thoughts I would have if I were in charge of investing R&D time at a large org like the ones mentioned in the article.

eropple 4y ago
Crystal is only superficially similar to Ruby and doesn't seem to get you very far if you're a Ruby shop. It's not a bad language, but it is different, and there's probably more value to be had not trying to adhere to some similar-ish syntax and adopting something more mainstream.
- petepete 4y ago
  I agree, I think the fact that the standard libraries are really similar is a huge help for people transferring.
pizza234 4y ago
Rust is overkill for projects that don't need very high scale, also because of the paradigm shift of the frameworks. Golang is a more conventional choice, for the opposite reason. Crystal is not ready for large scale deployment, which includes the fact that is not well supported as more widespread languages (e.g. on AWS).
- lgreiv 4y ago
  I agree insofar as that there is no dedicated runtime for crystal in AWS Lambda, but it can well be used there or in fargate containers. I wrote a (proof of concept) minimal runtime for Lambda some time ago [1] and had pretty decent results. Given that both fly.io and Heroku have working buildpacks for Crystal/Lucky, I’d say you can serve pretty heavy load before you’d need to reach for more specialized machines. Of course, that depends on the nature of your application as well. Maybe my understanding of 'large scale' is different from yours, though. [1] https://github.com/lagr/aws_lambda_runtime https://github.com/lagr/aws_lambda_runtime
  - pizza234 4y ago
    > I’d say you can serve pretty heavy load before you’d need to reach for more specialized machines At large scale, I expect a programming language to support multithreading, in order to avoid the resource occupation of multiple processes. When one runs dozens of serving instances on a server, threads and processes make a significant difference in terms of memory requirements. The experimental (therefore, not production-grade) support for parallelism has very poor performance, see their benchmark of the web server: https://crystal-lang.org/2019/09/06/parallelism-in-crystal.html https://crystal-lang.org/2019/09/06/parallelism-in-crystal.h....
_wldu 4y ago
I would also recommend Go for web developers who want both speed and memory safety. It works well and is hard to beat, but I haven't seen any Go web framework that comes close to Ruby on Rails. If anything like that ever does come along, I think it will be very popular. I like Ruby a lot. I'm not knocking it. It's probably the most enjoyable language I've ever used.

eropple 4y ago

Crystal is only superficially similar to Ruby and doesn't seem to get you very far if you're a Ruby shop. It's not a bad language, but it is different, and there's probably more value to be had not trying to adhere to some similar-ish syntax and adopting something more mainstream.

petepete 4y ago
I agree, I think the fact that the standard libraries are really similar is a huge help for people transferring.

pizza234 4y ago

Rust is overkill for projects that don't need very high scale, also because of the paradigm shift of the frameworks. Golang is a more conventional choice, for the opposite reason. Crystal is not ready for large scale deployment, which includes the fact that is not well supported as more widespread languages (e.g. on AWS).

lgreiv 4y ago
I agree insofar as that there is no dedicated runtime for crystal in AWS Lambda, but it can well be used there or in fargate containers. I wrote a (proof of concept) minimal runtime for Lambda some time ago [1] and had pretty decent results. Given that both fly.io and Heroku have working buildpacks for Crystal/Lucky, I’d say you can serve pretty heavy load before you’d need to reach for more specialized machines. Of course, that depends on the nature of your application as well. Maybe my understanding of 'large scale' is different from yours, though. [1] https://github.com/lagr/aws_lambda_runtime https://github.com/lagr/aws_lambda_runtime
- pizza234 4y ago
  > I’d say you can serve pretty heavy load before you’d need to reach for more specialized machines At large scale, I expect a programming language to support multithreading, in order to avoid the resource occupation of multiple processes. When one runs dozens of serving instances on a server, threads and processes make a significant difference in terms of memory requirements. The experimental (therefore, not production-grade) support for parallelism has very poor performance, see their benchmark of the web server: https://crystal-lang.org/2019/09/06/parallelism-in-crystal.html https://crystal-lang.org/2019/09/06/parallelism-in-crystal.h....

_wldu 4y ago

I would also recommend Go for web developers who want both speed and memory safety. It works well and is hard to beat, but I haven't seen any Go web framework that comes close to Ruby on Rails. If anything like that ever does come along, I think it will be very popular. I like Ruby a lot. I'm not knocking it. It's probably the most enjoyable language I've ever used.