Crystal 0.25.1 released | Hacker News Reader

Crystal 0.25.1 released

crystal-lang.org

148 pointsmikece152 comments

Crystal looks interesting although I decided to learn Golang instead. It's more mature and the WIP features described below made me cautious (i.e. what other features are immature).

Anyone know when Crystal will get concurrency-a-la-golang? i.e. running concurrent processes in parallel? At the moment I think it's still single-threaded. https://crystal-lang.org/docs/guides/concurrency.html

Still no windows support: https://github.com/crystal-lang/crystal/issues/5430

Crystal has had concurrency, almost identical to goroutines, for a long time. It's just as if you're always running with GOMAXPROCS=1. And you can still get some excellent performance on IO bound workloads with a single core. The challenge is expanding what crystal is already good at to CPU bound parallelizable workloads by implementing parallelism. This work should be done before 1.0, we have a lot more resources to work on crystal from now on, because brian is working on it full time.

And as for windows support, I'm working on it right now. Cross-compiling "hello world" has been working for a while.

Thanks for the response.

I'm no expert but when you have a server, would each request be handled concurrently by a separate thread (/fibre?)? So in that sense would the server's I/O be non-blocking? (I know each thread would be blocked as it waits for the response).

Do you have a rough time frame for parallel concurrency?

What's your view on the maturity of the language?

No, each request is handled concurrently in the same thread using evented IO. You spawn fibers, which are the analogue to go's goroutines, and many of those run in one thread. Just like nodejs (without callbacks/promises/async/await) and similar to go with GOMAXPROCS=1.

Unfortunately, I don't have a timeframe for parallelism, it's not my area of crystal and it's a fairly tricky issue.

