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.
Cross-platform Rust rewrite of the GNU coreutils
191–200 of 498 posts
Re: Cross-platform Rust rewrite of the GNU coreutils
#192Some 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?
Re: Cross-platform Rust rewrite of the GNU coreutils
#193Earlier 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…
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
#194What 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.
Re: Cross-platform Rust rewrite of the GNU coreutils
#195Could be useful given the choice of MIT license rather than a GPL variant.
They really should use the GPL and not a pushover license.
Re: Cross-platform Rust rewrite of the GNU coreutils
#196Earlier 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.
Re: Cross-platform Rust rewrite of the GNU coreutils
#197Earlier 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…
Re: Cross-platform Rust rewrite of the GNU coreutils
#198What 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....
Re: Cross-platform Rust rewrite of the GNU coreutils
#199Earlier 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.
Re: Cross-platform Rust rewrite of the GNU coreutils
#200Earlier 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…
> 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.