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

31–40 of 180 posts

Re: The Crystal Programming Language

#31

Post by ezdiy »

trengrj wrote: post #12

I've been looking at the benchmarks https://github.com/kostya/benchmarks and am pleasantly surprised about the speed. It definitely smokes Ruby, but also is usually faster than Go. I know that all benchmarks are relative but Crystal seems a great language from a performance viewpoint.

Indeed it's becoming quite promising (using crystal already for few pet scripts which were too slow even for rubinius). Where it's most lacking at the moment is gc - it uses stop-world off the shelf boehmgc which is ok but not exactly great for memory heavy tasks.

Re: The Crystal Programming Language

#32

Post by kibwen »

reagency wrote: post #19
kibwen wrote: post #10

Earlier quoted context omitted.

I'm curious how possible it is in practice to write large software that relies exclusively on global type inference. Does the compiler itself go without ever explicitly specifying a type?

GHC does global type inference, and has very sophisticated types.

My point was specifically in regard to the feasibility of omitting the types in all cases. I see types often in Haskell code, likely because the community regards that as a best practice (in contrast to Crystal).

Re: The Crystal Programming Language

#33

Post by asterite »

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…

You are right, it wouldn't be wise to create a new language without having concurrency in mind.

Starting from the last version there's spawn (lightweight processes) and channels for communications, similar to Go (although it's in a very experimental stage right now). We aren't sure immutability everywhere is the solution for everything, some algorithms and programs are much more efficient with mutable data.

I think Go is quite popular and have an amazing concurrency support. It's true, you have to make sure to communicate using channels and not via shared memory, but if you follow that rule than you won't have problems, and you can get pretty efficient programs.

Re: The Crystal Programming Language

#34

Post by seanmcdirmid »

asterite wrote: post #29
seanmcdirmid wrote: post #18

Earlier quoted context omitted.

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 t…

If you are using Agesen-style CPA, then it is more of a global analysis (type recovery) then type inference. I would be a bit worried about scaling, but if you've put 50kloc through it, maybe you've figured it out? I'm working on my own type-less type inference system that I'll share more about soon.

Re: The Crystal Programming Language

#35

Post by raindev »

asterite wrote: post #30
raindev wrote: post #26

Earlier quoted context omitted.

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.

Yes, Maybe (Optional) is the way to go. The difference is, with nil you basically make every type optional allowing it to have nil as a value.

Re: The Crystal Programming Language

#36

Post by dmgbrn »

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 have to disagree with you on this.

A language should be expressive enough that it can easily support correct concurrent programming, and readily expose runtimes (OTP is a great example) that have support for concurrency and distributed programming.

However, patterns like message passing instead of shared memory are not a panacea. Deadlocks and non-deterministic behavior can still happen in such systems if programmers do something stupid.

Enforcing these patterns at the language level smells of the old "let's make a language that doesn't allow programmers to write bugs!" trap.

Re: The Crystal Programming Language

#37

Post by asterite »

raindev wrote: post #35
asterite wrote: post #30

Earlier quoted context omitted.

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.

Yes, Maybe (Optional) is the way to go. The difference is, with nil you basically make every type optional allowing it to have nil as a value.

Well, in Crystal Nil is a separate type that can be combined with others. But, say, a String is always a String, it doesn't implicitly have the Nil type. Same goes with every other type.

Maybe you are thinking of Java/C#, where reference types can also be null, but this is not true in Crystal. It's also in a way similar (but not quite) to Swift, where optional types are different than types that can't be null.

Re: The Crystal Programming Language

#38

Post by raindev »

raindev wrote: post #35
asterite wrote: post #30

Earlier quoted context omitted.

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.

Yes, Maybe (Optional) is the way to go. The difference is, with nil you basically make every type optional allowing it to have nil as a value.

I find the distinction important as it allows to establish a contract without falling into defensive programming. Null pointer analysis is great, I admit, but how it would help to write a library function without checking explicitly if its parameter is nil?

Re: The Crystal Programming Language

#39

Post by tel »

asterite wrote: post #30
raindev wrote: post #26

Earlier quoted context omitted.

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.

And to be honest, (T | Nil) is pretty difficult to distinguish from (Maybe a = a + 1). Complaints feel difficult to motivate to me anyway.

Re: The Crystal Programming Language

#40

Post by tel »

kibwen wrote: post #32
reagency wrote: post #19

Earlier quoted context omitted.

GHC does global type inference, and has very sophisticated types.

My point was specifically in regard to the feasibility of omitting the types in all cases. I see types often in Haskell code, likely because the community regards that as a best practice (in contrast to Crystal).

Best practice and it's required to make certain more advanced type features work.

It's the same with Crystal. Their generics require type annotations.

Post reply on HN