My (biased, i'm a core developer) view on Crystal's maturity, after using it in a few of my own side-projects, is that once crystal code compiles, it runs pretty much rock solid in production. Compiler bugs are fairly rare too, although the compiler clearly isn't as mature as gcc. The main issue you face is lack of available libraries, and being forced to make a few changes every couple months when a new release comes out with breaking changes. Depending on the size of your codebase, that could be a big issue or it could be a 5 minute easy commit.

Thank you for adding more color around Crystal.

I'm somewhat new to this so bear with me. With regards to the I/O, is it like node.js? i.e. all requests are handled inside a single thread (until Crystal gets parallelism) and when the thread waits for an I/O response (i.e. a database call), it will process some of the other requests?

Yep, exactly like that.

What do you think of Nim?

No opinion as I didn't look at it. I was more focused on more mature languages and Crystal came up on my radar so I read around it.

Hrm. Your post implies that Crystal is more mature than Nim, is that intentional? If so, what makes you think that?

Oh I didn't mean to imply that. I meant I was researching mature/mainstream languages and outside of the scope of that research, it just so happened a friend mentioned Crystal. So I looked into it.

I know absolutely nothing about Nim so I can't comment either way.

I've programmed in both and as far as I can tell here's the best use case for each:

Go - I want to program explicitly and don't mind a little extra code or syntax to do it. I want close to the best performance possible and a single distributable binary. I don't mind being encouraged to "roll my own" api / web app rather than using a framework.

Crystal - I want to feel like I'm writing in Ruby, but with type checking at compile time and much better performance. I don't mind being a little less performant than other compiled languages. I want access to Rails/Sinatra-like frameworks for web/API apps rather than having to "roll my own".

Basically, if you want something quick and fun that can run in production, I love Crystal. If you want something that needs to be custom and highly performant, I love Go.

Great response. [EDIT - as highlighted by the replies below you can't use Rails with Crystal...my fault for misreading the parent] I didn't quite realize that I could use Rails with Crystal. That would be make it more interesting if I knew how to use Rails ^^

You can't use rails with crystal, the keyword is "rails-like".

Unfortunately, you can’t use actual-Rails in Crystal (it’s written in Ruby which is similar but not exactly the same).

But there are Rails-like frameworks you can use in Crystal that are just as much fun (though understandably less mature).

Check out Amber, Lucky, and Kemal to give you an idea of what’s out there.

While you can't use Rails, there are frameworks that I have heard are "similar", such as https://luckyframework.org/.

Disclaimer: I haven't used it, just read a bit about it.

I would definitely recommend amber. It's probably the most rails-like, and is more mature than other solutions at this point (kemal is more like sinatra, though it is obviously more mature being rather ancient by crystal standards)

Lucky uses type safety extensively preventing a lot of bugs. My team really enjoys working with it. You should definitely check it out.

https://luckyframework.org

>I don't mind being a little less performant than other compiled languages.

The same, if not more so, goes for Go. It might be statically compiled, but it's far from the most optimised performer.

Crystal - because it uses LLVM's optimizer - is probably better optimized at the codegen level than go. We still have a long way to go to get an optimized GC and similar though. Luckilly, bdwgc isn't too terrible.

> I don't mind being a little less performant than other compiled languages.

What other languages? Because the language uses "Fast as C" as part of it's tagline. Is this a false claim?

That's definitely such an underspecified claim that it's not even wrong. Fast as C under what conditions?

I've personally found that a lot of Go's marketing is, if not misleading, outright false. As an example: https://blog.plan99.net/modern-garbage-collection-911ef4f8bd...

If you were to use Go you would know that the GC is indeed pretty fast, on part or faster than Java / C# in many scenarios.

That's exactly what the article I linked said, isn't it? It has low pause times, at the expense of everything else.

Beware trading a visible cost for an unbounded number of smaller costs. In Go's case, in return for minimal pausing you get memory fragmentation, terrible performance if the GC is ever seriously taxed, and a 100% (!) heap memory use overhead. If you're just writing commandline daemons or servers you restart every ten minutes though, who cares?

Go doesn't come off too badly in this because it's not Java, which allocates like crazy. That's a laudable tradeoff, but that does not mean they solved garbage collection very well.

Crystal's definitely up there, faster than java at least for most workloads. That can be improved much further by innovating on the GC.

It really ought to say "fast LIKE c" because none of the core devs actually want crystal to be used for systems programming.

All they want is ruby with static types, that runs fast. Those things will satisfy them alone.

Intelligently written C/C++/D/Zig/Rust will always knock Crystal out of the park. :(

"Fast as C" should maybe be changed to something else. Crystal can bind directly to C functions and libraries without any overhead, plus you have pointers and other stuff. So you could really write code that runs as fast as C if you program like in C, but with Crystal syntax. That's where the tagline comes from. But of with course normal usage of the language, with its heap-allocated stuff, garbage collector and usual stuff (like Array#map, which does allocate a new array), you won't get performance like C, but it will be acceptable, and usually faster than dynamic/interpreted languages.

I think what we'll see coming soon, assuming some people work on it, is the recognition that Go's stdlib and all the supporting libs is where the real awesomeness lives. And for langs that support Go-style concurrency (like Crystal basically does, Kotlin, etc), people will start transpiling with only a couple of things dropping into the target language. There're just too many good pieces of crypto, http2, etc to rewrite it over and over.

I can attest to this, the amount of times I've had a look and used go's stdlib as a reference for what to do when implementing something in the std for crystal is too many to count!

Unfortunately, transpiling has a huge bunch of problems, which you can see in for example how quickly nim vs crystal compiler matured - even though the crystal compiler is more complex. I'd be interested in seeing go's stdlib, ssa backend, and toolchain turned into a robust library. Like LLVM but including a GC, a stdlib with a CSP implementation, and a complete toolchain for static compilation.

I'm curious about the transpiling problems from, say, Go to Crystal (not after SSA, but before w/ the high level constructs). I have toyed with Go to Kotlin and even though duck typing is unimplemented in the latter, I can basically get there. I even started a project to dump Go AST and type info[0] but I haven't completed it really. There are just too many amazing Go libs out there to not exercise this option.

Go does have a buildmode for c-archive and c-shared, but it's built around the hobbled Cgo, so you have to explicitly export funcs, and things like structs cannot be exported. Still, a swig-like shim/bridge could be developed, but I am unsure at what cost (I think the go mobile stuff does a form of this).

0 - https://github.com/cretz/go-dump

>I decided to learn Golang instead

So what has been your experience with Golang so far?

I've played around with a number of languages and settled on Crystal because:

* Speed

* Pleasant to use type system

* Doesn't get in my way

* Catches lots of bugs

* Fun!

I wrote http://luckyframework.org/ to write web applications with minimal boilerplate and as few runtime errors as possible. Take a look and let me know what you think

That looks really nice. When I clicked the link, I wasn't expecting a good looking page and all of those docs, it was a nice surprise. I look forward to checking it out :)

I'm glad you were pleasantly surprised. Feel free to hop on https://gitter.im/luckyframework/Lobby if you have any questions or comments!

From https://luckyframework.org/guides/installing/

  >To get Lucky, you need to install these first.
  >Install one of these process managers: Overmind (recommended), Heroku CLI (great if you plan to use Heroku to deploy), forego, or foreman.
  >Node. Requires at least v6
  >Yarn
  >Crystal. Requires at least v0.25
  >Postgres (macOS/Others)

Why are those dependencies needed, except Crystal, particularly Node? And does Lucky only work with Postgres?

You can use Lucky without a database, but if you use one, Postgres is the only support database.

You don't need node or yarn if you are using API mode. You can generate an API only app with `lucky init <app-name> --api`

The process manager is used to start the watcher process. You can use Lucky without it by running `lucky watch` instead of `lucky dev`, but using the process manager is nice because you can also run asset compilation, job queues and whatever other processes you app needs to run.

Lucky can be stripped down further still, but the documentation focuses on the more opinionated route

Thanks for the info.

Godspeed to the Crystal team. Third party library means everything.

Otherwise you end up with the same problem: "cool language...now I need to bind it to a C library to do this..."

Still betting on Rust and it's ecosystem.

IMO Crystal as a lot more mass-appeal than Rust, and once people realize that the interest might swing in that direction as pretty much anyone could pick up Crystal. Rust is an awesome, very cool language, but Rust code is super weird looking, and the backflips you have to do to deal with safety make even basic tasks sometimes extraordinarily difficult, or so I've heard.

"make even basic tasks sometimes extraordinarily difficult, or so I've heard"

That would be an understatement :-)

But it's a trade-off. You fight the borrow-checker to ensure safe code.

It's really subjective. Are you using a language for front-end/middle-tier service/back-end process, etc. etc.

Back in the day - you had a handful of people writing C code via CGI for web development.

Every good language addresses a problem.

Rust = safe code. Crystal = IMO...productivity.

Exactly. I wouldn't write a kernel or shared library in Crystal and I wouldn't write a webapp in Rust.

> wouldn't write a webapp in Rust

https://rocket.rs looks nice ;)

What other people subject themselves to is none of my business :)

And there is need for HTTP frameworks in Rust, for example embedded stuff often hosts HTTP servers. However, just like C we frameworks, it's my opinion they're not for the average use case.

Yes, and I can see HTTP frameworks in Rust useful for turning high-performance libraries into web services that can be used by other applications.

Yeah, that makes a lot of sense too. For example a database might want to provide a REST api for management, which would make sense to write in rust if the DB was written in rust.

Have you looked into iron/hyper? I’ve used them extensively and find them great and fast as hell.

I tried out Crystal and Kemal a few months ago and really enjoyed it. However, one issue that's preventing me from wanting to take it to production is that apparently you cannot generate fat binaries and run them without Crystal also being installed in your deployed environment.

Is that true still? If it is, does anyone know when support for "real" fat binaries (no need for Crystal on the server) will be available?

Do you mean statically linked binaries? Fat binaries generally refer to multiple ABIs in the same image, a mostly Apple thing these days.

I'm referring to fat binaries like the one Golang would compile too. Apologies if I have some terms mixed up here!

Golang produces one single binary you can deploy to your target environment and doesn't really require anything else installed.

From what I've read, Crystal generates a binary but you also need to ensure Crystal is installed on your target environment.

Golang makes statically linked binaries. (Well, until you use cgo.)

By default, Crystal generates dynamically linked binaries. You absolutely do not need Crystal to run them. But you do need:

- Boehm GC (libgc-threaded)

- libevent

- PCRE if the program uses regexps

- libyaml if the program uses yaml

- OpenSSL if the program uses crypto/TLS (?)

Here's an example ldd output:

    /usr/local/bin/shards:
            libyaml-0.so.2 => /usr/local/lib/libyaml-0.so.2 (0x8c0bb1e000)
            libpcre.so.1 => /usr/local/lib/libpcre.so.1 (0x8c0bd3c000)
            libm.so.5 => /lib/libm.so.5 (0x8c0bfb8000)
            libgc-threaded.so.1 => /usr/local/lib/libgc-threaded.so.1 (0x8c0c1e6000)
            libthr.so.3 => /lib/libthr.so.3 (0x8c0c444000)
            libevent-2.1.so.6 => /usr/local/lib/libevent-2.1.so.6 (0x8c0c66c000)
            libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8c0c8c3000)
            libc.so.7 => /lib/libc.so.7 (0x8c0cad2000)
            libdl.so.1 => /usr/lib/libdl.so.1 (0x8c0ce8f000)
            libcrypto.so.42 => /usr/local/lib/libcrypto.so (0x8c0d091000)

