Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Crystal Programming Language

crystal-lang.org

Post reply on HN
Print view View original

21–30 of 180 posts

Re: The Crystal Programming Language

#21

Post by kibwen »

logicchains wrote: post #14
asterite wrote: post #11

Earlier quoted context omitted.

Yes, you can browse the source code if you want, check it out and compile the compiler. It has between 30k and 60k lines of code (because you have to consider it also includes the standard library) and on a Macbook Pro 2015 it takes less than 10 seconds to compile (in non-release mode). We'll have to wait until we get project that's larger than the compiler, but we believe there's still room for performance improveme…

It seems to have a fair slew of type-system features, so how does it manage to compile so fast, compared to for instance the Rust compiler, which doesn't do global type inference?

The current slowness of the Rust compiler is largely due to putting more developer attention into improving the runtime speed of fully-optimized binaries. Hence, regardless of which mode it's in, the compiler does a lot of unnecessary work that a debug-mode binary doesn't need or benefit from. There's also simply a ton of low-hanging fruit lying around: we're only two weeks out from 1.0 and the nightly compiler is already reportedly 30% faster for code compiling in the wild. There's another 10% compilation speed reduction coming from work around optimizing linking. There's also work towards parallel codegen coming along nicely (https://github.com/rust-lang/rust/pull/26018) which reports a 30% reduction in compilation time. In the longer run there are plans for incremental compilation which should drastically reduce the amount of work that gets unnecessarily repeated with each compilation cycle (https://github.com/rust-lang/rfcs/pull/594). In the even longer run there are plans to fully parallelize the compiler phases and also to pre-optimize code before it gets to LLVM in order to reduce the sheer quantity of IR that we shovel into it.

TL;DR: Crystal manages much faster compilation than Rust because Rust's compiler developers may have deprioritized optimizing the compiler for a bit too long. :)

Re: The Crystal Programming Language

#23

Post by oconnor0 »

rifung wrote: post #17
MCRed wrote: post #15

I love that we're getting new languages lately, but almost all of them seem to be ignore the significant new requirement of our age: parallelism & concurrency. Specifically, you need lightweight processes and no-shared-memroy architecture. While the number of cores on a machine is remaining relatively low, the number of machines in a system are going up. Erlang got this right and build a lot of infrastructure around…

I largely agree with what you are saying, but doesn't it only apply to languages that will be used in back end systems? If you are just making a phone app or something, it doesn't seem like parallelism is nearly as important.

Phones are getting more and more cores. It won't be long before languages for mobile need to solve the same issues - parallelism and concurrency.

Re: The Crystal Programming Language

#24

Post by asterite »

zeeone wrote: post #16

Just curious, why Crystal? It looks just like Ruby. What problem(s) are you addressing with Crystal?

We like the way Ruby lets you quickly prototype things, but its performance isn't very good (it's just good) and it also lacks static type checks (for example "undefined method '...' for Nil" is a very common runtime error).

So, we are trying to create a language with all the nice aspects of Ruby but with static checks and better performance. Of course that comes at a price: no dynamic aspects (no eval, no instance_eval, no methods or classes created at runtime, no methods redefined at runtime, etc.). But we try to compensate those with macros and compile-time reflection.

One thing that is definitely not one of our goals is to replace Ruby: every tool has its place.

Re: The Crystal Programming Language

#25

Post by [deleted] »

MCRed wrote: post #15

I love that we're getting new languages lately, but almost all of them seem to be ignore the significant new requirement of our age: parallelism & concurrency. Specifically, you need lightweight processes and no-shared-memroy architecture. While the number of cores on a machine is remaining relatively low, the number of machines in a system are going up. Erlang got this right and build a lot of infrastructure around…

[deleted]

Re: The Crystal Programming Language

#27

Post by asterite »

logicchains wrote: post #14
asterite wrote: post #11

Earlier quoted context omitted.

Yes, you can browse the source code if you want, check it out and compile the compiler. It has between 30k and 60k lines of code (because you have to consider it also includes the standard library) and on a Macbook Pro 2015 it takes less than 10 seconds to compile (in non-release mode). We'll have to wait until we get project that's larger than the compiler, but we believe there's still room for performance improveme…

It seems to have a fair slew of type-system features, so how does it manage to compile so fast, compared to for instance the Rust compiler, which doesn't do global type inference?

It's because we spent some time thinking the algorithms and optimizing them, and whenever we make changes to the compiler we make sure the times remain pretty much the same (it's hard because the compiler's size grows so the times inevitably grow, at least for the compiler). And from time to time we profile and optimize further, we like speed.

I believe with time Rust can achieve a similar performance, maybe even better because they will be able to do incremental compilation (maybe, I'm not sure how will they do that with parameterized types).

There's also the thing that most of the things in Crystal are lazy: if you don't invoke a method there are no type checks to be done for it. This means that you only pay for what you use (in terms of compile speed) but also what you don't use doesn't end up being in the resulting executable.

Re: The Crystal Programming Language

#28

Post by tel »

seanmcdirmid wrote: post #18
asterite wrote: post #5

Earlier quoted context omitted.

It has global type inference, there's nothing dynamic in the language. You can specify type restrictions to allow overloading methods, for example, or doing multiple dispatch. But in the general case you don't specify types (except for generic type arguments) and the compiler figures out everything.

What algorithm are you using? How do you deal with subtyping and paramatricity?

They have a couple posts on their inference algorithm, but I confess I haven't read them.

Re: The Crystal Programming Language

#29

Post by asterite »

seanmcdirmid wrote: post #18
asterite wrote: post #5

Earlier quoted context omitted.

It has global type inference, there's nothing dynamic in the language. You can specify type restrictions to allow overloading methods, for example, or doing multiple dispatch. But in the general case you don't specify types (except for generic type arguments) and the compiler figures out everything.

What algorithm are you using? How do you deal with subtyping and paramatricity?

The algorithm isn't very easy to explain in a few words. We don't use any well-known algorithm. It has some bits of the cartesian-product algorithm, but just tiny bits.

There's some info here:

http://crystal-lang.org/2013/09/23/type-inference-part-1.htm... http://crystal-lang.org/2014/04/27/type-inference-rules.html

About subtyping and paramtricity, I'm not sure what's that, but the compiler just keeps track of all the types and forms unions, except in one case which is this one (a union of references with a base type): http://crystal-lang.org/docs/syntax_and_semantics/virtual_an...

Re: The Crystal Programming Language

#30

Post by asterite »

raindev wrote: post #26
rtpg wrote: post #13

http://crystal-lang.org/2013/07/13/null-pointer-exception.ht... The Null pointer analysis is great, hope this stuff pollinates some of the more mainstream languages

I don't see a reasons for null to exist in a new language in 2015.

How do you model a "zero or one" relationship without null?

Maybe your answer is "with Optional" (or Option, or Maybe). We just choose to use union types and have "Nil | T" (Nil or T) be the same as "Option(T)" in other languages.

Post reply on HN