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

171–180 of 439 posts

Re: Crystal: Fast as C, Slick as Ruby

#171

Post by RX14 »

kristianp wrote: post #54
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…

Maybe the makers of Crystal need to take a leaf out of Go's book. Despite the Go creators not being windows users (AFAIK), they support Windows as a primary target, to help adoption, I assume. Of course the Crystal people probably don't have the same number of developers working on it as Go did even early on. Edit: Go took a little while to support windows, not until around July 2010. See this question from November…

The plan is to support windows before 1.0, although the core devs are reluctant to "open up" to the large amount of developers windows support would bring before they are finished making breaking changes.

Re: Crystal: Fast as C, Slick as Ruby

#172

Post by RX14 »

_uhtu wrote: post #69
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.

My biggest concern if i were to try to use Crystal in production would be the lack of "googleability". I'm guessing your team is very familiar with the language, so it's not as much of a problem that you can't Google a problem when it happens. Do you feel that this is a major roadblock for people new to crystal, or are the majority of errors very intuitive? the second thing is that according to the site crystal is in…

Just to add on that breaking changes are always compile errors, with a nice description of what you need to do to fix it, which makes the breaking changes a lot more manageable.

Re: Crystal: Fast as C, Slick as Ruby

#173

Post by javiercr »

solidsnack9000 wrote: post #128
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…

The biggest practical downside with Elixir relative to Crystal is lack of types. The per-thread GC is an important advantage, though.

With pattern matching [1] and guards [2] you often don't miss explicit types.

[1] http://elixir-lang.org/getting-started/pattern-matching.html

[2] http://elixir-lang.org/getting-started/case-cond-and-if.html...

Re: Crystal: Fast as C, Slick as Ruby

#174

Post by DHMO »

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!!! ;)

You don't have to use do; end or do |a,b|; end in Ruby; you can use { } and {|a,b| }, even for multiline. There are options.

Re: Crystal: Fast as C, Slick as Ruby

#175

Post by pjmlp »

exDM69 wrote: post #170
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…

About GC: it would be nice if there would be some kind of standard-ish implementation framework for a GC in an LLVM language. LLVM has been enabling fantastic new programming languages, and while it has support for a GC, I have not found a GC library that would be easy to embed in a new compiler/runtime environment. Now there are dozens of LLVM-based languages (or language prototypes) that have different, incompatibl…

It is very hard to have a general purpose GC library, because the best GC algorithms require a tight cooperation between compiler, GC and language semantics.

For me, the only viable alternative to GC are substructural type systems like in Rust's case.

Re: Crystal: Fast as C, Slick as Ruby

#176

Post by RX14 »

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…

Just to add another data point, I've seen crystal do over 100k requests per second on a single desktop core.

Re: Crystal: Fast as C, Slick as Ruby

#177

Post by bluetomcat »

exDM69 wrote: post #164
bluetomcat wrote: post #136

Earlier quoted context omitted.

Shameless plug: is it considered totally uncool in 2016 for one to be developing a memory-unsafe, manual MM, non-OO, thread-denying language that preserves most of the C semantics? https://github.com/bbu/quaint-lang

No, definitely not! I'd be very interested in a language that is roughly as low level as C, but has some obvious warts "fixed" while still being able to run on bare metal or with a minimal runtime system. I also don't care about a standard lib as long as I can call open(), close(), read(), write(), socket(), etc. Native threads is another requirement for me. Things I'd like to see in a language: - compile to native e…

My next big endeavour with Quaint will be to create a clean module and linking system (without header files or any textual inclusions). Each source file will be transformed to a corresponding unit which contains code, data and exported type definitions. The linker would then merge these units and produce a native executable that runs your program in the self-hosted VM which will be a part of that executable. Pure native compilation or LLVM integration is too much of a hassle for me at this point.

One of the virtues of the language would also be the direct correspondence between the HLL code and the emitted VM instructions, without any optimisation passes. This makes it much easier to reason about code performance and to write code which performs consistently and predictably (albeit a bit slower).

Re: Crystal: Fast as C, Slick as Ruby

#178

Post by catnaroek »

TickleSteve wrote: post #150
catnaroek wrote: post #134

Earlier quoted context omitted.

> The vast majority of all code you write will not invoke UB That's a bit like saying “the vast majority of the haystack doesn't contain any needles”. > most people tend to stick to an 'easy' subset of syntax I'm not sure I understand what you mean. Undefined behavior has nothing to do with syntax. It's strictly a semantic issue. > It used to be that people used dynamic memory allocation to beat C with, but that is j…

You're correct.... the vast majority of the haystack doesn't contain any needles, thats the point. And you also know where the needles tend to be and stay away from that area. I'm not implying that UB doesn't exist, simply saying that using C is a different mindset. If you use C, you dont just use the language, you use the language, the toolchain and the machine, you're familiar with the whole stack, quite often down…

> The point about memory management is that memory management is just case of the general problem, i.e. resource management.

Wholeheartedly agree. I'm aware that GC is no solution for this problem. But I'm not arguing in favor of GC - I'm arguing in favor or making manual resource management safer, for example, like Rust does. Resource management is every single bit as manual as in C - the only difference is that the compiler yells if you do it wrong.

Re: Crystal: Fast as C, Slick as Ruby

#179

Post by jhoechtl »

I seldom whine about blog posts but his one clearly justifies as click-bait. Not because of it's otherwise good content. But if it takes me a Google search instead of having within the very first sentences a link to the obvious target,

https://crystal-lang.org/

there is something f~*#ing wrong with the article.

Re: Crystal: Fast as C, Slick as Ruby

#180

Post by wtbob »

> Have you ever dreamed of a programming language as beautiful as Ruby but as fast as C?

Yeah, I discovered Common Lisp back in 2006 and have been using it ever since …

I discovered Go back in 2009 and have been using it ever since, too.

What does Crystal get me that these two don't?

Post reply on HN