You can try `crystal build --static` though :)

Thanks for explaining! In other threads, I've seen people refer to them as fat binaries, but yes, I've also seen them referred to as statically linked binaries.

Not sure when/if this changed recently, but from:

https://crystal-lang.org/docs/using_the_compiler/ "Creating a standalone executable":

crystal build some_program.cr --release --static

Builds a static binary (just tried it on Ubuntu 18.04 with a simple hello-world).

You're going to have much better luck with an alpine-based docker image. Unfortunately non-musl based systems have a lot of issues with static compilation, so while this will work with hello world, if you try something more complicated you will likely get linker errors.

Particular to the c library? Because an "ldd" on the hello world listed quite a few libs which all worked fine with a static build.

openssl and libz are particularly fussy

I could definitely see openssl being tricky (libz not so much, but I might very well be naive here) - but how does changing the libc help with either?

glibc has some plugins which make it not easy to statically link. Musl doesn't have that. And alpine compiles openssl etc. with a config amenable to static linking. It's all about distro choices.

Thanks! These instructions seem to have less warnings than I saw last time, which implies it's more stable now.

You can use my alpine docker image to statically compile without any fuss: https://hub.docker.com/r/durosoft/crystal-alpine/

I'll be updating it later today with 0.25.1 support.

You can statically compile a local crystal file using a docker one-liner that is included in the description.

