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)
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.
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.
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.
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.
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.
> &+, &-, &. 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).
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.
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.
37 comments
[ 3.0 ms ] story [ 86.9 ms ] threadOut of curiosity, what's the purpose of this change? Style enforcement? Simpler parser?
Great work so far, thanks! Absolutely in love with the language.
> Next releases should enable some stories around parallelism
- Goals of Crystal over say Ruby? Speed? Safety?
- What drew you to try it?
There's a list on https://crystal-lang.org/docs/ that is less tongue in cheek.
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.
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.
Crystal https://p.thorsen.pm/f4b376d71d1a
Dlang https://p.thorsen.pm/f5f7d6b09480
Golang https://p.thorsen.pm/369b79e836a8
Same applies to any other language.
FYI for the curious, running crystal in a google cloud function is now as simple as: https://gist.github.com/sam0x17/5b26ffa0ae663f3137fdf6c98256...
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).
http://github.com/crystal-lang/crystal/issues/26
https://github.com/crystal-lang/crystal/issues/5430
You knew each languages solve different problems in AI or space age.
Are there any notable applications written in Crystal, for reference?
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.