131–140 of 400 posts
Earlier quoted context omitted.
(Rust does not guarantee the prevention of memory leaks, to be clear)
can you elaborate please?
"For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space." I don't want to be harsh, but who the hell is compiling anything on i386 now? Real question, is anyone even making fresh i386 hardware that might be used by consumers, or deployed in datacentres?
OpenBSD is. Just because you can't think of a use case doesn't mean they don't exist.
> I wasn't implying. I was stating a fact. There has been no attempt to move the smallest parts of the ecosystem, to provide replacements for base POSIX utilities. This is in fact incorrect--there is a project aiming to build all of the coreutils in Rust ( https://github.com/uutils/coreutils ). More to the point: while I do concur in the conclusion that Rust shouldn't be a part of the OpenBSD base system, the gatekee…
There is no gatekeeping. To actually achieve POSIX-compliance is not an easy task and requires lots of testing. If you don't do it then your replacement will break everyone's scripts. A distro maintainer will also want to retain compatibility with their supported GNU/BSD extensions so that's more work to add on. I would still agree with his statement at least as far as BSD is concerned. Outside of Redox I haven't see…
Thinks like `cargo tree | wc -l` or the number of dependencies cargo builds are not appropriate as they count _internal_ dependencies (from the same repo).
Given that it's split into many "sub-crates" in the same workspace this will make the numbers unnatural high.
Or with other words _most_ of the 417 "dependencies" for building the "unix" feature set are internal ones in the same repository. I.e. the project is just split up into many small parts.
Additionally many deps are reused between many internal deps.
Removing duplicate dependencies, dev-dependencies (e.g. testing tools) and build dependencies less then 100 deps are left.
Looking through them many are rust versions a C/C++ libs which are "available per default", like e.g. unix_socket, libc and similar.
Then some are thinks which come from rust deps being split up more, e.g. there are md5, sha1, sha2, sha3 as separate crate.
There are also a bunch of "internal" deps of deps e.g. backtrace-sys.
Anyway still a lot of deps but most are quite reasonable and could be "taken care of" in some way or another if they want to ship a distro based on this.
This is from 2017. In 2020 I personally use ag 99% of the time, and when I do use grep is because its options are burned in my brain and it saves me 30 seconds by not looking up the equivalent for ag. https://github.com/ggreer/the_silver_searcher
But ag isn’t a drop in replacement for grep, and when you have tooling that’s depends on that, replacing it simply isn’t a viable option.
Earlier quoted context omitted.
Regarding build tools for C, you might find this one interesting: https://github.com/vmchale/cpkg
Yeah, there are lots of good build systems for C (didn’t know about this one; will have a look; thanks for sharing), but the problem is that they have tiny adoption, especially among “core” ecosystem packages, like coreutils and friends. The problem isn’t technical, it’s political and cultural. This ecosystem is hostile toward its users for no discernible reason. If anyone knows of a distribution that aims to use onl…
It's not for "no reason", in general you will not be able to get away from having a complicated build system at the lowest level. Otherwise you would need to be prepared to give up on nice things like cross-compiling and supporting more than one compiler, CPU architecture, etc.
Earlier quoted context omitted.
There is no gatekeeping. To actually achieve POSIX-compliance is not an easy task and requires lots of testing. If you don't do it then your replacement will break everyone's scripts. A distro maintainer will also want to retain compatibility with their supported GNU/BSD extensions so that's more work to add on. I would still agree with his statement at least as far as BSD is concerned. Outside of Redox I haven't see…
> Or is there something I'm missing here? There may be some platform-specific dependencies, but at least when building on Windows, I saw 67 dependencies downloaded. One thing that may be skewing the count is that internally coreutils is packaged with one crate per command. There are about 100 commands, so you'll have seen at least that many separate crates building. They're listed here: https://github.com/uutils/core…
It also doesn't help that Rust keeps on pushing on the idea that "static linking is the only way to go". This is another cargo-cult which I wish didn't end up being engrained so deep in the toolchain because while it has some merits, it also has significant drawbacks of a typical unix distribution. Static linking might be good for folks distributing a single server binary over a fleet of machines (pretty much like Go…
A good linker will shave off the parts of a library you're not using, and the parts which are left over are usually not very big. The problem isn't with static linking, it's that some "developers" think that bundling an entire Chromium build with their app is a good idea.
Rust has a problem with big binaries (so does Go), but that's Rust's problem, not static linking's problem.
Earlier quoted context omitted.
How much of that is Indicative of rustc vs llvm? The latter isn't exact a lightweight piece of software.
Until there is a rustc in production that doesn't use llvm to emit code in the backend, the point is moot, no?
Earlier quoted context omitted.
> Fresh hell, they all seem to be build dependencies of each other. ‘sed’ is its own build dependency. Except that people have run into the exact same issue with stuff like rustc and cargo. Bootstrapping an entirely new platform is just hard, no way around it.
Comparing coreutils to a self-hosting compiler is a strained analogy. Bootstrapping a compiler is about as hard as it gets; there’s no reason coreutils needs to depend on itself.
> I wasn't implying. I was stating a fact. There has been no attempt to move the smallest parts of the ecosystem, to provide replacements for base POSIX utilities. This is in fact incorrect--there is a project aiming to build all of the coreutils in Rust ( https://github.com/uutils/coreutils ). More to the point: while I do concur in the conclusion that Rust shouldn't be a part of the OpenBSD base system, the gatekee…
> the gatekeeping implied here [...] is really toxic It's Theo de Raadt, toxic rhetoric is sort of his brand. But... he has a real point here. It's not about grep or cat or whatever really, those are just the use cases for which OpenBSD would care. It's that as Rust is reaching the second decade of its history, and despite some outrageous wins in press, evangelism, and general developer mindshare... Rust just hasn't…
IMHO, that's basically not possible, so it isn't a fair ask. If the Rust community produced a drop-in replacement that is every bit as good as readline in literally every way... still nobody would switch, because why would they? What's the benefit? You spend all this effort just to trade evenly across. If the Rust community produces something better, nobody's going to use whatever those extra features are outside of Rust itself.
This is the category of software that will be last.
The question for Rust, and equally, every other ambitious language, isn't really "What percentage of existing code will be rewritten in this new language?" (And by "rewritten", I don't just mean "reimplemented but only your community uses it, but in the sense you mean... it actually replaces the original.) If your answer is any number significantly over zero, that itself represents entrance into the absolute top tier of languages... this is very rare. The question for Rust et al is "What percentage of future code will be written in your language?" On that front, Rust is still on a pretty decent trajectory.