That's great! I've only heard complaints that it's difficult to statically compile. Sounds like a solved problem though.

The docker approach is I think a well kept secret but I'm trying to get more people to realize it's a thing. My gcf.cr tool abstracts this away for you if you are deploying to a Google Cloud Function

Crystal supports static linking with `--static`, unfortunately glibc and openssl don't like static linking, so it turns out to be easier to do in an alpine linux chroot/container/etc which uses musl instead of glibc. Crystal is in the alpine linux repositories as of 3.8, so this should be now a lot easier.

If someone wants to generate some good tooling around this workflow, it'd be greatly appreciated.

I wonder if it is possible to do something that staticly link everything except the few libraries that misbehave.

There isn't much else left to link - iirc openssl, glibc, libevent, libpcre are all it needs.

Only noticed this in the release post, but the `record` feature is neat: https://crystal-lang.org/api/0.25.1/toplevel.html#record(nam...

It's been around for a long time, but perhaps not documented.

The clever bit seems to be that, being a macro, it can accept an undefined constant as if it was an argument, and then define that constant. Neat.

Are compilation times still incredibly slow?

That was the deal breaker for me with crystal, toy project of maybe a few hundred lines of code taking 30+s to compile

edit: specifically a static release compile, with

    shards build --no-debug --release --link-flags "-static"

I’ve been using crystal for moderately sized personal projects for a few months now - I’ve never experienced any unreasonable compilation times. If you tried crystal a long time ago, I’d recommend giving it another shot!

The compiler takes about 30 seconds or a bit more to compile, and it has around 50000 lines of code. Do you have the few hundred lines that took you 30+s to compile?

Just dug out the code and tried again

It's 80 lines and depends on kemal, radix and kilt

`shards build --no-debug --release --link-flags "-static"` takes ~60s

I can't send the full code atm, but it basically just fetches json from an endpoint, stores it in memory, and returns it in a different format on an http endpoint

Oh, release builds do take longer.

My point of view is that while developing you don't need the `--release` flag, so you can get a more or less fluent experience. The few times where you need to release an app it takes longer, but for me that's acceptable.

I always like flipping on the release flag at then end of my work day. I treat it like a stopping point in my code, where I get to see how fast it is compared to the slow running debug executables I’d been working with all day. Great way to end a coding session.

I rarely notice the difference between release and debug executables unless i'm benchmarking or doing something super CPU heavy. I've so far deployed most of my crystal apps in debug mode because it makes the stack traces nicer because of the lack of aggressive inlining.

Our ~100k line web app takes 10-15 seconds to compile.

~100k LOC in Crystal? that's pretty amazing

about 60-70k of that is slang, CSS, and frontend javascript, but we're still looking at a large amount of pure crystal.

That’s a lot of slang (shard author here)! Happy to see people using it so much.

If your few hundred lines of code takes 30 seconds to compile, then either it's a crazy macro that expands to hundreds of thousands of lines of code, or I suggest you report it on github.

