Rust-Written Replacement To GNU Coreutils Progressing, Some Binaries Now Faster

[krzyzowiec]

I don't agree with the 'broken' part ... and nothing wrong with being old, well defined/understood either. C is a language that gives you complete freedom to do anything. There are no restrictions per-say. It is wonderful. It is up to the programmer whether the person crashes the system or writes a thing of beauty. Between C and assembly we can accomplish anything. So broken? No. Far from it. Just simplicity at it's best. Do we write everything in 'C'? Of course not. At work, I use a lot of Python as that fits as lot of the tasks at hand. However when I work in our control system and real-time RTUs, C/C++/Fortran/Perl is used. And for embedded projects at home I use C/Assembly and some cases circuit/micro Python. Dabbling in Ultibo with Object Pascal.... Point is 'C' is not broken. It gives you the freedom to do 'anything' you can imagine to do with a computer. I like that. I don't like being hemmed in when I don't need to be and C gives me that.

If it was well defined then it wouldn't have so much undefined behavior. Why can you use some variables before they are initialized? That is a broken language feature. We know this should not be possible in a sane language. I don't think I need to go into buffer overflows due to lack of bounds checking, or the other issues, as everyone knows them by now.

It's fine if you like C, just as it is fine to like assembly, but software really should not be written in C any longer. The restrictions that you abhor actually enable you to do things that were not possible before. For example, before we came up with structured programming, you had the ultimate freedom. You could just set labels and jump everywhere. It led to crazy spaghetti code, but anything was possible, at least anything except the kind of complicated programs that we expect to build today.

It took us restricting ourselves to standard constructs like loops, conditionals, etc. for our code to be comprehensible enough that we could move from simple programs to building more complicated ones. Gnome or KDE would not be possible without them. Now we have even more restrictions with Rust, but the nice thing about them is that we no longer have to track aliasing in our heads and hope for the best. What will Rust enable us to do in the future? Trivial parallelization for one thing.

[krzyzowiec]

I think there's a few things you need to consider. I can write complex things in JavaScript in a day which would take me a possibly a month or more in C++. I think Rust is attractive because it's easier to maintain, can write nicer code and can detect errors (which you haven't programmed to catch) and print them out for debugging.

I'm not into Rust, but I know enough about it to find it extremely appealing.

I've programmed in Rust. It feels almost as productive as JavaScript but with static typing, references, and a helpful compiler that gives you useful hints! Dynamic languages are still great for what they enable at runtime, but as a static language Rust seems as good as you can get.

From this perspective it is quite inexplainable to me if someone starts a new project today with tools less than state of the art (which prevent memory leak cve) to begin with ... That is like designing mechanical Systems like they did in the 50s, aligne and drill while assembled that is just shit ist just no more state of the art because the milling and turning tools can achive precision to allow parts to be manufactured to spec.
And yes there are still a lot of retarded engineeres which thel the mechanic they should fit the things together and then drill an bolt them together, sure one can still do it today but it has a cost.

This is actually a very interesting point. It's more than just subjective personal preference. I have more than once read people say that we need to stop writing software in C due to all the bugs caused by it, but there was no viable replacement with the same performance characteristics. Now that we have it, there are some places where not using it would be inexcusable. In other fields, if you ditched certain safety features or best practices, you could be held liable for the disastrous consequences, but in software, things are treated differently because they are virtual and most people don't understand how programming works.

[sdack]

Why can you use some variables before they are initialized? That is a broken language feature. We know this should not be possible in a sane language.

An initialization can come late and depend on external code. It helps to avoid multiple initializations. Compilers can warn you about such uses. Nothing insane about it and better than initializing variables multiple times only to satisfy an overbearing language.

[jacob]

No, not at all. The point is simplicity. You just do not see it.

That's a strawman. You are assuming that anyone who doesn't agree with you doesn't "see" it. I for one do see it but that doesn't mean I agree. Simplicity is not an all-overriding holy grail. It's a factor that has to be weighted against other important criteria. "Make it as simpler as it can be, but not simpler": you are one of the people who want it to be simpler and that's where it becomes a liability. In fact I'm convinced that the "worse is better" ideology is the single most idiotic idea in the history of software engineering. In reality, worse is worse, period. Solving only the proverbial 90% of the problem, tolerating bad behaviour in corner cases, seeking simplicity for simplicity's sake, that *may* have been acceptable when going the remaining 10% implied unreasonable extra effort. Now we have theoretical understanding and tools that make the initial 90% marginally more expensive in terms of effort, but they make going to 99% feasible, practical and comparatively cheap. Which means that now it's no longer optional, it's a mandatory requirement. Refusing to accept that reality is a sign of ignorance, if not downright incompetence.

[Mordrag]

I love how sdack is showing everyone how good Rust actually is. If he didnt start trolling here, all those good arguments may not have been written here for the reference of other readers. So a big thank you to you sdack. Maybe you should consider brainfuck. It is a great simple language with minimal features but still turing complete. There is a beautiful simplicity in it some may not see.

[jacob]

I've programmed in Rust. It feels almost as productive as JavaScript but with static typing, references, and a helpful compiler that gives you useful hints! Dynamic languages are still great for what they enable at runtime, but as a static language Rust seems as good as you can get.



This is actually a very interesting point. It's more than just subjective personal preference. I have more than once read people say that we need to stop writing software in C due to all the bugs caused by it, but there was no viable replacement with the same performance characteristics. Now that we have it, there are some places where not using it would be inexcusable. In other fields, if you ditched certain safety features or best practices, you could be held liable for the disastrous consequences, but in software, things are treated differently because they are virtual and most people don't understand how programming works.

The problem is that bugs are virtual until they aren't. There is nothing virtual about a bug in an airplane's autopilot software, or in the Therac 25, or in banking software that may make your $30000 transfer simply disappear due to a race condition. Fortunately, some critical areas mandate formal code proofs and exacting testing methods that leave absolutely no room for "good programmers" who delude themselves that they know what they are doing in C. Now we have tools (not only rust, but including rust), freely available to everyone, that make some of the actually good development practices possible even for small hobby projects. Not taking advantage of them to improve the quality of even "ls" is indeed inexcusable.

[caligula]

Is that because of coreutils or the Linux i18n patch that has been applied since 2001 by Linux distros to add i18n support to coreutils? The patch has had performance issues (see https://bugzilla.redhat.com/show_bug.cgi?id=499220).

You can look it up here https://github.com/coreutils/coreuti...ter/src/true.c - the resulting file is around 35 kB on my x86-64 system.

The utility could just return "EXIT_SUCCESS", but it does a lot more. Why? Dunno.. probably a majority of users don't even realize the 'true' in their bash script use bash's internal true command.

[jjkk]

Very good. Mere 17 pages of comments and rust sectarians show their goofiness in all its hysterical glory. This time even they managed to promote themselves to new levels of incompetence.

Some of them have no idea of MIT, Apache and GNU licenses but send links to their godlike software which they never ever tried to build from source as a strong and valid argument.

Please go on. The amount of whining of rust sectarians should not drop for a single second.

[mdedetrich]

I've programmed in Rust. It feels almost as productive as JavaScript but with static typing, references, and a helpful compiler that gives you useful hints! Dynamic languages are still great for what they enable at runtime, but as a static language Rust seems as good as you can get.

In this regard while Rust is as good as you are going to get when it comes to zero cost abstraction systems language it doesn't come close to Scala in terms of expressiveness for a strongly typed language.

[Danielsan]

So Rust it is just the excuse to erase the GPL from the "GNU Coreutils" and to leave just "Coreutils". Genius!