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

61–70 of 180 posts

Re: The Crystal Programming Language

#61

Post by bjeanes »

tel wrote: post #39
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.

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

They both accomplish the same thing: no unexpected null. The exact mechanism was never the interesting part. Maybe being monadic does offer some other benefits but the killer advantage is the responsible handling of nil. Crystal doesn't seem to have a foundation in monadic programming so the type unions seem like a reasonable approach there.

Re: The Crystal Programming Language

#62

Post by bjeanes »

kibwen wrote: post #21
logicchains wrote: post #14

Earlier quoted context omitted.

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

Thanks for linking to those RFCs. The planned or in-progress work for Rust compilation speed is very exciting. I can't wait to reap the benefits!

Re: The Crystal Programming Language

#63

Post by anonyfox »

sergiotapia wrote: post #46

I'm looking for something beautiful like Ruby but fast like Go. Do you think Crystal fits this bill? Also, are there packages/libs/gems for Crystal? What are they called? What do I google for? One of the major reasons why I dumped Go is that it's just too verbose and makes me write too much boilerplate code. I want to sort a collection and I have to write the same algorithm every single time for every single type. It…

http://elixir-lang.org may be even faster than go. web apps respond in microseconds.

Re: The Crystal Programming Language

#64

Post by anonyfox »

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…

http://elixir-lang.org - ruby-like syntax on the erlang VM, -> massivly scalable, really fast and fault tolerant.

Re: The Crystal Programming Language

#65

Post by lmm »

bjeanes wrote: post #61
tel wrote: post #39

Earlier quoted context omitted.

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

They both accomplish the same thing: no unexpected null. The exact mechanism was never the interesting part. Maybe being monadic does offer some other benefits but the killer advantage is the responsible handling of nil. Crystal doesn't seem to have a foundation in monadic programming so the type unions seem like a reasonable approach there.

The advantage of the monadic approach is that it's easy to abstract over, because it's just an ordinary type in the language. So e.g. in scala I can call the same "sequence" method on a List[Option[Int]] as I do on a List[Future[Int]] or a List[ErrorMessage \/ Int]].

Unions seem like more of a language-level feature, so I'm not sure you could abstract over them in the same way.

Re: The Crystal Programming Language

#66

Post by espadrine »

singularity2001 wrote: post #53
sir_akshay wrote: post #51

Earlier quoted context omitted.

You missed compilation?

He probably meant the results of compilation: superfast binaries ;)

In that case, what he missed was AOT optimization :)

Many Lisps have had compilation to binaries. But having a binary doesn't imply being faster than an interpreted language.

Theoretically, a JIT optimization can end up with faster code than an AOT optimizer can produce, thanks to runtime profiling.

In fact, I'd be interested in seeing benchmarks, which Crystal is probably not ready to share, but may have conducted: https://github.com/manastech/crystal/blob/master/samples/fan...

Edit: this[0] seems to indicate that the optimizations are in the same ballpark as Go and D, which is really impressive.

[0]: https://github.com/kostya/benchmarks

Re: The Crystal Programming Language

#67

Post by jacquesm »

anonyfox wrote: post #63
sergiotapia wrote: post #46

I'm looking for something beautiful like Ruby but fast like Go. Do you think Crystal fits this bill? Also, are there packages/libs/gems for Crystal? What are they called? What do I google for? One of the major reasons why I dumped Go is that it's just too verbose and makes me write too much boilerplate code. I want to sort a collection and I have to write the same algorithm every single time for every single type. It…

http://elixir-lang.org may be even faster than go. web apps respond in microseconds.

Elixer and Erlang are not faster than go.

The ability to respond in microseconds is a latency issue, not a raw speed issue. Erlang and Elixer can do that because of the way the core systems are architected but the underlying VM and language constructs are quite a bit slower than anything that Go has to offer.

For maximum throughput out of a given chunk of hardware you'd want Go.

Erlang / Elixer and the associated VM and eco-system have their own strength, reliability for instance, with some C code thrown in for heavy lifting if required.

Re: The Crystal Programming Language

#68

Post by masklinn »

singularity2001 wrote: post #58
keypusher wrote: post #50

Python is to Nim as Ruby is to Crystal.

More like Crystal could become to Ruby what RPython is to python

That makes no sense. RPython is not a general-purpose development language, it's a strict subset of Python for writing VMs. From what I understand Crystal aims to be a general-purpose statically-typed native-compiled language with a syntax similar to Ruby in much the way Nim aims to be a general-purpose statically-typed native-compiled language with a syntax similar to Python.

Neither Nim nor Crystal exist solely to write VMs and auto-implement JITs, and programs in neither is expected to run unmodified on a VM for the inspiration language.

Re: The Crystal Programming Language

#69

Post by masklinn »

singularity2001 wrote: post #54

Now someone convince Matz to reimplement Ruby in crystal, add optional typing to CRuby, and you have won big time.

Except for the parts where you've lost spent years reimplementing an implementation-defined language and you've lost the existing C API so most any C extension which doesn't use Fiddle (or similar FFI mechanisms) is incompatible.

Re: The Crystal Programming Language

#70

Post by infraruby »

sergiotapia wrote: post #46

I'm looking for something beautiful like Ruby but fast like Go. Do you think Crystal fits this bill? Also, are there packages/libs/gems for Crystal? What are they called? What do I google for? One of the major reasons why I dumped Go is that it's just too verbose and makes me write too much boilerplate code. I want to sort a collection and I have to write the same algorithm every single time for every single type. It…

> I'm looking for something beautiful like Ruby but fast like Go.

Have you tried InfraRuby? InfraRuby is a compiler and runtime for statically typed Ruby: http://infraruby.com/blog/why-infraruby

Post reply on HN