Anyone using Crystal in production? What do you use it for?

We use Crystal at RainforestQA to replace our heavy-load / slowish Ruby microservices. It's been great so far and we love it. We're also increasing the adoption to Crystal inside the organization.

Also Crystal has a dedicated a wiki page for production users

Used in production: https://github.com/crystal-lang/crystal/wiki/Used-in-product...

Interesting! I’m surprised you didn’t move to Elixir given the syntax similarities to Ruby

Elixir would probably not have been a huge improvement over Ruby if they switched languages for performance reasons. Elixir is great for many things, but raw number-crunching performance is not one of them.

While elixir's syntax is inspired by ruby, the semantics are vastly different. That change in semantics is really good for elixir, because it means it can take advantage of the unique properties of the erlang vm, but it's worth noting that crystal is far far closer to ruby than elixir. For better and for worse.

The syntax similarities between Elixir and Ruby stop as soon as one moves on from reading short blog post to writing real code. They are extremely different languages. Knowing Ruby helps only to remember the names of some standard library modules and functions, which were designed on purpose to match the name of the corresponding Ruby modules and methods, but not all of them. A vanilla example:

    $ iex
    > "1 2 3" |> String.split |> Enum.map(fn x -> String.to_integer(x) * 2 end)
    [2, 4, 6]

    $ irb
    > "1 2 3".split.map {|x| x.to_i * 2}
    [2, 4, 6]

which by the way highlights the extra verbosity of Elixir compared to Ruby. It's less verbose on more complex examples, mainly because of pattern matching, but the proof would be too long for this reply.

Kotlin syntax:

"1 2 3".split(' ').map { it.toInt() }

Your example doesn't do the same thing.

The same as grandparent, in crystal:

  "1 2 3".split.map &.to_i.*(2)

Whoops, you're right.

    "1 2 3".split(' ').map { it.toInt() * 2 }

I believe that Ruby also has that & shortcut (or similar) but it's totally unreadable. I never used it and I don't even want to check the exact syntax. Is it the only way it works in Crystal?

It being readable is a matter of getting used to it. I find it more readable than the block version as there is less syntactic boilerplate. YMMV.

Ruby has a similar version using colon instead of dot but that version isn't chainable and doesn't take arguments so it can't do the *2.

And no, you can write out the full block just as you did in the Ruby version.

I hear this a lot but I keep seeing more and more Ruby devs moving to it trivially and as someone who reads-not-writes Ruby code I find it just as trivial to grok it.

So I think the differences are there but they’re being overstated from a transfer of skills standpoint.

Differences don't necessarily make it hard to move to another language. Many developers moved from Java to Ruby between 2006 and 2010, including me, and Ruby is pretty different.

What drew you to Crystal?

If you'll forgive the snark, you've moved from one obscure language, to an even more obscure language that even fewer developers know.

What is it about Crystal that outweighs the very boring practical downsides of production use of obscure and immature languages?

I think many tens-of-thousands of developers would not agree that Ruby is obscure.

How is Ruby an obscure language...?

Their developers are already proficient in Ruby. Crystal is a very, very close cousin of Ruby, syntactically and structurally. This isn't like jumping from Java to Haskell.

I didn't know it was that similar. Neat idea for a language.

The 'Boo' language does the same for Python.

I'd say Nim is for Python what Crystal is for Ruby.

On closer inspection I agree - hadn't realised Boo uses the Common Language Infrastructure.

Probably because they loved the language. Humans are humans, and not everything is made with a rational financial decision. If you use the language, and like ruby and static typing, you'll find that there's a lot to love.

I see your point, but I sympathise with it less and less as time goes on. Programming languages are just tools. Software development should strive to be a proper, rational, engineering discipline.

Humans aren't robots, but one's choice of development tools is steered by real forces, both technical and business. I don't see that whim, unconstrained by such forces, has any place in the decision. Same goes for curiosity.

If it were my decision to choose a language to use in production, I'd want to go with a safe boring choice like Python/Java. Mature and stable on lots of platforms, easy to hire for, plenty of libraries and tooling.

Taking a risk is sometimes the right thing to do, but I don't see choice of programming language as being one of those times.

It's not that I don't like neat languages like Crystal - I really do - and I'm certainly not trying to put them down. I just wouldn't want to try to argue to management that using it is in the company's best interest.

