Ludovic Courtès
#Rust 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 #FreeSoftware β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.
Taylan Kammer
Ramakrishnan VU2JXN
@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.
Csepp π©Έ
@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.
Ramakrishnan VU2JXN
@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 - https://github.com/commercialhaskell/stack/issues/5459)
Taylan Kammer
sneak
@civodul copyleft snobbery has no place in free software. public domain is free software too.
Be
@civodul Also, I am really impressed with the way the Rust language is collaboratively developed at scale and continuously evolving without breaking old code.
Be
@civodul My answer to the lack of copyleft in the Rust ecosystem is to write copyleft Rust code. π
Be
@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++.
Be
@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.
Be
@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.
Be
@tychosoft @civodul lol that's what happens when using something made by Google for essential infrastructure of your project
David Sugar
@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.
Be
@tychosoft @civodul and people advise me to use Flutter for the GUI of a Rust application π
Be
@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
@tychosoft @civodul lol what a terrible idea to couple the symbol names in the code to where the code is located
Codeberg.org
@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
David Sugar
@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.
David Sugar
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.
David Sugar
@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 ;).
Be
@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
@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
@tychosoft @codeberg @civodul Go sounds like an even worse shitshow than the Node ecosystem.
David Sugar
@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.
David Sugar
@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.
mbernabe
@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.
David Sugar
@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.
Be
@fnetX @tychosoft @civodul At least you don't need to commit those 500 MB of Node modules into your Git repository.
fnetX
@be
Switching to my private account for not spamming all codeberg followers :)
Not worse. The Node stuff is awful and breaks often, at least for me, while Go works pretty fine.
And Go doesn't take 500 MB which node_modules does if you create a 17 lines HTML module for common js frameworks.
But yeah, some things aren't great either.
fnetX
@be
Well, if you want to achieve the same with vendoring in Go (without network etc), you'd need to.
I'm happy people (commonly) don't do this.
@tychosoft @civodul
David Sugar
@fnetX @be @civodul In any case I absolutely require vendoring when I build stand-alone release tarballs (something go tooling also doesn't itself support), because obviously no arbitrary git repo is guaranteed to remain. So yes, I have a dist target that also dumps in vendored code, and that is also what I do to cache even for local builds.
David Sugar
@codeberg @be @civodul in the beginning, and for a while, they were only able to process "github.com" to git. So you couldnt use gitlab, or codeberg... so while now still lame, it used to be double lame.
Be
@tychosoft @codeberg @civodul So if GitHub shut down, with the original design, the entire Go ecosystem would collapse instantly with no recourse without changing how the core tooling works? π€£ Incredible.
David Sugar
@be @civodul exactly, a really terrible idea. They have since introduced gopkg.in as a kind of redirect proxy service, that you can use to at least have a fixed path that can then use the real target path instead, but how many well known packages are offered thru that is not known outside of some of google's own core library components. In fact, most of the awful aspects of go really were google decisions.
Ludovic Courtès
@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.
Josh Justice
@civodul how does choosing a copyleft license exclude you from the rust community?
Josh Justice
@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?
Ludovic Courtès
@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.)
Be
@civodul Another aspect of Rust that makes it really easy to share code is how easy it is to organize code into independent modules and libraries, even within one project.
Be
@civodul Going along with the standard library, one more aspect of Rust, as well as other modern programming languages, that makes it much easier to collaborate is standardized tooling? CMake? Which CMake generator? Meson? Handwritten Makefile? Autotools? Visual Studio project files? Nah, none of that mess. Everyone uses Cargo.
Be
@meena @civodul Doing something like this in C or C++ would be a nightmare. You can't just run QFutures on GTK's event loop.
Be
@meena @civodul The way asynchronous runtimes are decoupled from the standard asynchronous interfaces is a great example of this. It allows asynchronous code to be shared between a native Rust runtime like async-std or Tokio, and it also can be integrated with an external runtime like the GTK Rust bindings do.
Be
@meena @civodul Yep, just because the standard library exists and doesn't suck, doesn't mean external libraries can't do some its jobs better.
Mina
@be @civodul funnily, Rust has several high quality, platform independent libraries and frameworks for doing these things.
orthogonal libraries or frameworks, or consumers of them are aware of this and often allow you the choice which ones to depend on!
David Sugar
@loziniak @codeberg @civodul @be most likely google itself ;). They had already done many similar poor decisions and roadblocks in the past...
Codeberg.org
@tychosoft @loziniak @civodul @be let's rebuild our trust in the free minded communities that created (and often still maintain!) the foundations and backbone of the modern internet as we know it. Corporations were late to the game
Be
@tychosoft @codeberg @civodul and what if someday someone makes a version control system that's better than Git?
Loziniak
David Sugar
@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...
Chirp! is a social network. It runs on GNU social, version 2.0.1-beta0, available under the GNU Affero General Public License.
All Chirp! content and data are available under the Creative Commons Attribution 3.0 license.