Crystal: Fast as C, Slick as Ruby • Hacker News Board

Re: Crystal: Fast as C, Slick as Ruby

#401

Post by jestar_jokin » Fri, Aug 05, 2016, 8:11 AM UTC

anp wrote: post #8

From this post, Crystal appears to have some of the things many people have been lusting after in Rust: sophisticated metaprogramming, fewer sigils, a bigger standard library, fibers/coroutines/whatever-they're-called-now. But it still has a GC :(. Rust has completely spoiled me with making it easy to minimize dynamic memory allocation and copies, and to know (almost always) deterministically when something will go a…

Nim[0] takes an interesting approach. It uses "deferred reference counting", effectively allowing GC cleanup to be spread out over a period of time. This at least helps with GC pauses.

It also seems to allow tweaking for soft realtime systems, e.g. games.

[0]http://nim-lang.org/docs/gc.html

Re: Crystal: Fast as C, Slick as Ruby

#402

Post by im_down_w_otp » Fri, Aug 05, 2016, 8:17 AM UTC

bjz_ wrote: post #181

iamd3vil wrote: post #165

Earlier quoted context omitted.

Elixir has optional typing though. You can type check with Erlang's Dialyzer.

Dialyzer uses success types, which don't always let you know when you have a soundness problem. The only thing you can count on is that if it does cry out, there certainly is something you need to fix. It also lacks parametric polymorphism, which means you often lose a great deal of useful type information. The theory behind Dialyzer is impressive, but I was pretty disappointed with it in practice.

You didn't enable the right flags.

Re: Crystal: Fast as C, Slick as Ruby

#403

Post by costajob » Fri, Aug 05, 2016, 8:22 AM UTC

kimshibal wrote: post #45

crystal on rails. i want this.

Stick with Ruby then: Rails is great to build monolith application easily, Crystal suits a different use (micorservices?). Also the lack of Ruby meta-programming facilities (send overall) will make to rewrite Rails with Crystal really challenging (pointless?)

Re: Crystal: Fast as C, Slick as Ruby

#404

Post by continuations » Fri, Aug 05, 2016, 8:26 AM UTC

asdf1234 wrote: post #161

continuations wrote: post #38

Earlier quoted context omitted.

Is Elixir really fast for web apps though? According to the web framework benchmark [1] the performance of Elixir is pretty bad - it's consistently slower than python and ruby frameworks. [1] https://www.techempower.com/benchmarks/#section=data-r12&hw=...

Erlang/Elixir is much, much faster than either Python or Ruby especially when it comes to workloads like your typical web app. In the Techempower benchmarks the Phoenix tests had a ton of errors and there was no preview run so whoever submitted them wasn't able to fix them. Look at the error column. I assume they'll be fixed in the next run.

Error isn't why Elixir performed poorly in the web framework benchmark.

Take a look at the "Single Query" test [1]. The entry for Elli has zero error and is still slower than many Python & Ruby frameworks.

[1]: https://www.techempower.com/benchmarks/#section=data-r12&hw=...

Re: Crystal: Fast as C, Slick as Ruby

#405

Post by lmm » Fri, Aug 05, 2016, 8:44 AM UTC

catnaroek wrote: post #309

lmm wrote: post #296

Earlier quoted context omitted.

An occasional exception and silent corruption the rest of the time is still a lot better than silent corruption all the time - it's much easier to notice in the first place, and as long as you have one instance of the exception you have a stack trace to start from. And in practice the JVM/standard library throws ConcurrentModificationExecption pretty reliably.

> An occasional exception and silent corruption the rest of the time is still a lot better than silent corruption all the time The fundamental problem still remains, that in neither case can I use the language's semantics to guide the design of my program. > and as long as you have one instance of the exception you have a stack trace to start from Oh, really? How am I supposed to find what the problem is in the gener…

The stack trace tells you where one of the concurrent accesses happened. As opposed to data corruption where (if you even manage to witness it in the first place) all you know is that one of the things that accesses that memory got it wrong.

Re: Crystal: Fast as C, Slick as Ruby

#406

Post by lmm » Fri, Aug 05, 2016, 8:45 AM UTC

kminehart wrote: post #354

banachtarski wrote: post #329

Earlier quoted context omitted.

He said decent type system, not static one.

C, Java, and C# have decent type systems, especially compared to JavaScript.

No sum types, no higher-kinded types, huge verbosity in declaring a new type. I'm talking something like OCaml/F#/Scala/Haskell.

Re: Crystal: Fast as C, Slick as Ruby

#407

Post by bjz_ » Fri, Aug 05, 2016, 9:00 AM UTC

im_down_w_otp wrote: post #402

bjz_ wrote: post #181

Earlier quoted context omitted.

Dialyzer uses success types, which don't always let you know when you have a soundness problem. The only thing you can count on is that if it does cry out, there certainly is something you need to fix. It also lacks parametric polymorphism, which means you often lose a great deal of useful type information. The theory behind Dialyzer is impressive, but I was pretty disappointed with it in practice.

You didn't enable the right flags.

What flags?

Re: Crystal: Fast as C, Slick as Ruby

#408

Post by spriggan3 » Fri, Aug 05, 2016, 9:46 AM UTC

westoque wrote: post #30

Was wondering how many companies actually use Crystal in production. I was interested in Crystal but the lack of apps using it in production and proof of concept on the field is making me doubt its usefulness.

I don't think Crystal is production ready, the language is still evolving and not stable at all, from minor version to the next.

Re: Crystal: Fast as C, Slick as Ruby

#409

Post by valarauca1 » Fri, Aug 05, 2016, 12:26 PM UTC

adrusi wrote: post #271

valarauca1 wrote: post #216

Earlier quoted context omitted.

4. The fact that operator order is changed by the amount of white space between symbols 2+2 * 5 = 20 2 + 2 * 5 = 12

If you're consistent about how you space your infix operators, this will have no impact on your code. If you put space around some operators and not around others, in a way that doesn't correspond to precedence, you're going to confuse anyone who reads your code, in any language.

Being confused by code is no excuse for code not doing what ya know... every other programming language has done for the past 50 years.

I get that trying new things, but somethings are pretty well agreed upon.

Re: Crystal: Fast as C, Slick as Ruby

#410

Post by mike_hearn » Fri, Aug 05, 2016, 12:52 PM UTC

happyslobro wrote: post #317

renox wrote: post #256

Earlier quoted context omitted.

> It's crazy I can't tell Java and NodeJS "use the memory you need". Define the 'memory you need'? You know the computer doesn't have a cristal ball to know what latency vs memory usage trade off you want..

I wonder, could we just tell each JVM instance that it may use all of the memory on the system, and then let the OS kill the first VM that allocates more than the system has to offer? Would this get us the same semantics as those of a native application? Or does the JVM preallocate all of the memory that it is allowed to use?

As of one of the most recent Java releases, I believe the G1 GC does this on Windows. G1 is not the default but can be selected with a single command line flag.