Biason::Julio::new(); @juliobiason@functional.cafe

Anyway, here's some Wonderwall...

I do have the feeling that this would "give freedom to libraries, but not to your executables" is just to avoid contributing to projects to adjust their dependencies -- mostly 'cause doing a release takes time and "everything is for yesterday".

But, if "another_library" and "big_library" require different versions of "small_library"... Wouldn't that be the case of contacting both authors and pointing there is a new version of "small_library"?

I mean, heck, if it is open source, you could contact the author of the smaller version and give a PR with the new version and all...

(obviously, this works 'cause Cargo -- and other tools -- make static binaries instead of dynamic ones.)

... and I think dependency tools can't do that 'cause they can't find a way to have two different versions of "small_library" in a single package.

... which cargo solves by using "name mangling", meaning it would change the name of the functions in one library, so both versions exists, but with different name.

I suppose they suggest this 'cause if there is "another_library" that also requires "small_library", if "big_library" and "another_library" required different versions of "small_library", the dependency tool would point that it cannot find the proper version to use.

... which seems a problem with the dependency tool than library versions, IMHO.

A library bit like this:

• "big_library" has a dependency on "small_library".
• The recommended thing is that "big_library" 0.9 has a non-version-pinned dependency on "small_library".
• On your executable, you'll point that you need a pinned-version of "big_library" 0.9 and the dependency tool will pin whatever version "small_library" is used.

But, if "big_library" had a pinned-version-dependency on "small_library" (say, version 1.0), then I only would need to care about my direct dependency, not everything else.

But (and here is were I'm confused) if libraries pin their dependencies, I only need to pin the direct dependencies of my project, not dependencies of my dependencies.

I mean, most of the dependency management (and reproducible builds) say that you should pin the dependencies versions on your executable, but not on libraries.

(The Cargo Book says exactly that.)

I have to be honest in another point, too: I never got the "proper" dependency management idea.

Ok, honestly, there is a point there, but I'm just pissed with that person for saying, once, that he didn't "believe health care should be public" 'cause that way nobody would "explore" the market.

Pro tip: If you need an article on the internet to explain your thinking, you're not thinking.

Also, "down talking" by showing an article on the internet that explains something.

Oh, nice.

The guy never shows up to help people, and only appears to say "Thank you" when someone mentions his course, decided to appear to down talk me for explaining dependencies.

Bought a Book HumbleBundle about mediation and stuff, but now I'm wondering if listening to music is my meditation/zen stuff...

I mean, cool that they get more, but it sucks that new releases are available only on a specific day.

I do like Bandcamp Fridays for what it does, but you can clearly see that on those Fridays there is a deluge of new releases, which give the feeling that most artists were holding their new productions only to match with that Friday.

Related: I finally sat down after a long time and wrote some more Rust code.

One of the weird things about Rust:

You write code. When the compiler stops complaining, the thing works.

Then you look at the code and think "Ok, now I know a bit more about Rust and the way I wrote that before is not the way people write Rust code."

So you refactor the code. When the compiler stops complaining, the thing works and you code looks smaller, simpler and more readable.