Why people leaving crystal?

I’d argue being able to install a shard via your OS’s native package manager is better than each language having their own. Improving the tooling around this would be more useful IMO than spending the effort to create an actual Crystal package manager.

This is one of the main issues as Crystal doesn’t have a central package repository. Maybe that’ll change in the future, but I don’t see it happening anytime soon.


I would say that from a normal user’s point of view (non-developer) you are right, but for developers, everyone likes the tools provided by their language can do everything.

There is an easy way to distribute tools written in Crystal in the form of Ruby Gem. It is easy to specify binaries for each platform or to have them compiled at installation time. However, this may be bad manners, and the administrators of RubyGems.org may not be pleased.

I don’t see why that would be better than just building binaries via CI and allow people to download it. Why involve Ruby at all?

oq/deployment.yml at master · Blacksmoke16/oq · GitHub Is another example of how to handle it. When a release is created, build/upload a static binary to GH release, update homebrew formula, build and publish new snap binary. I then follow that up and update AUR packages. I imagine handling other package managers like .deb and such would be doable as well if so desired.

I’ll mention again, having docs/tooling around this would, IMO, be more impactful than spending the effort and time developing a Crystal package manager.


This is because it is difficult to provide a uniform installation/uninstallation method across platforms. Having a package for each platform is ideal but a painstaking task. Moreover, even if you do that, there will still be platforms that are not supported…

That’s where the pre-built binaries come into play. You really only need one per architecture. E.g. Linux x86_64, aarch64, and windows. If those are available, then the user could just download them and start using it. Distribution via package managers would be the next step on top of that to handle updates more easily.

Snap kinda handles this, but less than ideal to require people to install that just to install your project. Tooling/docs on how to build to each package manager could be a way to make that easier. Tho really the main challenge that I’m not super familiar with is getting your shard included in the package manager themselves, officially at least. I.e. so that you could do apt install oq and not have to add your own repo, or tap in the case of homebrew.

1 Like

There are a certain number of Raspberry Pi users. However, it seemed hard to provide pre-built binaries for them in GitHub Actions. Of course this would not be a problem for my personal tool. But I think providing pre-built binaries for everyone is not as easy as it first seems.

Just curious, does anyone (developer) actually use a package manager like apt for development envs?

the key point is:

  1. we don’t want install those tools into /usr, you know, you know, file permission issues.
  2. system package manager versions are usually older, sometimes, because system dependency, update is not possible.
  3. developer don’t like change the install process when change the OS (e.g. linux distro, debian even use different name with redhat)

so, AFAIK, developer love install those tools into some folder in $HOME, e.g. install ruby and gems ~/.rvm use RVM, install into ~/.cargo/registry when use cargo, install into ~/go/pkg when use golang.

Crystal developer only care about things regarding to Crystal, they don’t want to spent time to learn package manager, even, one more time for a new platform.

1 Like

I’m a Crystal developer. And I do not only care about software written in Crystal. I use a lot of software written in all kinds of programming languages. Event together with Crystal.

And frankly I don’t think it’s a good idea that I should install a tool chain for any programming language first in order to be able to “easily” install software written in that language. That doesn’t make any sense. I just want to use the software. I shouldn’t have to build it myself (and install whatever dev tools are necessary for even being able to do that).

If you want software to be used easily, it should be provided as binaries for direct download and/or via established package management systems which many people already use.


I think it only makes sense if the tools provided by the language are for the language. Like, it would be nice to easily install ameba with a single command line, using shards or crystal.

But for general tools, I agree, it doesn’t make any sense.

I use a Mac. If I want a tool I check if it’s in homebrew, which is the most used software manager for Mac. I would be pretty annoying to have to install cargo just to install another software. Like, I don’t develop Rust at all, why do you make me install it?

1 Like

I usually prefer this method, actually, but I also know it’s not the usual way of doing things. But I prefer it because of the type of software I write (Linux command line programs, or occasionally a Linux daemon). It just makes it a bit easier if I ensure things work with (somewhat) older versions because that’s what the end user will have from their system package manager.

But it also depends on the language, and this isn’t much of an issue with Crystal, especially when I avoid using any sort of bindings.

It also depends on how I expect the end-user to receive my program (either AppImage, from a system package, or from a community from-source thing like SlackBuilds). For an AppImage, I just make sure it works with older distros so I can build a good image. For from-source things like SlackBuilds and AUR, I want to make sure the user can rely on the versions in the package repositories and not worry about installing things manually.

EDIT: I forgot to mention, I like Shards specifically because it occupies a sweet spot between a build system, a way to specify and build dependencies at build time, and a full package manager. No central set of packages somewhere in my home directory is nice, just a cache.


If Ruby were a compiled language it probably wouldn’t need gem as a distribution channel for general-purpose applications; it is less a feature of the package manager and more a consequence of those applications requiring an interpreter. Same goes for pip and npm.


Well, I use asdf for dev tools, and it’s a package manager.
If you are talking about package managers like apt, yum and nix, then yes, I do use those as well for interpreted languages like ruby to ensure dependencies are the same version as the targeted systems, it just makes it much easier if you are developing for servers.

I’ll second the notion that we don’t need a package manager. We got shards for dev dependencies, and github for hosting those. I rarely visit npmjs.com or packagist.org to find a library, but google my need.

Certainly, we don’t need a package manager to distribute applications. Better use the time to polish some github actions that can build for different platform/package managers.


On the other hand, it is not exactly very uncommon for Rust programs to be distributed primarily using cargo install. I’d say language specific installation method is what happens before a program ends up popular enough for people to package it to a generic service. So I don’t think it really is an either-or kind of thing. Both ways can have its place.


For me, the package manager is part of the OS fundamental knowledge we have to catch early.

My tooling or any end-user stuff comes by the OS package manager 1st (apt or brew).

Programming / tech tooling, especially for my language or designed to be gently hacked, is fetched by the language’s package manager.

The Ruby “gem” tool is great for compiling native libraries, but I’ve had bad times with missing header files or just the correct ext. library. Sometimes I can “apt get” easily. Sometimes it’s a game of hunting in the corners of the internet.

Install from source is not the greatest experience if the user has no clue nor interest with the technology behind.

1 Like

I miss the point of this thread.

I’m not sure people are leaving Crystal. I think the interest in Ruby is declining since years. By leverage, it also reduces the people who can naturally turn to Crystal.

Because other share their wish list for Crystal :) I share too the mine.

I prefer that the Crystal team take their time to experiment and carefully design the technology. I am thinking of Erlang VM which is amazing. It took time too.

I don’t hope Crystal to become a trending language because I found myself lost when it was the case for Ruby.

Okay, wish-list time:

1/ I think Windows is really something to have. I see lot of junior developers who use their own computer for games, studies and programming.

2/ For me, a good concurrency model is a way better than multi-core / parallelism support for 1.x version.

I see issues open for this and Elixir / Erlang was mentioned. Beam-VM, at its heart, is really close to the CSP model of Go. The major difference is each job (the “process”) has a queue attached (a mailbox). In the Go language, we can say it is like a default “channel” for each go-routine :)

Genserver and all other strategies are more related to OTP than Erlang itself. It’s a higher level layer.

Thanks for reading. I’ve finished.

Take your time, dear Crystal team, we are patient :)