It's always a tradeoff between having fun and accepted practice, and I'm glad for the brave souls who do use Crystal in production. After all, every mature language was once someone's toy, and you can never get from one to the other without many successive firsts.

I'm not here to recommend people use it in production, but I can understand the mindset of people who do.

> Software development should strive to be a proper, rational, engineering discipline.

Well, to use an analogy from civil engineering, I don't think choosing a programming language is always as critical as which type of concrete you choose and how it's reinforced. While it's true you wouldn't choose just any language, there is more room for preference here. Especially because you can switch languages for a project, but practically can't switch the material used in the foundation of a building.

> I just wouldn't want to try to argue to management that using it is in the company's best interest.

In some companies you don't need to argue with management about that decision. Also, a language being less popular or obscure doesn't mean you can't evaluate it's stability and feel comfortable enough with where it's at to use it. I'm glad people do because otherwise we wouldn't even see any language as popular as it is.

> you can switch languages for a project

What do you mean? If you're 100kloc in, you pay a considerable price in jumping ship. Rewriting means throwing out your investment. Interfacing two different languages for one project is rarely a good move.

> I'm glad people do because otherwise we wouldn't even see any language as popular as it is.

Sure, me too. Like I said, I do like new programming languages, I just don't see myself using one for serious work.

>Software development should strive to be a proper, rational, engineering discipline.

That will never happen. Or when it did it will be all mechanized, with machines doing the programming.

Even today, a tiny proportion of software development is actually done with a respectable engineering process.

It's not a myth, and I don't see that it should be dismissed as a pipe-dream to think that this sort of serious engineering approach could be adopted outside the critical-systems industry.

https://www.fastcompany.com/28121/they-write-right-stuff

In silicon valley and among most of the startup community, Ruby still dominates the landscape, even when compared with Node.js, Python, etc. There's plenty of talk of companies re-writing their infrastructure in node, but why would you do that when you can have Rails and/or Crystal? Furthermore, if you ever need something from NPM, you can just throw it in a Google Cloud Function or in Lambda.

https://medium.com/@yoelblum_45935/demand-for-ruby-on-rails-...

It's interesting that everyone's still using rails in silicon valley. Here in the UK, Laravel (PHP) and Django (python) are both more popular than Rails for new projects. But I hear that PHP isn't popular at all in the US?

PHP in the U.S., especially in the startup world, is seen as "oh, you develop in third world countries". That's the perception these days unfortunately.

That said, I was an avid PHP developer in the U.S. about 10-15 years ago and I always liked the language. There's just no one learning PHP anymore since all the kids just learn js, and no one trying out "hipster" languages like ruby/crystal/go/python/elixr/d/nim/rust/etc is going to try crusty old PHP.

I will say though that PHP, without any frameworks, is probably my favorite thing to develop a simple standalone site specifically because it lets you break all conventions and just output some damn content possibly with some simple logic involved and without using classes/mvc/etc.

>What is it about Crystal that outweighs the very boring practical downsides of production use of obscure and immature languages?

Tons of startups, and tons of billion dollar companies, run on Ruby / Rails. How is it "obscure"?

Crystal sure.

Then again, PG who created Hacker News used Common Lisp, which at the time had about the same developer pool as Crystal give or take (well, not really, but close enough, compared with industry favorite languages).

Let's make this more generic:

Anyone using Crystal? What do you use it for?

I'm specifically interested in production settings, not toy projects. Using something in production is much more interesting.

I do. I run a service called "HashCache" which caches resources by hash ( http://hashcache.rkeene.org/ ). I use this as a central cache for build scripts which download resources from the Internet, and the upstream/origin server may go away.

I wrote a version in Crystal (v0.10, I think) and Tcl to compare the two:

Crystal: https://chiselapp.com/user/rkeene/repository/hashcache/artif...

Tcl: https://chiselapp.com/user/rkeene/repository/hashcache/artif...

I am making a simple bloggy webapp with Crystal.

I'm not sure why anyone would actually use it in the current state, unstable, lack of libraries, lack of community and the biggest problem no multi-threading / windows support

You could basically say the same about any language. Just switch the descriptions. For example:

C#: verbose, magical dependency injection, Microsoft, etc.

Ruby: slow

Go: ugly syntax, verbose, if err != nil, etc.

If a language works for you I see no reason not to use it :-)

Ruby's getting much faster now with recent speed improvements, JIT and recent developments by the TruffleRuby team

