Comment by npn | Hacker News Reader

Comment by npn | Hacker News Reader

Parent Full thread

no, I meant when your script crashes because some careless typo in the middle of the file, then you will value a compiled language. and even when there is no typo, your program can still crash due to the huge memory consumption.

also, using crystal you have parallel and concurrency to speed up your task. sure it is not as good as other matured languages, but it still does the job.

when doing with large amount of data, and with IO involved, you will see that your JIT or AOT engine for ruby still can not cut it, because in ruby there is so many layers of safety check and failure guard it is really hard to make it faster (number calculation is not everything). with crystal you can manipulate the io stream directly, avoiding a lot of intermediate steps. you can check yourself, they make a full page for it: https://crystal-lang.org/reference/1.22/guides/performance.h...

personally I do not use a single language, I just pick the most suitable language for the job I'm doing, let it be ruby, python, crystal, rust, go or typescript. but surprisingly crystal is the one I use the most everyday.

> when your script crashes because some careless typo in the middle of the file, then you will value a compiled language

How about the crashes for all the other more common reasons? It seems like a concern unrelated to whether a language is strictly AOT-compiled or not, and whether such compilation runs through a static type checker or not, and in any case surely differs a lot among programmers' experience. (Crashes from typos basically rarely if ever happened to me in Python, same with memory constraint crashes. But I've never tried running Python on anything with less than 1 GB/core, if you don't count possibly some educational usage on ancient 90s hardware or a 2004 laptop; the lowest power device was probably a Cubietruck3 from 2013 that still had a generous dual-core ARM cortex-a7 and 2 gigs.)

But I agree with the sentiment, I hate it when programs crash and take out their work in progress or other state. I wish more languages adopted the Common Lisp condition system model, where errors don't crash or unwind anything by default and you can dynamically fix things and retry, or resume, or restart from a specific stack frame. There's even a book about implementing it: https://www.amazon.com/dp/B0DF5YVJKJ (And despite being dynamically typed, Common Lisp is compiled to native machine code, and some implementations like SBCL offer some bare-bones static checks to flag trivial typo or type mismatch issues during compilation, before running the code in question... You can also bolt on a full static type system language on top as a library if you want.)

> no, I meant when your script crashes because some careless typo in the middle of the file, then you will value a compiled language. and even when there is no typo, your program can still crash due to the huge memory consumption.

If your code is poorly enough tested for a typo to cause it to crash, a typo is the least of your concerns.

> also, using crystal you have parallel and concurrency to speed up your task. sure it is not as good as other matured languages, but it still does the job.

So you do in several Ruby implementations.

> when doing with large amount of data, and with IO involved, you will see that your JIT or AOT engine for ruby still can not cut it

I've used Ruby for large scale IO with Ruby for 20 years without problems, even on CPU's far slower, and with Ruby versions far slower than today. If you're doing IO with Ruby and the performance of your language implementation is what is limiting you, rather than spending most of the time in kernel space waiting for system calls to complete, you're doing something wrong.

Reply on news.ycombinator.com