why crystal choose shards? I’m confused,
isn’t ruby’s bunder’s syntax more simple?
In ruby there’s configuration as code paradime,
then when you come to a new project,
you don’t need to learn a new configuration language.
What’s the reason to choose shards over bundler?
Maybe because crystal is static and can’t implement bundler?
Is there any existing design discussion to this?
Also if the reason is only because crystal is static and can't implement bundler,
then perhaps the discussion of bytecode can help a little bit?
I’m sure there are more reasons than that, but that’s what it comes down to. It’s no newer than having to learn how a cargo file works when learning Rust, or composer for PHP. As I mentioned yesterday in gitter, you can’t just expect someone to come from Ruby and be a Crystal expert now just because it looks similar.
Crystal is not trying to be compatible with Ruby. All of these recent proposals about bytecode, or changing things because Ruby has or does not have it is not really productive IMO. Now don’t get me wrong, I’m not saying proposing things is bad, nor new points of view. But coming in with the attitude that Crystal is in the wrong because Ruby has or can do something is the wrong point of view to have in the first place.
I like Ruby and Crystal.
But I never wondered about the difference between shards and bundler.
Perhaps the biggest difference is whether or not there is an organization to run the Gem server, that is, the difference in services offered rather than the difference in languages. Since it takes a lot of money to provide a sustainable service and the Crystal team is small, taking advantage of free GitHub hosting is a reasonable choice.
You can find a lot of the history in these issues:
TL;DR: There was a general understanding that the Crystal ecosystem needs a dependency manager, and the community discussed basic features. Then @ysbaddaden implemented shards and everyone liked it, so it be came part of the ecosystem.
Because “configuration as code” would be painful in Crystal: we’d have to compile, link and run an executable just to get the configuration back in some form, or worse compile shards with the shard configuration every time… but we don’t have one shard, we have a whole tree of them, and we must select a version which means we’d have to compile & execute the configuration for each version of a dependency that we consider…
Today with the interpreter we might be able to consider “configuration as code” (though the interpreter is still slow, especially startup time, and it still needs to compile) but back in 2015, that was never considered.
I would personally avoid going the configuration as code route, as this is one of the biggest drawbacks of cross-platform lockfiles for Bundler.
For example, if your Gemfile contains condition blocks (if and such), the generated lockfile will be dependent on the platform that generated it, which might break others attempting to run the project in order similar or different platform.
I would say I love the simplicity of a YAML file, can be easily serialized and the lockfile it generates matches what I defined.
Why not something like Gemfile? Because it’s a bad idea to turn your dependencies into its own little program. Infrastructure as code is all the rage, but that means bucketloads of YAML files, not a 2000 line bash script that knows how to download the DigitalOcean client.
What’s the reason to choose shards over bundler?
With shards you have a file that specifies your dependencies. With bundler you have a Ruby script that might either install some dependencies you might not be able to figure out how it arrived at, or maybe install a crypto miner.
Anyone who’s fought with configure scripts and autoconf in order to try and install some app back in the day knows the pain of trying to figure out what went wrong.
A simple file that simply specifies what’s needed and where to get it is much preferred.
