Cross-platform Rust rewrite of the GNU coreutils • Hacker News Board

Re: Cross-platform Rust rewrite of the GNU coreutils

#311

Post by rmc » Tue, Mar 22, 2016, 9:25 PM UTC

pnathan wrote: post #150

coldpie wrote: post #83

Earlier quoted context omitted.

I've contributed to this project, and yeah, this was a major concern for me while I was doing it. If it shared a license with GNU coreutils, then code sharing would be free and the project would be built much faster because I could just use coreutils's algorithms. As it is, I haven't done any real, hard work for it because frankly, I won't want to re-invent that wheel. The project isn't terribly far along. I wonder i…

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.

I've started using the Affero GPL in order to avoid the "networked software" work around

Re: Cross-platform Rust rewrite of the GNU coreutils

#312

Post by rmc » Tue, Mar 22, 2016, 9:26 PM UTC

coldpie wrote: post #199

ChristianBundy wrote: post #188

Earlier quoted context omitted.

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…

"Your money or your source code, which do you want to give up?"

Re: Cross-platform Rust rewrite of the GNU coreutils

#313

Post by aidenn0 » Tue, Mar 22, 2016, 9:26 PM UTC

zwischenzug wrote: post #211

aidenn0 wrote: post #142

Earlier quoted context omitted.

SVN is way simpler at the interface than CVS, you should really look into it. SVN is a spiritual successor to CVS, and is trivially easy for a CVS user to pick up. We switched from CVS to SVN at work several years ago and everyone was happy with the change.

We did the same and plenty were _unhappy_. In the end git took over. There were plenty of things I didn't like about SVN (separate folders per branch? yuk), having used CVS, and didn't find it 'trivial' to pick up.

Really, it's hard to handle branching worse than CVS does, and if SVN doesn't do a stellar job either, I don't see it as a barrier to switching.

Re: Cross-platform Rust rewrite of the GNU coreutils

#314

Post by wangchow » Tue, Mar 22, 2016, 9:27 PM UTC

pcwalton wrote: post #250

wangchow wrote: post #243

Earlier quoted context omitted.

I don't think I worded my original comment in the best way. However, I find that the people who make statements like "C makes it far more difficult to write safe and correct code" haven't touched the language in years if ever. Hence, no wonder it will be difficult for them because they have not practiced or been exposed to good C idioms. Correct code in C is actually easy since the language is very simple. Due to thi…

> Correct code in C is actually easy since the language is very simple. 1. No, it's not. Witness the various arguments that have happened on HN over the years concerning whether the imprecise language of the spec makes some idiom undefined behavior or not. 2. The evidence over the past 35 years has not shown that correct code is "simple" in C. > For instance, parallelizing algorithms must take into account cache-alig…

"The evidence over the past 35 years has not shown that correct code is 'simple' in C."

"Your firm belief is contradicted by 35 years' worth of memory safety track records of large-scale software written in C."

Keep in mind, of those 35 years, it only makes sense to consider the last decade-onward (or so) in comparison. While the language hasn't changed a whole lot, programming methodologies certainly have. How many of those libraries in question were written within the last 5 or 10 years? What is the code coverage on them? Et cetera.

I am not trying to argue that C is perfect and everything should be written in C. That would be crazy! There are definitely issues with C no doubt--but so many people say C is dangerous and difficult when in fact they don't even practice using the language. This is no different than practicing Violin on a daily basis and saying Cello is difficult so people should stop playing Cello (not a perfect analogy but you know what I mean).

The other comments is just me ranting at how the majority of programmers don't understand important computer-science concepts because of their removal from such concepts by higher-level languages. And sometimes its important to have a higher level abstraction to help solve certain problems. But, people have a tendency to become lazy and therefore they lose the fundamentals over time.

Re: Cross-platform Rust rewrite of the GNU coreutils

#315

Post by pcwalton » Tue, Mar 22, 2016, 9:29 PM UTC

codedokode wrote: post #121