For the thrill man! If it doesn't have a library you need you create it yourself. Eventually enough people who have the skill to contribute will become interested in Crystal and contribute a library, then one day crystal will replace java. In all seriousness, other than the multithreaded windows support, which libraries are missing?

For sure. I've had a lot of fun getting to be the person to create some basic libraries for things like image manipulation and an ORM for mongodb when I find no one else has done that yet.

One big thing that is missing still is full google cloud platform and AWS libraries. There is an s3 connector but I think it's out of date.

I know you’re (effectively) trolling here, but there are many reasons to “actually” use it. The community is great and helpful (check out the Gitter activity if you have any question about that). Lack of Windows support (for now) doesn’t matter if....you don’t use Windows. Multi-threading is being worked on.

You’re rehashing the same 2 things many folks point out that Crystal is missing in its pre-1.0 state and while they’re obviously important for widespread adoption, they’re not reason in and of themselves to dismiss a language that’s otherwise super interesting to many.

I'm actually not trolling, I'm 100% serious, there is no reason to use that language right now when you have others languages that are better on every aspect. Maybe Crystal will be ready at some point but right now it's not.

I don't think any language feels as close as crystal does to dynamic languages while being completely type safe with strong types. I think thats why so many people choose to use it so early. It truly doesn't feel like any other language out there.

Ruby is pretty useless on Windows too to be fair.

Good luck trying to compile native libraries.

We use it in production. The web framework side of crystal is IMO more mature than what you find in Node.js, Python, etc. About a year ago we tried moving everything to Express because it's super easy to find fledgling js developers, but Express simply lacked most of the features we needed, even when supplemented by npm, whereas Amber did everything we needed literally out of the box.

Edit: Sails is not what it claims to be, and doesn't live up to the dream at all

> Sails.js is probably the closest thing to sane in the JS web framework ecosystem

Whoa, that's where you lost me. Sails has a reputation for being horrible, and after working on a production app using Sails, I agree. Perhaps you were wanting something like Rails but in JS, which is what Sails claims to be, but it barely lives up to that. I don't know if there are other frameworks that try to be the Rails of JS but it wouldn't be hard to better than Sails. I'm interested in hearing why you think it's so sane (no snark, I'm sincerely curious)

I'm going to retract my statement about Sails. I had a lot of trouble with it when I went to use it, but I thought it was just me. It seems it really is crappy as well.

Why’s that?

Why would those who do use and are happy with it, judging from the responses here, not use it?

I'm planning on trying it to replace some Ruby code that updates our elasticsearch index in a background job. It's currently slow and memory hungry and crystal's similarity to Ruby should make it easy to port.

At BlockVue we use crystal for v2 of most of our core infrastructure (the old version of our app is Rails-based), and we also use crystal heavily in Google Cloud Functions via our gcf.cr (open source) tool. So mainly we use amber and gcf.cr in conjunction with one another. We host everything on Google App Engine and GCP.

We're currently using Crystal 0.25.1 with the Kemal web framework to provide an online paycheck calculator for US based employees (it's basically a demo/tool for our SaaS based accounting, payroll and fund raising app).

Really impressed with the language so far and hope to expand its use within our organization.

I'm the creator of Kemal, glad to see that you're liking it :)

Crystal is a nice language that just keep getting better.

Think about 10 years ago, we never think of a small company,community be able to writing a programming language. Nowsaday Crystal/Elixir/Nim prove what we can without huge financel support from huge company.

Crystal pick Ruby syntax, which is very elegant to me and I'm happy to have that option available and appreciate that.

> Think about 10 years ago, we never think of a small company,community be able to writing a programming language.

Perl, python, ruby ?

Any recommendations on an editor for crystal? I was unable to get the VSCode extension to work properly.

Atom behaves pretty well with it. What problems are you having with VSCode? That's what I use.

Won't the impending releases of TruffleRuby, Graal and Substrate VM make Crystal irrelevant?

That's about speed (though I think Truffle/Graal make an app consume more memory). Crystal is type-safe, and no optimizing VM can do that for Ruby.

Not that type-safety is a killer feature, but that's just one difference.

https://medium.com/byteconf/stripe-is-building-a-ruby-typech...

Stripe are trying to solve that issue.

That's still not the same as a compile time type-checker, it still relies on the interpreter.

Other than being a statically typed language: Crystal AOT compiles down to native code (so, good FFI) and has a much better portability story (you can port it to ~any LLVM target).

