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.
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:
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.
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?
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.
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 :)
According to Tiobe 2022, Crystal is between #51 and #100, unfortunately no precise numbers and no comparison with 2021
The following list of languages denotes #51 to #100. Since the differences are relatively small, the programming languages are only listed (in alphabetical order).
ABC, ActionScript, Alice, Apex, APL, AutoLISP, Awk, B4X, C shell, CL (OS/400), CLIPS, Clojure, Common Lisp, Crystal, Elixir, Emacs Lisp, Forth, Hack, Icon, Io, J#, JScript, Korn shell, Ladder Logic, LPC, Modula-2, MQL5, MUMPS, NATURAL, Occam, OpenCL, OpenEdge ABL, PL/I, Q, Racket, Raku, Ring, RPG, S, Smalltalk, Solidity, SPARK, Stata, Tcl, VBScript, Verilog, VHDL, WebAssembly, X++, Xojo
Honestly I’ll just say it, slow development is a huge factor but there are a lot of reasons people aren’t sticking around. Windows still hasn’t been fully supported since 6 years ago when it was talked about at the code camp. This is a huge issue, and while I know development on Windows is rough it’s still a big issue that concurrency isn’t fully supported still. I would have rather seen WASM support over what we have now with Windows. Macros were a neat compromise but honestly they are unreadable in practice. I’d really like the see something closer to Crystal replace it (maybe now that we have crystal i there is a future for fixing macros.) Macros also have weird limitations that are not immediately apparent, like for example lib not only doesn’t generate documentation but also can’t have it’s methods enumerated by a macro except when in the body of a function. This is a huge pain as a C binding author because name changes and structs inside lib cannot be easily documented or wrapped without a massive amount of work. IMO we should be doing everything we can to keep C binding writers happy and working on new things, not spending hours wrapping functions to generate basic docs. The more popular C libraries we bind the better it is for all of us, but that doesn’t happen when dealing with changes in the binding can be a huge PITA. We need to get people binding huge things like Vulkan, and no one will do it or even be able to maintain it when changes get made to the main library. The last time any one even touched the Vulkan bindings for Crystal was like 4 years ago.
Another big issue is the lack of support for IDE. VSCode works acceptably, but quickly falls apart when Crystalline is introduced as an LSP as well as when using any sort of code completion or suggestion. It’ll work for a bit crash, make mistakes, etc. Working on my Linux machine I get about 1 error/LSP crash every 5 minutes, Windows I never got the LSP working. This is something that should be a part of the Crystal core development process. We should have a complete package for VSCode that works well and doesn’t bombard the user with crashes and errors. This should be tested and released along side every major Crystal update. We especially need this functional for Windows.
I’m still going to be here regardless, nothing I mentioned is a deal breaker for me, but it will be a deal breaker for other people, specifically people with much less time than I do and might be talented enough to get some real things done. I love Crystal and I have a near infinite amount of time to spend writing bindings, but I also see it doesn’t have to be exactly that hard. I have a mountain of respect for the devs, they basically do it for free, but the programming community notices when all these other languages have all this stuff down by now in their 6th year but, we are still trailing what seems very far behind. The response from other devs I mention Crystal to starts with interest when talking about C speeds and no centralized package hub but quickly falls off when I mention that we have sparse tooling, Windows support is a little shaky, macros can make an unreadable mess of code that should otherwise have been much more straight forward and they have weird inconsistencies that can make them hard to use/understand. IDE support being wonked is a huge deal breaker for a lot of devs and is the biggest point of issue for me personally, even though I have learned to work without it.
I’m not sure if any of these can really be solved either, seeing that the devs only have so much time and money to work on Crystal and they are already using those resources to the best of their ability.
@recodefinal Thank you for the thorough feedback!
If I understand it correct, here are the three main point points you have or others might be having:
My thoughts: