Live data from Hacker News

Cross-platform Rust rewrite of the GNU coreutils

github.com

191–200 of 498 posts

Re: Cross-platform Rust rewrite of the GNU coreutils

#191
post #174

Earlier quoted context omitted.

Difficulty is relative. If you don't study modern C idioms your C code will be crap. Same goes for Rust. Honestly using higher-level languages is the same mentality as taking a pill to magically lose weight. It's quick, but detrimental (to programmers ability) in long term. Programming becomes easy but in the long term most people forget how algorithms and data structures work, in addition to cache mechanisms and oth…

I disagree. When programming C you have to remember so much stuff and be so carful about even the simplest things, this mental effirt takes from your resources, and I dont care how good a C programmer you are. The mental capacity saved can be invested in higher level design issues that gone get you a lot more in the long run.

It will be slower, though. C is king in raw performance, and in critical areas where that does matter you don't really have a choice but to write it "by hand" (aka in C).

Re: Cross-platform Rust rewrite of the GNU coreutils

#192

Some people worry about the file size (which should be similar), but I worry about the speed. How much faster can we grep or sed with a Rust compiled grep vs a C compiled grep?

Likely not as fast as with a grep written in C, but FreeBSD's grep is (was?) pretty slow compared to the GNU version and nobody really cares (read: it's probably fast enough).

Re: Cross-platform Rust rewrite of the GNU coreutils

#193
post #168

Earlier quoted context omitted.

Difficulty is relative. If you don't study modern C idioms your C code will be crap. Same goes for Rust. Honestly using higher-level languages is the same mentality as taking a pill to magically lose weight. It's quick, but detrimental (to programmers ability) in long term. Programming becomes easy but in the long term most people forget how algorithms and data structures work, in addition to cache mechanisms and oth…

> Difficulty is relative. If you don't study modern C idioms your C code will be crap. Same goes for Rust. That's not a valid argument for why better tooling can't help alleviate some of the difficulty. > Honestly using higher-level languages is the same mentality as taking a pill to magically lose weight. It's quick, but detrimental (to programmers ability) in long term. If that were true, the most effective program…

>If that were true, the most effective programmers would only code on assembly.

No, because C is as fast as hand-coded assembly in most of the cases. The same can't be said of any high level language in comparison to C (save for C++ and Fortran).

Re: Cross-platform Rust rewrite of the GNU coreutils

#194
post #52

What are the licensing implications for this kind of work? I assume the authors used GNU coreutils as more than just inspiration. They probably read all the original code and reused some of the solutions (obviously ported to Rust). Shouldn't the derivative work still be covered by the GPL?

This is a terrific project idea, but I agree that it should likely be under the GPL. Even if it is not legally derivative, it would be nice to preserve the GPL.

It's under a GPL-compatible license. This way, it can be used both in Linux and in the BSDs.

Re: Cross-platform Rust rewrite of the GNU coreutils

#195
post #3

Could be useful given the choice of MIT license rather than a GPL variant.

They really should use the GPL and not a pushover license.

If they're not doing a 'clean room' rewrite, I'd agree. Otherwise? That's their choice, and it's one I'm glad to see. This could be quite useful for OSes that aren't GPL'd, like the BSDs, or Redox.

Re: Cross-platform Rust rewrite of the GNU coreutils

#196

Earlier quoted context omitted.

Not sure why you're being downvoted. I don't see why we shouldn't be moving to languages like Rust given the chance, as C makes it far more difficult to write safe and correct code.

Don't underestimate performance. I haven't seen the most recent benchmarks, but C/C++/Fortran are still unbeatable in raw speed. If you want maximum performance no matter what, these are the languages to choose, even if they sacrifice readability, maintainability or safety.

That is, in this general form, wrong. Most compiled languages can match or sometimes exceed C speeds, depending on the task at hand and the algorithm chosen. There are a lot of very inefficient C programs around - because they are badly written. More high-level languages allow the programmer to focus on speed where it matters. And in the current day and age, there should be no reason to favor raw speed vs. program correctness and safety.

Re: Cross-platform Rust rewrite of the GNU coreutils

#197

Earlier quoted context omitted.

I don't understand why you need an IDE, I believe Rust is simple enough that you can work on things in Notepad++ or Vim or Emacs.

This is pretty common, and the advantages of Rust won't overcome people being inherently lazy (not in a bad way... lazy in this sense is really more efficient). People love C# for that very reason, once they get used to Visual Studio, convincing them to switch to something with very limited IDE support is a tough argument. Most people have better things to do with their life. Rust will get there though, just give the…

I write C# at work using VS, and am working on getting omnisharp running so I can use VIM here instead. I have fully converted from being an IDE person to a VIMMER. So many helpful things, and keyboard binds that I can't believe I ever lived without. VsVim just isn't the same, and cannot be used in VS2008 which we unfortunately use most of the time.

Re: Cross-platform Rust rewrite of the GNU coreutils

#198
post #63

What are the licensing implications for this kind of work? I assume the authors used GNU coreutils as more than just inspiration. They probably read all the original code and reused some of the solutions (obviously ported to Rust). Shouldn't the derivative work still be covered by the GPL?

Just to give an example: https://github.com/uutils/coreutils/blob/master/src/whoami/p... looks suspically simmilar to: http://code.metager.de/source/xref/gnu/coreutils/src/whoami....

The rust version looks more like the old FreeBSD version http://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-relea...

Re: Cross-platform Rust rewrite of the GNU coreutils

#199

Earlier quoted context omitted.

I've submitted an issue asking to shift to a GPL license. My general perspective on code I write that isn't for work - it has to be GPL. I refuse to have my code be yoinked by random corporations for their profit without having the code shared downstream.

Like many other programmers, I avoid GPL'd code like the plague. The idea that you can own an idea seems ridiculous to me, and it feels unjust to sue "random corporations" for using ideas that you published. We're standing on the shoulders of giants, and I see the GPL as a tumor that's draining the world's resources. Just my two cents.

It's not about owning an idea, like a patent is. It's about receiving payment for someone else using the code I developed. The price for using my code is that you also release your source code. If that price is too high, you can't use my code. The hard part is defining "use my code" in the context of reading my source, then using those ideas in your own project. At what point does it change from gathering an idea to just copying my code?

Re: Cross-platform Rust rewrite of the GNU coreutils

#200
post #76

Earlier quoted context omitted.

Prof. Regehr did not find problems with SQLite. He found constructs in the SQLite source code which under a strict reading of the C standards have “undefined behaviour”, which means that the compiler can generate whatever machine code it wants without it being called a compiler bug. That’s an important finding. But as it happens, no modern compilers that we know of actually interpret any of the SQLite source code in…

At some point some popular compiler is going to make a subtle but important change to some undefined behavior that's not going to be immediately obvious as to it's repercussions, and the fallout will be massive. Wait until you realize that the length of a byte in C is not clearly defined. Someday a processor will come along where a byte is 6 bits, and the fallout will be massive. (Really, it's happened before). No, a…

Its far more likely for a major compiler to exploit more undefined behavior for optimizations than for a processor with a bizarre sized byte to become popular. The major compilers already do this.

> The reality is unless you are using a formally-defined language like ML, you are relying on undefined behavior in your language.

This is not true, not using the definition of "undefined behavior" provided in the C standard.

Post reply on HN