All that Graal stuff, while a true open source project, has some "Oracle weirdness" around it (IIRC, only Linux (and probably only amd64) is supported in the "community edition") and requires JDK 9/10 (not available on FreeBSD yet..)

Some people (myself included) actually want the type safety and method overloading etc. Also you can only make a dynamic language so fast before there are inherent trade-offs.

I gave up on crystal and realized I should've started with rust in the first place.

Crystal wants very badly to displace ruby, in order to leverage the network of developers and generate more and more attention. It's a smart decision on their part.

As such, crystal doesn't seem to have munch interest in low-level nitty gritty. "we aren't trying to be C" is a common comment amongst contributors.

For game dev, (why I'm bothering with rust) it's too big a turn off to ignore.

For web dev, I suspect crystal will ultimately find some success. Lucky framework has some REALLY cool features that rails hackers are going to discover eventually.

Unless ruby 3 drops a type system bomb and finds a 10x perf speedup, the continuing progress crystal is making will consume the ruby ecosystem.

Congrats on another successful release! Still no exhausting matched, no parallelism, and the spectre of type system changes in the future still looms, but aside from those things, looking good!

And windows support. But I personally don't mind windows support being missing. Fuck 'em. Continuing to settle for windows with alternative implementations and things like Wine only gives windows more power as an antihero. Let them be forced to adopt a Linux kernel, no compromise.

Edits: typos

Exhaustive matching is on the cards, parallelism is coming, and any type system changes in the future will be minimal.

And yes, crystal isn't trying to be C, but you can still do many of the low-level things that you can do in C. It'd be nice to know what exactly you were missing from Crystal.

It's not the lack of features it's just the difference in what it's meant for. Crystal has a GC, it doesn't have a lot of memory control, etc. She just ain't that type of lady.

Crystal isn't what I thought it was. That's not a bad thing necessarily, it's certainly nobody's fault....

For what I have in mind, rust fits my needs much more closely. I want to write a game and learn all about graphics wizardry and rendering pipelines and all the cool Carmackian arts I've been missing out on. My career is winding down, but I think I will retain my gray matter longer if I keep myself busy.

If I were thirty years younger and starting out a career in web development, crystal would excite me. The prospect of all that ruby out there that will eventually need to be crystallized... Man, what an opportunity.

I don't really have a specific idea in my head of what a crystal for systems development would look like so I'm not sure that I could really provide what's missing from crystal.

Rust is made for systems from the start and there appears to be a large number of really smart low-level hackers on the scene already. I'm glad, because I don't know, so at least I can fail amongst a crowd.

The second windows support is ready I'm going to start poking around with crystal for game dev stuff, cross platform UI, desktop apps, electron replacement, among other things.

I'll still love you even though you're a windows heathen.

Actually, let me ask you something... Are you just targeting windows or are you a windows user also? I can't imagine writing non-dotnet code with windows, but maybe I'm doing it all wrong.

I target it. My daily driver is Antergos or Ubuntu depending on how I'm feeling and how crappy GNOME is on any given year.

Nice. I browse with gallium on a Chromebook but I have a desktop at home with elementary. A little fancy but tolerable.

Still not quite the Year of the Linux Desktop... Any year now....

The chromebook thing is fun and I've tried it with a chroot. I've been addicted to IBM/Lenovo trackpoints / little red dot thing since 2004, however, so I'll probably never get away from using ThinkPads. As a kid I played counterstrike and halo 1 with a trackpoint. That's one thing motivating my upcoming purchase of https://www.amazon.com/LANRUO-Pocket-Aluminum-Windows-x7-Z87...

Any Julia programmers who have tried Crystal? I've never quite seen the point with Crystal when you got something like Julia. Although I guess there is a value in familiarity.

I was a big fan of Ruby back in the day, but I just feel that our understanding of what makes good language design has evolved since then. The heavy OOP focus in Ruby seems very 90s in retrospect.

I don't think it makes sense to restrict dispatch on single objects. Real world problems often don't fit that paradigm.

Crystal has OOP features, but you don't have to use them if you don't want to. I do some scientific research in crystal and it is all modules with functions calling other functions and dealing with structs. I love the fact that I can create C-style structs with member methods in Crystal.

On the language level, Julia isn't statically typed, and it doesn't have ruby syntax.

On a tooling level, binaries are easier to deploy than the whole julia JIT and your whole source code.

And crystal has dynamic multiple dispatch. It's used a lot, it's great.

Reply on news.ycombinator.com