Bzip2 To See Revival Under New Maintainership, Experimental Porting To Rust

[clavko]

Everyone talking about dependencies of Rust... What are those? Glibc? Rustc is a compiler built on LLVM infra. How does that differ from GCC or clang as a dependency? And how does cargo differ from automake or cmake as a dependency.

There's unreasonable amount of hate towards something that's actually a really nice systems language.

Bzip2 is open source, ffs. If you dislike current development, fork it and write it in machine code. At least that has no dependencies.

[starshipeleven]

Everyone talking about dependencies of Rust...

fecking noobs.

[jjkk]

Everyone talking about dependencies of Rust... What are those? Glibc? Rustc is a compiler built on LLVM infra. How does that differ from GCC or clang as a dependency? And how does cargo differ from automake or cmake as a dependency.

There's unreasonable amount of hate towards something that's actually a really nice systems language.

Bzip2 is open source, ffs. If you dislike current development, fork it and write it in machine code. At least that has no dependencies.

Not sure if ignorant or just triggered, so let me explain. Rust is dependent not only on Glibc and GCC or LLVM which would be ok, it is dependent on hundreds of megabytes of binary data, including the binary build of itself. And on top of that it requires internet connection to download something during the build process without well defined means to control that.

i am not a fan of such critical low level software being ported to language with such a truckload of dependencies.

i'd rather see core os components stay reliant on C/C++ compiler, this makes things simpler for people putting together distributions.

Exactly this. I am one of those people and can say that to automate builds of Firefox or librsvg in a clean and reproducible manner is just a load of unnecessary and undeserved pain. The difference between automake, cmake, or just about any traditional approach is that Rust overcomplicates many things without any reason.

Not personally against new languages even the toy and unnecessary ones. If it is truly open and maintainers are cooperative, just fine. But lots of bad vibes are coming from rust people, that is sad. You don't have to tell people that something is really nice, they will find it by themselves if it really is, don't spoil their sense of discovery. Just calm down, you don't need to set the whole world against you to feel special and unique. You already are and everyone accepts that.

[hotaru]

Do you mean that "zstd -19 --threads=0" compresses worse than bzip2?

yes.

Decompression speed of zstd is, roughly speaking, about 500MB/s !!!

decompression speed of lbzip2 scales nearly linearly with the number of cores you throw at it.

[clavko]

Not sure if ignorant or just triggered, so let me explain. Rust is dependent not only on Glibc and GCC or LLVM which would be ok, it is dependent on hundreds of megabytes of binary data, including the binary build of itself. And on top of that it requires internet connection to download something during the build process without well defined means to control that.

Ok, I've issued a couple of equeries on my Gentoo box...

greenbean ~ # equery size gcc-9.1.0
* sys-devel/gcc-9.1.0
Total files : 1770
Total size : 494.38 MiB
greenbean ~ # equery size rust-1.34.2
* dev-lang/rust-1.34.2
Total files : 1281
Total size : 382.40 MiB

Aside from pulling a C++ compiler to bootstrap it (but gcc needs bootstrapping as well) and having a curl/openssl dependency for package management, which is sorely missed in C/C++ ecosystem, I see no large dependencies. What are you talking about? Yes, compilers weight a couple of hundreds of megabytes. No, you don't have to have a rust compiler infra in order to download a binary made by rust compiler.

[jjkk]

Ok, I've issued a couple of equeries on my Gentoo box...

greenbean ~ # equery size gcc-9.1.0
* sys-devel/gcc-9.1.0
Total files : 1770
Total size : 494.38 MiB
greenbean ~ # equery size rust-1.34.2
* dev-lang/rust-1.34.2
Total files : 1281
Total size : 382.40 MiB

Aside from pulling a C++ compiler to bootstrap it (but gcc needs bootstrapping as well) and having a curl/openssl dependency for package management, which is sorely missed in C/C++ ecosystem, I see no large dependencies. What are you talking about? Yes, compilers weight a couple of hundreds of megabytes. No, you don't have to have a rust compiler infra in order to download a binary made by rust compiler.

These queries is an attempt to oversimplify the problem. Like saying "both a hammer and a microscope weight about 3 kilos -> they must be equally easy to produce".

What I am trying to tell is that having decades old linux, bash, tar, gcc, binutils, coreutils, sed, awk, etc., a dozen or so of binary packages in total occupying less than 100 megabytes of space, I am able to create a build chain and reproduce thousands of packages of software and firmware. Including modern, including ancient, including exotic architectures, including whole OS distributions, including other (cross)compilers and environments.

And no, you can not reproduce Rust without extending this bare minimum by a binary build of itself. Of course there are quite a few examples of quirky build procedures, but they can be managed in reasonable ways and built only from source code. IMO that is huge disadvantage of Rust and even more so because it can be solved but it is not. If it can not be solved it is a poor design. If rust maintainers intentionally keep it self-contained and irreproducible it is a poor policy. Go guess.

[hotaru]

In my experience, bzip2 has been made obsolete by xz / zstd / brotli.

in my experience, anything without multi threaded decompression is obsolete outside of uses where I'm stuck with single threaded decompressors. most of the compressed data I have is xz or lz4, but if the Linux kernel and Pacman implemented parallel decompression for bzip2, it would be a much better choice.

[Weasel]

it's obsolete though

Just like Rust.

[dremon_nl]

Not sure if ignorant or just triggered, so let me explain. Rust is dependent not only on Glibc and GCC or LLVM which would be ok, it is dependent on hundreds of megabytes of binary data, including the binary build of itself. And on top of that it requires internet connection to download something during the build process without well defined means to control that.

Who cares about "hundreds of megabytes" of compiler binaries? This is ridiculous complaint. Modern toolchains often take gigabytes (I mean look at Apple/Microsoft). And there are no runtime dependencies because the produced binary is only linked to glibc (can be also statically linked to musl) and Internet connection is only required for 3rd-party crates if your project uses them. In the recent Rust release it's possible to set up a custom crate repository (e.g. on the intranet).

The difference between automake, cmake, or just about any traditional approach is that Rust overcomplicates many things without any reason.

Quite the opposite, cargo build tool is designed to be very simple.

But lots of bad vibes are coming from rust people, that is sad. You don't have to tell people that something is really nice

I have yet to see those mysterious "Rust zealots" who constantly attack the good people. Actually it's quite the opposite; most unexplained hatred is generated towards Rust and in most cases by people who know virtually nothing about it.
And if something is really nice you definitely CAN tell people about it, although you don't HAVE to. I am trying to promote Rust also but purely from technical perspective. It truly shines in making a defect-free software. Today it's the most critical issue.

[clavko]

monraaf Well, in order to provide a feature you either make your own code or use another already available. Rust makes it easier to do the latter in comparison to C++, I suppose.

In C++ you'd probably use only stdlib. And maybe some boost. Ok, lots of boost. Some Poco? That libcurl would really get handy... Ah, need to add zlib and openssl. Perhaps a JSON parser. An ORM library? And then you're in the same mess, because you're developing real world software.

Well, probably not the same, because in C++ you're on your own handling versioning. This issue is not about the language, is about reinventing the wheel vs reusing. It's a gotcha that almost all programming languages face and try to solve to a various degree of success. Has little to do with rust, aside that it's probably better equipped to battle it.