Though I like ideas behind Rust but the code is awful. If you look at the code you'll see a lot of misterious symbols (as in Perl) and strange constructs like wrap, unwrap, Arc etc. They make the code less readable. Also Rust doesn't have exceptions so you have to wrap almost any function call with let/match/Ok/Err. Ugly. I looked at one random file which turned out to be a `du' command implementation: https://github…

There aren't any mysterious symbols left in Rust that aren't in C++. Can you name one? The Perl comparison doesn't make sense to me.

Also, idiomatic code doesn't match on errors; it uses try!. And nightly now supports a ? syntax that's even shorter.

Re: Cross-platform Rust rewrite of the GNU coreutils

#316

Post by pcwalton » Tue, Mar 22, 2016, 9:30 PM UTC

DrJokepu wrote: post #172

wyldfire wrote: post #154

Earlier quoted context omitted.

I suppose this coreutils impl doesn't do it but one could perhaps use rust w/o its standard library and use strictly some libc instead. Would probably still be a net win.

Writing Rust code interfacing libc is a rather frustrating experience though. Many libc interfaces use constructs that Rust really wants you to avoid (for very good reasons), things such as global mutable variables (errno and for callback functions without context pointers) or union types. I know about at least one cargo crate attempting to "Rustify" libc with some level of success. None the less, this is what I typi…

> Rust code as much of th Rust standard library is simply not ready for "serious" usage.

Can you elaborate on this? I've been getting serious usage out of the Rust standard library for years...

Re: Cross-platform Rust rewrite of the GNU coreutils

#317

Post by rmc » Tue, Mar 22, 2016, 9:31 PM UTC

_ph_ wrote: post #203

pnathan wrote: post #150

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.

The concept of a corporation using your code for their profit without giving back is mostly just an imagination. Todays reality has Microsoft and Apple sharing part of their codebase under permissive licenses. If a corporation uses your code, chance is, they want to give back any modifications to reduce their maintenance load. If GPL prevents 1 out of 10 corporations from misusing of your code, it also probably preve…

> The concept of a corporation using your code for their profit without giving back is mostly just an imagination.

One of the authors of the Python requests HTTP library has called out Uber for using Python, and almost certainly using requests, and not paying any money

https://lukasa.co.uk/2015/08/Funding_OSS/

Re: Cross-platform Rust rewrite of the GNU coreutils

#318

Post by jahewson » Tue, Mar 22, 2016, 9:31 PM UTC

jordigh wrote: post #290

jahewson wrote: post #285

Earlier quoted context omitted.

Your lawyers are peddling FUD because they make money that way. "Hey, it looks like you need another legal agreement, can't be too safe!" The reality is that an "unintentional copying" claim against source code makes for a very weak lawsuit and it's close to unimaginable that such a case would even make it into a court room. You're free to read whatever you like. Don't let anybody tell you otherwise.

> Your lawyers are peddling FUD because they make money that way. No, the SFLC works pro-bono. > You're free to read whatever you like. I wish that were true, but many current laws say otherwise. You do not sound like you are aware of those laws, so I take it you're not a lawyer. You're just hoping the world is as free as you say it is. I wish it were too, but we have to be pragmatic and work in the world we have whi…

Sigh... I feel like I'm not getting through to you here. Yes your layer works pro-bono but the rest of the time he works for money, and his entire conception of legal advice revolves around that. What's good for the goose is good for the gander: Your lawyer isn't paid to understand the law. He's paid to protect you from other lawyers. And other lawyers peddle FUD, so your lawyer has to protect you against FUD. Of course he's going to advise you to protect yourself! And if you've got an aggressive adversary, then you probably should.

But you don't need to protect yourself. You're legally allowed to read stuff and write something similar. Just don't copy it.

> I wish that were true, but many current laws say otherwise

I'm going to disregard this statement (and it's conspicuous lack of citations) because you're not a lawyer :)

> You're just hoping the world is as free as you say it is.

No, I'm just reading Wikipedia:

    Clean room design is usually employed as best practice,
    but not strictly required by law.

https://en.wikipedia.org/wiki/Clean_room_design#Examples

Re: Cross-platform Rust rewrite of the GNU coreutils

#319

Post by Dylan16807 » Tue, Mar 22, 2016, 9:33 PM UTC

pcwalton wrote: post #304

Dylan16807 wrote: post #292

Earlier quoted context omitted.

It was too ambitious. Some of those examples, like shifting by 32, are about trying to remove even unspecified behavior. If you could reduce most cases of undefined behavior down to "what some real machine would do", it would be an enormous help, and wouldn't be anywhere near as hard. For example you could say that division by zero will either give a result or trap, but that it can't do anything else, and the code pa…

> Or that an uninitialized variable is equivalent to initializing it with a semi-random number. This proposal destroys lots of dead code elimination optimizations that are very important in code post inlining (for example, in the STL).

Can you explain why? What if we relax it to say that copying from one uninitialized variable to another can be omitted?

Re: Cross-platform Rust rewrite of the GNU coreutils

#320

Post by JulianMorrison » Tue, Mar 22, 2016, 9:45 PM UTC

pcwalton wrote: post #231

weberc2 wrote: post #220

Earlier quoted context omitted.

> If you want to argue that Rust isn't worth it, you need to convince me that C plus gcov results in fewer bugs in the important areas in practice than Rust (plus kcov [1] if you like) does. I don't have a dog in this fight, but I don't see how the burden of proof is on Hipp rather than the folks proposing the change. In other words, shouldn't the "rewrite it in Rust" folks have to prove that the cost of their propos…

> In other words, shouldn't the "rewrite it in Rust" folks have to prove that the cost of their proposed rewrite will be justified? Agreed, they do. But that it hasn't been proven to make things better doesn't mean it will make things worse. It just means that we don't know enough to say. The right way to answer the "would this software have fewer bugs if it were rewritten in Rust?" question requires a detailed look…

A rewrite automatically makes things worse because you start with no code.

I figure it's one of the signs of programmer maturity, that you start to look askance at rewrites. So tempting, yet so rarely even finished let alone better.