Crystal 0.27.0 released | Hacker News Reader

Crystal 0.27.0 released

crystal-lang.org

173 pointsksec36 comments

Major props to the Crystal team for this release and for addressing our concerns about running in Google Cloud Functions. This has enabled gcf.cr (https://github.com/sam0x17/gcf.cr) to work more consistently and has paved the way for doing crystal compilation in a cloud function, which until now has been impossible.

FYI for the curious, running crystal in a google cloud function is now as simple as: https://gist.github.com/sam0x17/5b26ffa0ae663f3137fdf6c98256...

I recently ported a fairly simple ruby project to crystal, and am happy with the result. I'm now writing another smallish project in crystal, and finding it quite productive. I like the syntax and language features of ruby, but I prefer static typing... so it's a nice addition. I'm glad to see crystal has momentum.

Did a quick search but I wasn't able to find anything on the site:

- Goals of Crystal over say Ruby? Speed? Safety?

- What drew you to try it?

On https://crystal-lang.org/ "Fast as C, slick as Ruby".

There's a list on https://crystal-lang.org/docs/ that is less tongue in cheek.

Is it actually as fast as C? That seems like quite a claim.

It uses LLVM like Swift, Rust, & Julia. I'm not sure if it can beat highly optimized C code, but generally is in the neighborhood of C, while letting you code like a rubyist. This is similar to how Nim lets you write code similar to Python and it then transpiles to C or C++ code to be compiled by gcc or Js to be run in the browser.

Any statically typed language that doesn't do anything really stupid will be as fast as C when using the same backend (LLVM here) and the same type of coding (e.g. not taking into advantage high level libs that abstract everything, but doing regular stuff like loops, bit mangling, string processing, etc).

Pascal, Rust, ADA, and lots of others all are (or can be, when programmed properly with comparable constructs) "as fast as C" (and in some cases, e.g. when avoiding aliasing issues) faster.

It's fast as C in the same way Java and Go are as fast as C. To put it in more concrete terms, it's worst cases on the same order of magnitude as C at least for non-specialized usecases. Whereas dynamic languages are usually many orders of magnitude slower. Comparing "the speed of languages" is largely bullshit and you need to be comparing a specific problem.

Crystal certainly has the genes required to be as fast as Go, and I think very few people are unhappy with Go's performance. Currently the major difference between Crystal and Go's single-threaded performance is the GC and thats not too bad. Parallelism is coming soon.

You could say that Crystal and Go (by default) is faster than C (by default) for IO bound workflows because of how IO is handled in Crystal and Go. But most people look at micro-benchmarks which don't reflect the difficulty of achieving C's performance in C.

My Crystal test code with primes managed to run 4x faster than the D version and 1.15x faster then the Go version when built with the --release switch, but when I ran it up to 100k it filled up all my 8GB of memory and started swapping. The D and Go versions run fine up to 100k without any issues and without filling up the memory. Running it up to 100k probably also causes integer overflow and I couldn't make the range iterations work with uint64 as I'm not quite familiar with the language.

Crystal https://p.thorsen.pm/f4b376d71d1a

Dlang https://p.thorsen.pm/f5f7d6b09480

Golang https://p.thorsen.pm/369b79e836a8

You should definitely consider using Set(Int32) instead of Hash(Int32, Bool). Not sure why it is using so much RAM but I strongly encourage you to submit this as an issue on the crystal lang github.

The problem is that not all the languages tested have a Set type. This is why all the implementations use a Hash or map or associative array type, which are roughly the same thing. Othwerwise we are comparing apples with oranges. I also refuse to use anything which is not included in the standard library. The program does really basic stuff, so all of its building blocks should be in the core language. This is why the Rust implementation is slower than D or Go - because it uses HashMap which is slower than D's associative arrays or Go's maps.

I reported it and it turns out that the integer overflow generated the memory consumption issue. After modifying the code it's speed is par with Go.

Remember C compilers used to generate pretty crappy code, it took them a couple of years to improve.

Same applies to any other language.

Looking forward to Windows support and parallelism. After that a stable v1.0 and I am more than happy to use Crystal for my productive projects.

Great work so far, thanks! Absolutely in love with the language.

Absolutely. My favourite bit of these release notes:

> Next releases should enable some stories around parallelism

> &+, &-, &. They will perform additions, subtraction and multiplication with wrapping

It's definitely good that languages are adding this but it's a shame they didn't go for %+, %- and %. Some other language (I forget which) uses those and they are a lot more obvious in my opinion (because % means modulo pretty much everywhere and it is essentially a modulo operation).

I haven’t used Crystal, but wouldn’t that cause some parsing ambiguities? `a %- b` would clash with `a % -b`.

I've only done some minor patches to Crystal, but I don't think so -- after all, `a & -b` is a perfectly legal operation as well.

Good point, you could swap them though: -%

Awesome to see #dig merged in. I did the original PR 2 years ago but didn’t follow through. Glad someone else picked it up. This makes unmapped JSON much more sane.

From now on, if the arguments of a method call are to be splitted across multiple lines, the comma must be at the end of the line, before the line break.

Out of curiosity, what's the purpose of this change? Style enforcement? Simpler parser?

Simpler code. This style of code was accepted by the parser but not the automated code formatter. We decided it was easier to disallow it, as the style was uncommon (especially so as ruby doesn't accept that style either, and a lot of crystal's style guidelines are based off ruby's)

Windows support is... not good.

http://github.com/crystal-lang/crystal/issues/26

There is on-going checklists to implement the remaining tasks:

https://github.com/crystal-lang/crystal/issues/5430

Windows first class support is very nearly ready and many years in the making.

Crystal has both speed and expressiveness because it doesn't need ridiculous parentheses, curly brackets, semicolons, lots of line of code like you get in most languages.

I favour writing as productive and testing spec as I can and minimal the code smell and don't need colours highlighting in my code.

Beside, having the ability to write pure or system calls in C within Crystal is a big wins.

I've always found Crystal interesting whenever I came across it and finally installed it and got a simple local server running.

Are there any notable applications written in Crystal, for reference?

I appreciate having the pull requests linked. I did read through a couple of the discussions on those.

Just choose elixir, golang or C# with .net. Crystal has been “almost ready” since 2016.

Where does your "almost ready" quote come from?

We don't get where "almost ready" message since I have been coding Crystal.

You knew each languages solve different problems in AI or space age.

imo it is ready. We've been using it in production for a little over a year now and the breaking changes that have occurred have been trivial to deal with.

It will be my language of choice once they compile to wasm

The Haskell style comma before the next element is soooo nice for adding and removing elements over time. I wish more languages used that style.

It works best with Haskell-style indentation though. With more "conventional" syntax based languages, it's best to just always have a comma at the end

Do you have example of what you mean by that?

Reply on news.ycombinator.com