Follow

seems to have grown an individualist community, with all its tiny packages hosted in a non-curated repo, with its rejection of copyleft, and with its disregard of “community standards” developed by distro folks over the years.

I feel that introducing Rust right into once collectively-developed code bases at the core of GNU/Linux will have unpredictable and detrimental effects.

Before someone shouts “memory safety!” I should add that, yes, I’m all for replacing C with a memory-safe language. It’s the collaborative aspect that I’m concerned about.

@civodul I think I don't share all of your sentiments but I do have concerns about the crypto-crowd hitting Rust as a community, partly via Haskell and directly. Years ago the Rust community was an exceptionally friendly and welcoming place. But this is deteriorating.

@civodul

this saddens me

I have a bond with the Gnome desktop and community 😕

@civodul I share your sentiment WRT. individualism. Abeit it'd be tempted to say it's not a Rust-specific issue but shared among most "modern" tech stacks.

Cynical me would say it has to do with the intersection between capitalism and open source, pushing people to self promote their work as much as possible to advance their professional career. (To be clear: I'm personally guilty of doing that to some extent).

I'm not only answering to rant though :)

The recent Nix social-related issues made me dig quite a bit into free software community management best practices and think more about how to facilitate collaboration (and not competition) between the community members.

> #FreeSoftware “community standards” developed by distro folks over the years.

Could you expand a bit on that? Are you talking about technical standards or social standards here?

If you're talking about social standards, could you point me to some resources, I'd like to read more about it.

@Ninjatrappeur Agreed, individualism is not limited to Rust.

By “community standards”, I meant that, even though projects differ sometimes significantly in their world view, I believe each project, from KDE to GCC, knew that it’s part of a broader collective and cooperates to a large extent. Distros are like the technical incarnation of that broader collective.

@Ninjatrappeur @civodul Individualism is deeply rooted in western culture and psychology, for better or worse. I can highly recommend both of Joseph Henrich's books, if you're interested in taking a step back and learn about cultural evolution.

Back on topic, platforms exploiting individualism (github, stackoverflow) are the ones that won the cultural selection. Earlier coding platforms were more project-centric. With SVN you had to ask (or become) a project member to write a commit message.

@maxy Aha, I did not know this author.

I assume you're mostly reffering to "Why Humans Cooperate: A Cultural and Evolutionary Explanation", should I start with that?

@Ninjatrappeur Or maybe I'm just ignorant what else he wrote. My first recommendation would be "The Secret of Our Success", which is two steps back about how cultural evolution works and how it emerged and co-evolved with biological evolution. It's about human nature.

The follow-up book ("The WEIRDest People in the World") is trying to explain how today's cultural differences have emerged. (And what those differences are, like religions, marriage norms, markets, public clocks, etc.).

@maxy Perfect, both of them are available on the Trantor Imperial Library.

@maxy @Ninjatrappeur @civodul

hamishcampbell.com/2020/12/04/ We core crew need to learn how to become benign older folks who answer every “better” solution put forward by the thrusting young with “how does that work with the #4opens” then fallow up with “lets look to see if that furthers the PGA hallmarks” to all their enthusiastic “youth” energy for “change”. Keep it gentle and most importantly keep the focus…

@Ninjatrappeur What are the recent Nix social-related issues? I'm out of touch with everything.

Or is this related to the Flakes and RFC discussions? I saw at least some post about that.

@civodul

@civodul I think I share those sentiments. I have seen similar sentiments in the majority of Haskell community too (thought I don't want to generalize them as copyleft-unfriendly). Individualist community, yes.

@vu3rdd @civodul

Hadn't heard that about the Haskell community, I'd have expected them to be more community oriented since they come from a science background.

I think part of the issue with software like Rust is that it's based around technical superiority as the ultimate goal, and "open source" is merely seen as the better way to achieve technical superiority.

@taylan @civodul I have seen prolific contributors like Ed Kmett speaking against using copyleft licenses in favour of BSD-like licenses.

Also `stack new' without any commandline switches create default package template files with BSD3 license. (One example of someone who raised this issue - github.com/commercialhaskell/s)

@vu3rdd @taylan @civodul This will be preaching to choir, but I don't think you should be allowed to call a libre license cancerous when you work for companies that prioritize growth above everything else.

Just a thought.

@csepp Good point! I also came up with something which I'm actually sure others came up with before:

If the GPL is a cancer, then BSD-like licenses are a tumor.

So how can one use the BSD3 license yet call the GPL cancerous? Unless they're exploiting the license to dupe people into doing free work for them?

He probably just used such inflammatory language because he fell for anti-GPL memes, but that's the conclusion I reach when I think about the statement logically.

@vu3rdd @civodul

@civodul i agree, they don't seem to care or understand the free software movement, one step forward, two backwards.

@civodul Thanks for voicing these concerns. I also really like the language but if I look at the list of dependencies that rust projects pull in, I really start to worry. What I saw reminded me more of the hundreds of dependencies of node.js (with all its negative effects) rather than the few dependencies of fundamental GNU/Linux building blocks.

A while ago I tried to use the guix crate importer but - likely because I do not understand the process - quickly gave up because of this.

@civodul @csepp Packages say what licences they use in the crate manifest. Restricting your project to copyleft packages should be trivial.

@faun @civodul In practice they seem to avoid strong copyleft:
okturing.com/src/12717/body
(caveat: this counts different version of the same package as separate packages)

@civodul copyleft snobbery has no place in free software. public domain is free software too.

@sneak I think this is less about copyleft snobbery and more about concerns regarding anti-copyleft snobbery.

It's one thing to choose non-copyleft licenses for some projects after various considerations. (There's the LGPL to cover those use-cases, but maybe license simplicity is a criteria too for someone.)

But if a group systematically avoids copyleft licenses, that tells us something about their worldview.

@civodul

@taylan @civodul yes copyleft is a cancer pushed by anticapitalists

@civodul I don't know much about rust or Linux, so I'm curious:

- what programming languages have packages in a *curated* repo?
- how does the rust community reject copyleft?
- what distro community standards do you mean?

@CodingItWrong I don’t know of any language-specific curated repo: they all seem to favor rapid growth and developer-friendliness over user-friendliness. Traditional free distros are curated, though.

Non-copyleft licenses are the norm in Rust. Nothing prevents you from choosing a copyleft license, but making that choice “excludes” you from the Rust community and there’s a strong incentive to follow the norm (e.g., see how Sequoia recently dropped its weak copyleft license.)

@civodul how does choosing a copyleft license exclude you from the rust community?

@CodingItWrong It excludes you in the sense that other Rust developers will say they “can’t” use your code because it has the “wrong” license.

It’s just social pressure, nobody is formally excluding anyone of course.

@civodul This is an interesting take. I am curious to hear your perspective more. My perspective watching the Rust community and now starting to get involved myself is the opposite. The non-curated code repository makes it way easier to collaborate on shared code across projects. Also, it helps a lot that the standard library is decent, unlike C++'s awful standard library.

@civodul Ardour, Mixxx, and Tenacity, which are all written in C++ and share lots of dependencies. But they all have tons of their own code which hypothetically should be able to be shared between them pretty easily, but isn't. Why? In large part because tasks as simple and commonplace as reading files and spawning a new thread are hard to do in a cross platform way in C++. I wouldn't want to do these simple things without Qt in C++.

@civodul So, because Ardour and Tenacity don't use Qt, they can't make use of the code in Mixxx that reads audio files from storage in a realtime safe way. Compared to my current experience starting to work on a new audio application in Rust, people working on different projects with different goals have already written libraries for this nontrivial foundational task, and it already works well.

@civodul Also, I am really impressed with the way the Rust language is collaboratively developed at scale and continuously evolving without breaking old code.

@civodul My answer to the lack of copyleft in the Rust ecosystem is to write copyleft Rust code. 😃

@be @civodul Indeed, this I do love. I can still set a project to edition 2015 or 2018, and still compile old code compatibly, much like C/C++ compilers where you can use -std=... Golang, by contrast, is a "latest tip" language, has frequent releases, and only supports the last 2 major versions.

@tychosoft @civodul lol that's what happens when using something made by Google for essential infrastructure of your project

@tychosoft @civodul and people advise me to use Flutter for the GUI of a Rust application 🙄

@be @civodul yes, that is the one major downside of go. Though maybe google got a taste of their own medicine. Go uses the repository name as part of the import paths for the entire ecosystem. They could of course have hosted it on code, but they got rid of that. So they chose github. They are now very stuck there ;).

@tychosoft @civodul I'm not that familiar with Go so I don't quite understand the implications of what you're saying about using the repository name as part of the import paths.

@be @civodul consider this:

import "github.com/spf13/pflag"

its a library, like a rust package. It is animated directly from git, using github. In fact, if you move it elsewhere, everyone who has imported it off this git repo would immediately become broken. The entire go ecosystem is built this way importing modules and code from direct git repo references.

@tychosoft @civodul lol what a terrible idea to couple the symbol names in the code to where the code is located

@tychosoft @civodul does any other language do this stupid thing? Not as far as I know. You import a library from the code file, but it's up to external tooling to figure out where that code comes from

@tychosoft @civodul rustc and Cargo work closely together, but they're not the same thing

@be
... probably still better than certain other "modern" languages, which use a centralized package manager instead and only allow fur some services (this system is at least universal Git).

But that's probably the reason why so many Go apps vendor all their dependencies.
@tychosoft @civodul

@codeberg @be @civodul there are several reasons why vendoring is used. Reproducible builds, something google fought for years against, is one. They wanted everything to always use the tip of main/master at build time. Since go compiles so fast, vendoring is not much overhead. Also vendoring allows builds to happen in fully network isolated environments.

@tychosoft @codeberg @civodul So the solution to reproducible builds in Go isn't something like Cargo.lock that specifies precise versions of all dependencies with checksums, but literally copying and pasting the entire dependency graph of everything into every package? LMAO

@be @codeberg @civodul well, after many long years of google fighting it's community, they eventually grudgingly did introduce a kind of poor modules system, in I think go 1.13 or .14, which essentially does this, but not much else.

@tychosoft @codeberg @civodul Go sounds like an even worse shitshow than the Node ecosystem.

@be @codeberg @civodul while crates have toml that specifies the version of your code, go does not. The go module system relies on git tags to specify versions of this otherwise versionless code. This goes back to google wanting everyone to always build from tip, so the version of your code wasn't an important concept in their minds.

@be @codeberg @civodul This is why I always use a simple makefile in my go packages, in which I kinda emulates essential cargo behaviors, and gives me a place to specify an explicit package version and other meta information.

@tychosoft @codeberg @civodul I remember ~5 years ago, it seemed like either Go or Rust could become the Next Big Thing. I understand why that's Rust now.

@be @codeberg @civodul the language itself is nice, simple, and very consistent. You also don't have to template just to access an arbitrary object of a given trait; you can use a trait as a function parameter directly. There is no disjunctive alternate syntax for templates, macros, and decorators, or just strange syntax such as selective exclusion of ;'s for returning. It's very readable. It's everything else that google managed to fuck up, right from the beginning, and doubles down on.

@tychosoft @codeberg @civodul It also means that the entire Go ecosystem is *forced* to use one version control system. So not only is it coupled to GitHub, it's coupled to Git. I think Git is great, but I also think it's a horrible idea to *require* one specific version control system.

@be @codeberg @civodul as noted it is no longer tied to github, but yes, every imported package is still tied to a specific repo path, and if an essential one goes missing...

@tychosoft @codeberg @civodul and what if someday someone makes a version control system that's better than Git?

Show newer
Show newer
Show newer

@be @tychosoft @codeberg @civodul This is not true. The go tooling would only understand git, but it would only checkout the repo into your local GOPATH, so you could have libraries locally and make it work. It supports Mercurial and other SCMs now, same way as non-github is now supported. Still bad, but not as bad as you are saying.

Sign in to participate in the conversation
Mastodon (Aquilepouet)

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!