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

81–90 of 439 posts

Re: Crystal: Fast as C, Slick as Ruby

#81

Post by sdogruyol »

damagednoob wrote: post #70
sdogruyol wrote: post #43

Earlier quoted context omitted.

I'm the author of Kemal(kemalcr.com), a simple, fast and modern web framework for Crystal. We've been using Crystal in production(at Protel) for more than 6 months for some heavy load APIs (100-200 req/s). We've replaced our Rails API with 64 unicorns to just 1 Kemal process and it's not even breaking any sweat while consuming nearly 100x less resource and 30x less CPU. You can ask me about our experience.

1. Has the lack of multithreading been a problem in any way? 2. Do you do the standard deployment of putting nginx/haproxy in front of a load of processes? 3. Have you been able reuse any Ruby code (including gems) or do they have to be Crystal specific.

1. It hasn't been a problem for us. 2. We put Nginx in front of Kemal and it's working like a charm :) 3. Well we haven't tried but it's pretty simple with sidekiq.cr https://github.com/mperham/sidekiq.cr

Re: Crystal: Fast as C, Slick as Ruby

#82

Post by catnaroek »

Svenskunganka wrote: post #78
catnaroek wrote: post #56

Earlier quoted context omitted.

> but if you want to learn the semantics why not just go to their docs? https://crystal-lang.org/docs/syntax_and_semantics/index.htm... Yep, fair enough. I'm somewhat worried about how abstract classes work: https://crystal-lang.org/docs/syntax_and_semantics/virtual_a... Apparently, Crystal can infer the methods of an abstract class from the methods of its subclasses. In the Animal/Dog/Cat example, what happens if, i…

> In the Animal/Dog/Cat example, what happens if, in a separate module, if define a Snake class that doesn't have a `talk` method? There are several possibilities, sadly all pretty bad The abstract class defines which methods every class that inherits from it must define by using abstract methods. If you write a class that inherits from an abstract class, and you do not define a method that the abstract class says th…

> The abstract class defines which methods every class that inherits from it must define by using abstract methods.

In their example, the type checker can infer that Animal has a `talk` method, even if it's never explicitly defined:

    abstract class Animal
      # no talk method here!
    end
    
    class Dog
In their own words, “Now the code compiles:”

    john.pet.talk #=> "Woof!"
Now, what happens if, in a separate module, I define a Snake subclass of Animal, without a talk method? What happens in this corner case isn't documented anywhere.

Type system design is very serious business, and can't be done by mindless trial and error. When a type system has a safety hole, patching it is pretty much guaranteed to break other people's code.

Re: Crystal: Fast as C, Slick as Ruby

#83

Post by Svenskunganka »

welder wrote: post #79

Stopped reading when I saw the `end` keyword... the most annoying part of Ruby. Edit: I'm getting hella downvoted but I'm leaving this here. Ruby fanboys can't silence me!!! ;)

I wonder how Lua can get by, being embedded in literally every game that supports scripting, in databases and many other tools.

It's a personal preference of course.

Re: Crystal: Fast as C, Slick as Ruby

#84

Post by ghayes »

thinkpad20 wrote: post #62
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…

Manual or deterministic memory management might be a must-have for certain usage domains, but for any domain in which one would be using ruby, this seems unlikely, and presumably one could FFI into C when this is the case. There are hardly any languages commonly used in industry which don't have GC (essentially just C/C++). And many of these garbage-collected languages are capable of blazingly fast code with a small…

One of the largest areas of concern is for real-time systems (systems which fail if they do not respond within some small time threshold). Most GC involves stopping the world to perform the GC which can pause your program's execution for some number of milliseconds. If GC pauses exceed your real-time requirements, you're out of luck.

Some languages, like erlang, do slightly better by garbage collecting erlang processes individually, so other erlang processes can continue running during GC.

Re: Crystal: Fast as C, Slick as Ruby

#85

Post by progman »

bluetomcat wrote: post #67
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…

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-lang.org/t/2261

Embedded Nim: https://hookrace.net/blog/nim-binary-size/

Nim on LLVM: https://github.com/arnetheduck/nlvm

Re: Crystal: Fast as C, Slick as Ruby

#86

Post by girvo »

jesserayadkins2 wrote: post #59
ori_b wrote: post #39

Earlier quoted context omitted.

Yes. I'm currently trying to think of a good way to add it to Myrddin, which currently makes it more or less manual. Doing it in a simple way is a tough problem. The simplest solution is to add the moral equivalent of 'null' -- objects that transition to an idempotently destructable state, which solves a lot of complexity with the data flow and analysis (yay!) at the cost of some safety (boo), and nulls (louder boo).

My language (Lily) handles the problem by trying to avoid the gc where it can. Lily is statically-typed, built-in classes can't be inherited from, and there's no C-like casting. With those rules in mind, most objects can't become cyclical. It's impossible for a list of strings to loop back onto itself, for example. It helps that the value classes backing enums (like Option and Either) are immutable, which I so far su…

Can I just say that Lily is amazingly neat, and is exactly the language I was working on myself! Seems we have a shared delusion ;)

Re: Crystal: Fast as C, Slick as Ruby

#87

Post by welder »

Svenskunganka wrote: post #83
welder wrote: post #79

Stopped reading when I saw the `end` keyword... the most annoying part of Ruby. Edit: I'm getting hella downvoted but I'm leaving this here. Ruby fanboys can't silence me!!! ;)

I wonder how Lua can get by, being embedded in literally every game that supports scripting, in databases and many other tools. It's a personal preference of course.

Yes, it's my preference. I also don't like reading/writing Lua. Python doesn't need end, neither does Crystal.

Re: Crystal: Fast as C, Slick as Ruby

#88

Post by yxhuvud »

transfire wrote: post #31

I've done some coding Crystal when I have Ruby scripts I really need to run faster. I generally see about a 5x performance over Ruby. It certainly is great to be able to jump right into Crystal coming from Ruby. It isn't very hard to convert most Ruby code to Crystal -- you just have to go through and "typify" everything. A few methods have different names and of course some don't exist but most of it is there. My on…

You may want to revisit that splat issue. Asterite did some changes regarding splats a few months back that was pretty impressive.

Re: Crystal: Fast as C, Slick as Ruby

#89

Post by z3t4 »

scoped includes are a deal breaker for me when looking at new programming languages.

ex: non-scoped (everything in foo is added to the global scope)

  inport foo
  {
    bar.do()
  }
ex: scoped (everything in foo is added to the local scope, and assigned a name-space)

  {
    bar = inport foo
    bar.do()
  }
I find it much easier to manage programs where there are no "hidden" global variables. It's especially hard when the included files also can include files, witch all adds to the global scope.

Re: Crystal: Fast as C, Slick as Ruby

#90

Post by progman »

bluetomcat wrote: post #67
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…

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…

> You avoid allocations wherever possible

If you don't have to write cutting-edge games or embedded software for tiny systems, why do you have to care about allocations at all? Today's systems and RAM's are so fast that garbage collections don't really matter in most cases. Consider SBCL (compiled Common Lisp) which is almost as performant as Java and C++.

http://benchmarksgame.alioth.debian.org/u64q/lisp.html

I used to develop software in C and C++ for many years, and a garbage collector was the thing I wanted the most. GC-free programming is unnecessarily tough in most cases, except you desperately need it for games and embedded systems.

Post reply on HN