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

Crystal: Fast as C, Slick as Ruby

blog.codeship.com

Post reply on HN
Print view View original

251–260 of 439 posts

Re: Crystal: Fast as C, Slick as Ruby

#251

Post by tbrooks »

clessg wrote: post #4

Looks very nice. I hope it gains momentum. For now, if you want a fast language with the beauty and productivity of Ruby, check out Elixir [0] and its web framework, Phoenix [1]. I've been using Phoenix for a year, and it's the first framework that I've actually liked more over time. And I've been a web developer for a decade. With its recent 1.0 release, Phoenix is gaining a lot of momentum. If you want some idea of…

I don't have a CS background, so I can't speak much to the performance of Elixir and Crystal.

As someone who has made the transition from Ruby to Elixir, I'm really, really intrigued by Crystal.

Though, upon a cursory look into the Crystal docs and community, a couple things are clear...

Elixir killed it on all the things surrounding the language.

- docs

- testing

- Slack chan, IRC, mailing list

- package manager (Hex)

- build tool (Mix)

- web framework (plug & Phoenix)

- books from major publishers (manning, pragprog, etc.)

- ElixirConf

- ancillary teaching (ElixirSips, LearnElixir, Elixir Fountain, etc.)

While the language may not be as computationally performant as some of others mentioned, all the things above lower the barrier to entry for adoption and make Elixir a more attractive language than some of the counterparts. And it's amazing that a language this young has nailed it on these fronts.

Re: Crystal: Fast as C, Slick as Ruby

#252

Post by steveklabnik »

progman wrote: post #85
bluetomcat wrote: post #67

Earlier quoted context omitted.

All of these "fast as C" claims about modern, high-level Python-like languages (be they statically typed and natively compiled) are missing the point. It is mostly the minimalistic and terse programming style that C encourages that makes C programs performant. You avoid allocations wherever possible, you write your own custom allocators and memory pools for frequently allocated objects, you avoid copying stuff as muc…

There actually is one high-level Python-like language that really is almost "as fast as C". http://nim-lang.org I am using it for years already, and it is really performant, somewhere between C and Rust. I am still wondering why so few people use it. Benchmark: https://github.com/kostya/benchmarks Nim vs Rust: http://arthurtw.github.io/2015/01/12/quick-comparison-nim-vs... Performance discussion: http://forum.nim-lan…

Just a small note for anyone reading the "Nim vs Rust" post; today, regex! is much slower than Regex::new.

Re: Crystal: Fast as C, Slick as Ruby

#253

Post by jjnoakes »

p0nce wrote: post #249
jjnoakes wrote: post #207

Earlier quoted context omitted.

> if what I share has a global owner (ie. the GC), I don't have to lock or copy by definition Then how you do avoid data races? Two shared references which can mutate your shared data requires either a copy, a lock, immutability, or a single writer.

I use "parallel foreach", sometimes worker queues, implicit single writer... like in C++. It sounds like you think only Rust-style ownership can avoid data-races. Sure, if you want the type system to do it. For me discipline is enough and I've seen it work in teams too. Not seeing such a problem really.

Nothing specific to Rust, although Rust encodes in the type system what I usually have to keep track of mentally, which is nice.

Trivially parallel algorithms do benefit from constructs like "parallel foreach" and implicit single writers, but in general, one either has to stick to those models (where the cognitive overhead is low but manageable) or if one ventures into more complex territory, one has to either deal with a higher mental complexity (ownership or locks), performance degradation (copying), or immutable data (if it fits your problem and doesn't decrease performance, win-win).

My argument is simply that GC doesn't fix everything, and the mental overhead of tracking ownership of memory (to me) isn't a huge burden, especially since I have to do it for non-memory resources and memory resources shared between threads already.

I'm not against a GC - I like languages that mix GC and non-GC side-by-side - because sometimes I do want to just forget about my memory, but only if it fits my problem domain. But I don't think GC beats non-GC hands-down for-all-cases.

Re: Crystal: Fast as C, Slick as Ruby

#254

Post by SparkyMcUnicorn »

Athas wrote: post #6

The claim is "fast as C", so I was surprised that the performance comparison was with Ruby, not with C. On my machine, the Ruby Fibonacci program executes in 47.5s, while a corresponding C program executes in 0.88s - that's a factor 54 difference, while the article reports a factor 35 for Crystal. That's good, but what causes the difference? This benchmark is pretty much all function call overhead, so I doubt it's re…

From this quote it sounds like the more CPU intensive it is, the more you can expect when comparing to Ruby.

>Remember: The cake is a lie, and so are benchmarks. You won’t have 35x increase in performance all the time, but you can expect 5x or more in complex applications, more if it’s CPU intensive.

Re: Crystal: Fast as C, Slick as Ruby

#255

Post by jsmith0295 »

qaq wrote: post #201
rdtsc wrote: post #41

Earlier quoted context omitted.

> Elixir is not a fast language. Depends what we mean by fast. I have seen Erlang VM handle 100k requests per second on a distributed cluster. That's plenty fast. Moreover, because of fault tolerance, it means ability to have a better uptime, with less people on-call. "Fast" can also be measured to include that, if system goes 200k requests per second, but crashes at midnight and stays down for a few hours, the avera…

Phoenix is slightly faster than Gin (Go web framework) so depending on your use case it can be fast :). Obviously one of the primary selling points is OTP/BEAM VM with all the concurrency, HA, soft realtime etc. but with simpler syntax than Erlang.

