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

111–120 of 439 posts

Re: Crystal: Fast as C, Slick as Ruby

#111

Post by westoque »

sdogruyol wrote: post #43
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'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.

@sdogruyol

Sure, thanks. Would love to hear that.

A blog post would probably be more appropriate since it will have a wider audience and will be good for Crystal and its community.

Re: Crystal: Fast as C, Slick as Ruby

#112

Post by krzat »

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…

People want non-GC language because everyone already has GC language that their are comfortable with.

So basically C/C++ replacement is the only niche that is left to fill. It would be even better if new language could replace even GC-languages, so I can can write fast low level libraries or websites in single language, without sacrificing productivity. That would be the Holy Grail I guess.

Re: Crystal: Fast as C, Slick as Ruby

#113

Post by ken47 »

Scarbutt wrote: post #58
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…

I have seen Erlang VM handle 100k requests per second on a distributed cluster A single JVM server can do that load, scaling and providing fault tolerance for a server that just accepts requests is trivial these days, also, if your requests do computationally intensive stuff you are going to have a very bad time with Erlang. It all depends on the problem domain. Exactly, and the domain for Elixir/Erlang is way more n…

The Erlang VM (modified) has supported over 2M concurrent connections: https://blog.whatsapp.com/196/1-million-is-so-2011?

Furthermore, assuming each request is mapped to an Erlang process, each of them get their own VM -- no stop-the-world.

Re: Crystal: Fast as C, Slick as Ruby

#114

Post by bjz_ »

yamadapc wrote: post #92
hubert123 wrote: post #37

Earlier quoted context omitted.

Yeah it's weird how Rust has suddenly made me look for no GC languages everywhere I look. It opened up a whole new desire to not accept no for an answer in that regard. I have this burning thought in the back of my head that there just has to be a simpler way to offer it than Rust does it too.

The D Language ( http://dlang.org/ ) has a @nogc pragma ( https://dlang.org/spec/attribute.html#nogc ). You just annotate functions that you don't want to use the GC in with it and it'll assert that they don't use it.

But then you lose memory safety

Re: Crystal: Fast as C, Slick as Ruby

#115

Post by spriggan3 »

welder wrote: post #87
Svenskunganka wrote: post #83

Earlier quoted context omitted.

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.

Python has "significant white spaces", Crystal doesn't.

Re: Crystal: Fast as C, Slick as Ruby

#116

Post by fauigerzigerk »

Taek wrote: post #110
fauigerzigerk wrote: post #104

Earlier quoted context omitted.

Crystal seems to be targeted at a domain where ruby is not fast enough. That includes domains where GC is a problem. A tracing GC means that you either have to deal with potentially long GC pauses or you need a lot of extra free memory at all times to give the GC time to catch up before running out of memory [1]. Go says it can achieve 10ms max pause time using 20% of your CPU cores provided you give it 100% extra me…

If you are on a server do you need 10ms max pause time? For most applications running go on a remote machine, 25ms should be in the realm of acceptable.

True, but I don't know how much that would buy us in terms of memory utilisation and CPU usage.

Re: Crystal: Fast as C, Slick as Ruby

#117

Post by TickleSteve »

catnaroek wrote: post #75
TickleSteve wrote: post #66

Earlier quoted context omitted.

Thats simply not true. UB is simply the latest stick to hit C with. In day-to-day working nobody worries about UB at all as you generally don't notice it. Same with lack of a GC; this is a plus point for C for most applications, not a negative. (and yes, I do have plenty of experience in it, I've been using it for the past 20 years, have you?).

> UB is simply the latest stick to hit C with. Honest question, which is the case? (0) You find it easy to determine, by visual inspection, whether a piece of code has undefined behavior. (1) Your coding practices make it difficult to accidentally introduce undefined behavior in the first place. > Same with lack of a GC; this is a plus point for C for most applications, not a negative. Agreed. C addresses use cases f…

Its a combination of both.

The vast majority of all code you write will not invoke UB, most people tend to stick to an 'easy' subset of syntax, unlike say C++ where everyone uses a different subset of features making it in effect multiple languages.

A combination of testing the known edge cases, wraparound issues, size issues, static analysis and tooling means running into an example of UB is extremely rare in most cases.

It used to be that people used dynamic memory allocation to beat C with, but that is just a resource management issue. TBH, this is not rocket science. If you need dynamic memory allocation, you had damn well better know how to use it properly.

Its an example of laziness and people ignoring the machine.

Another example is performance; saying that a language comes within a factor of 2 of C's performance and therefore is fast is absolutely ridiculous. a factor of 2 is huge.

You have to remember that people who write C are dealing with machine-specifics day-in, day-out. we're bit-fiddling and writing MPU code and drivers, etc.

Basically, we're much more aware of the machine than higher-level softies, so what would normally be UB is actually DB in most cases, its defined by the compiler and hardware that we're intimately familiar with.

...and that isn't to say that you can't write high level abstracted code in C, the simplicity of the language lends itself to (properly) efficient implementation, not efficient in the sense of Java or Ruby ;o)

Re: Crystal: Fast as C, Slick as Ruby

#118

Post by p0nce »

yamadapc wrote: post #92
hubert123 wrote: post #37

Earlier quoted context omitted.

Yeah it's weird how Rust has suddenly made me look for no GC languages everywhere I look. It opened up a whole new desire to not accept no for an answer in that regard. I have this burning thought in the back of my head that there just has to be a simpler way to offer it than Rust does it too.

The D Language ( http://dlang.org/ ) has a @nogc pragma ( https://dlang.org/spec/attribute.html#nogc ). You just annotate functions that you don't want to use the GC in with it and it'll assert that they don't use it.

Since you can:

- disable the GC

- deregister threads so that they are not stopped by GC

- eventually avoid the runtime altogether

There really is no realtime system that D can't do.

The whole anti-GC thing is a giant strawman that consider all GC stop-the-world, unavoidable, and overarching. Academia decided in favor of GC decades ago, and industry has been following suit for good reasons: mental overhead associated with finding owners to everything.

Re: Crystal: Fast as C, Slick as Ruby

#119

Post by def- »

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…

> I am still wondering why so few people use it.

While Nim is my favorite language, I can understand that it has a small userbase, for these reasons:

1. No major backer like Google for Go or Mozilla for Rust

2. No killer feature like "memory safety and performance without GC" for Rust, instead a mix of all the reasonable down-to-earth features I want in a programming language

3. Some unique decisions instead of what you're used to from other languages, for example partial case sensitivity

Re: Crystal: Fast as C, Slick as Ruby

#120

Post by spriggan3 »

makufiru wrote: post #96
Svenskunganka wrote: post #15

I'd like to put out there that Crystal is absolutely awesome. The language itself is Crystal clear, but the language documentation and API documentation - oh my! I had never worked with compiled languages before I tried Crystal, but had always had a huge interest in getting into that. When I wanted to learn the compiled ecosystem I looked at languages like Go and Rust, but the learning curve for those was a bit overw…

In my experience, Golang's Windows support is actually fairly poor. I think it is largely to do with the clunky interface that is CGo. I found Rust to be less "warty" by a large margin with good library support in a lot of areas. Your mileage may vary, of course.

> Golang's Windows support is actually fairly poor.

It does exist unlike Crystal, so you should explain what you mean by poor. I never had a problem compiling a project with CGo on Windows.

Post reply on HN