Its only faster at IO. Once you start adding CPU bound work to the equation, Phoenix's performance will begin to drop. It's similar to Node in that regard.

Re: Crystal: Fast as C, Slick as Ruby

#256

Post by renox »

paulddraper wrote: post #225
ynniv wrote: post #218

Earlier quoted context omitted.

just look at hand the performance articles on Java. Just look at the hand performance articles on C... People talk about it because you can do it, not because you have to do it.

And you can do it because someone found that it was necessary to do. It's crazy I can't tell Java and NodeJS "use the memory you need". Instead I have to specify max memory sizes (and then watch as they inevitably consume all of it).

> 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..

Re: Crystal: Fast as C, Slick as Ruby

#257

Post by twistedpair »

clessg wrote: post #4

Looks very nice. I hope it gains momentum. For now, if you want a fast language with the beauty and productivity of Ruby, check out Elixir [0] and its web framework, Phoenix [1]. I've been using Phoenix for a year, and it's the first framework that I've actually liked more over time. And I've been a web developer for a decade. With its recent 1.0 release, Phoenix is gaining a lot of momentum. If you want some idea of…

Looks like Play! took #2. I can attest to it's efficiency. Just yesterday one of our mobile apps went nuts with repeating requests, and rps shot to 53K for a few minutes, but no one noticed, as our API max response time didn't break 15ms.

JVM+FP FTW.

Re: Crystal: Fast as C, Slick as Ruby

#258

Post by untothebreach »

kusmi wrote: post #194

Does it have any benefit in particular over lua/luaJIT?

off the top of my head, I would say it's similarity to Ruby means that Ruby devs would have an easier time learning the language than learning an entirely new one. Crystal also seems to have an extensive standard lib, which lua does not. (that's not a criticism of lua, just an observation. I know luarocks has made the lack of a large stdlib much less of a pain point for lua)

Re: Crystal: Fast as C, Slick as Ruby

#259

Post by qaq »

jsmith0295 wrote: post #255
qaq wrote: post #201

Earlier quoted context omitted.

Phoenix is slightly faster than Gin (Go web framework) so depending on your use case it can be fast :). Obviously one of the primary selling points is OTP/BEAM VM with all the concurrency, HA, soft realtime etc. but with simpler syntax than Erlang.

Its only faster at IO. Once you start adding CPU bound work to the equation, Phoenix's performance will begin to drop. It's similar to Node in that regard.

True any generalisation has flaws :) Even faster is relative do you care about avg or worst case performance do you care more about throughput or latency and on and on :)

Re: Crystal: Fast as C, Slick as Ruby

#260

Post by rdtsc »

StavrosK wrote: post #169
rdtsc wrote: post #36

Earlier quoted context omitted.

> that if it wasn't FOSS I'd have decided it's being astroturfed. That's a good sign! You know why? Because it has a great community and is very friendly for new comers. Jose, Eric and the rest of the team made that a priority and it shows. It doesn't just mean being nice on IRC, it also means putting usability first, putting more effort in how example looks, how documentation looks and so on. If Google invented a la…

"Friendly for newcomers"? I tried to write something the other day, and had an Erlang developer friend to help me. The Elixir docs section just says "buy one of these books to get started", which is completely unacceptable, and we (mostly my friend, as I had no idea what anything is) spent an hour trying to figure out how to run a node, with Google not providing any useful answers. That's as hostile to newcomers as i…

Oh sorry to hear that Stavros. Sometimes Erlang knowledge doesn't translate directly to Elixir, there are just a few conventions to keep in mind.

I've used these before when playing with it:

* http://elixir-lang.org/getting-started/introduction.html

* https://howistart.org/posts/elixir/1

* Asking on #elixir-lang on freenode IRC

Here is a specific chapter on distribution and nodes:

http://elixir-lang.org/getting-started/mix-otp/distributed-t...

Their IRC channel, they were pretty helpful for me. And also I am sure they'd want to hear about your experience to also improve their docs and tutorials.

Post reply on HN