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

Re: Cross-platform Rust rewrite of the GNU coreutils

#351

Post by Dylan16807 » Tue, Mar 22, 2016, 10:31 PM UTC

pcwalton wrote: post #321

Dylan16807 wrote: post #319

Earlier quoted context omitted.

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

Because uninitialized variables are allowed to change values arbitrarily over their (nonexistent) "live range". Your proposal would force them into having a real live range, with a stable value. See this section for an example, which shows examples of the kinds of optimizations this opens up: http://llvm.org/docs/LangRef.html#undefined-values There's also the issue that having a stable value forces the register alloc…

> Because uninitialized variables are allowed to change values arbitrarily over their (nonexistent) "live range".

Even specifying that they have a new arbitrary value on each access would be a big improvement over the status quo. It wouldn't allow nasal demons. Since LLVM seems to already have these semantics, it makes a good argument that it wouldn't hurt C's performance to tighten the spec at least that much.

But I'm not seeing how C or C++ code gets you in a situation where you're purposefully doing arithmetic or bitwise operations on uninitialized variables. If it almost never happens, it doesn't need to optimize particularly well. What parts of the STL can be faster by treating uninitialized variables as impossible?

> There's also the issue that having a stable value forces the register allocator to keep a live range for the undefined variable, which can cause unnecessary spills or remat in other places.

This would only happen when the variable is accessed multiple times. In which case having to keep the value safe is no worse than if it actually had been initialized. I don't see how this is a problem.

Re: Cross-platform Rust rewrite of the GNU coreutils

#352

Post by keeperofdakeys » Tue, Mar 22, 2016, 10:34 PM UTC

pjc50 wrote: post #5

The rationale talks about easy portability to Windows, but I'm skeptical - the underlying API and filesystem is different enough that this is likely to cause problems. '\' vs '/' to start with.

Most languages (including Rust), already support path libraries that abstract this away from you. As long as you use these libraries properly, you should never have these issues.

Re: Cross-platform Rust rewrite of the GNU coreutils

#353

Post by DannoHung » Tue, Mar 22, 2016, 10:35 PM UTC

JulianMorrison wrote: post #320

pcwalton wrote: post #231

Earlier quoted context omitted.

> 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.

In the case of Rust I don't believe this is 100% true given C ABI compatibility. You could start rewriting in such a way that it is integrated with the existing code and slowly, but surely tease the C out of the system.

Re: Cross-platform Rust rewrite of the GNU coreutils

#354

Post by z1mm32m4n » Tue, Mar 22, 2016, 10:36 PM UTC

gravypod wrote: post #162

yberreby wrote: post #124

Earlier quoted context omitted.

Autocompletion: YouCompleteMe + racer + racerd Source formatting: rust.vim + rustfmt Automatic building: https://github.com/passcod/cargo-watch Error display: tmux, terminator or iTerm2 split planes Rust has pretty good tool support in vim and Atom, for example (can't speak for the rest). We don't have stellar IDE support yet, but it's on the to-do list: https://www.rust-lang.org/ides.html Personally, I don't miss ID…

As I said, I don't want to learn how to use 5+ tools. I want to be able to install one thing, have everything work out of the box, and learn how to use their uniform and standard way of doing things.

I acknowledge that learning lots of tools just to start using a new language is a bit much.

However, the reason why so many people in this thread persist in suggesting that these tools are worth learning is that turns out most of these tools plug-and-play with whatever new language you feel like learning 6 months or 2 years or more from now.

Vim is one of the more popular editors to use in conjunction with this plug-and-play philosophy; if you have a change of heart and want to take a dive into learning to use Vim as such, I'd recommend Vim as an IDE[1], which addresses a lot of the points you brought up in your list of things you wish an IDE had.

[1]: https://github.com/jez/vim-as-an-ide

Re: Cross-platform Rust rewrite of the GNU coreutils

#355

Post by ehaughee » Tue, Mar 22, 2016, 10:36 PM UTC

jahewson wrote: post #294

jordigh wrote: post #276

Earlier quoted context omitted.

Are you a lawyer? Because other lawyers have told me otherwise. Would you happen to know of cases where your interpretation has been upheld?

Of course I can read something and not copy it. I can read a book and not copy it. I can listen to a song and not copy it. I can look at art and not copy it. And I can read source code and not copy it. It's not surprising that your lawyer implied otherwise, as its "best practice" to guard against every feasible risk, no matter how unlikely. Understand that your lawyer is protecting you against a hyper-zealous misinte…

Correct me if I'm wrong, but it seems like the original point here is not whether someone read the code and then contributed, but whether their contribution might (inadvertently or otherwise) contain Matlab intellectual property because they have been exposed to it. It seems a reasonable safeguard to prohibit those who have seen the source code from potentially contributing in a troublesome manner.

Re: Cross-platform Rust rewrite of the GNU coreutils

#356

Post by AnimalMuppet » Tue, Mar 22, 2016, 10:38 PM UTC

pcwalton wrote: post #330

wangchow wrote: post #314

Earlier quoted context omitted.

"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…

> 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. The last decade has seen an explosion of modern C++ code using best practices that routinely exhibits the same memory safety issues. C is worse. > There are definitely issues with C no doubt--but so many people say C i…

> The last decade has seen an explosion of modern C++ code using best practices that routinely exhibits the same memory safety issues.

Examples? I'd be surprised if best practice C++ (C++11, say) had memory safety issues. (I realize that's only the last half-decade...)

> C is worse.

Certainly. Lack of destructors alone makes it hard to create safe abstractions.

Re: Cross-platform Rust rewrite of the GNU coreutils

#357

Post by npizzolato » Tue, Mar 22, 2016, 10:39 PM UTC

jahewson wrote: post #285

jordigh wrote: post #226

Earlier quoted context omitted.

> This is very very weak grounds for any sort of lawsuit. Not according to the lawyers who have advised us GNU Octave developers to never read Matlab source code.

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.

You're giving a lot of strongly-worded advice/opinions on legal issues in this thread. Are you a lawyer? Can you point to any case-law to back up what you're saying?

I'm not a lawyer, and I don't really know who's right in this thread, but I'd find any citations you have really interesting to read.

Re: Cross-platform Rust rewrite of the GNU coreutils

#358

Post by _ph_ » Tue, Mar 22, 2016, 10:40 PM UTC

rmc wrote: post #317

_ph_ wrote: post #203

Earlier quoted context omitted.

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/

There are quite a few questions open here

- are they proven to use the library?

- did they modify it? - you can submit changes back only if you changed anything

- as it is server-side software, GPL had not changed much here, you have to provide the source of your program only to those who got delivery of that program, but that is not covering running on your servers.

- none of the licenses discussed require to donate money back, only source code changes.

So, yes, I think more companies should fund open source efforts when using open source software. The attention to OpenSSL and its security problems also showed how little funding that development got despite running most of the https on the internet. That indeed is scandalous. But this is covered by none of the current popular licenses.

Re: Cross-platform Rust rewrite of the GNU coreutils

#359

Post by viraptor » Tue, Mar 22, 2016, 10:41 PM UTC

jstimpfle wrote: post #346

viraptor wrote: post #340

Earlier quoted context omitted.

Rust allows you to specify the behaviour you want: Checked operations: https://doc.rust-lang.org/std/primitive.i8.html#method.check... Saturating: https://doc.rust-lang.org/std/primitive.i8.html#method.satur... Wrapping: https://doc.rust-lang.org/std/primitive.i8.html#method.wrapp... Wrapping with notification: https://doc.rust-lang.org/std/primitive.i8.html#method.overf... These apply to shifts too and you can tag t…

> If the requested behaviour is unspecified (just `a+b`), overflows cause runtime panic. As far as I know most machines can't trap on signed integer overflow. Which means having runtime panic is not practical. The page you linked says "no checking by default for optimized builds".

Ok, I simplified this too much. For full details of what happens you'll have to read the docs.

The non-release mode panics. Release mode with debug asserts turned on panics. Release mode with forced overflow checks panics. Release mode with no special options results in the same result as a wrapping operation.

Re: Cross-platform Rust rewrite of the GNU coreutils

#360

Post by pcwalton » Tue, Mar 22, 2016, 10:41 PM UTC

DrJokepu wrote: post #347

pcwalton wrote: post #333

Earlier quoted context omitted.

I don't miss the things you mentioned very much, and I think it's an exaggeration to say that these things are what makes Rust's standard library not usable for anything serious. But anyway: > There is no way to select over a range of TcpStream objects. mio > There is no stable way to select over a range of mpsc channels. Yes, this is annoying. We should stabilize MPSC select. You can use BurntSushi's chan for now th…

Mio is not part of the standard library. Go, for example, has excellent support for UNIX signals.

So I think our disagreement is semantic. When you say the Rust standard library is "unusable", you mean that you usually need Cargo packages in addition to what the standard library provides in order to write programs in Rust. That is true, but that's just a design difference between Rust and some other languages, like Go. For a systems language like Rust, I think that focusing on having an excellent package manager instead of having a super-comprehensive standard library was the right call. The standard library is very well designed for what it does (IMHO), and I credit the community-based library stabilization process for that.

As for Go and signals, I think it's pretty debatable as to whether you can have "excellent support" for signals without the ability to write a true signal handler. Note that this is not a fault of Go and is pretty much inherent to any garbage collected language. I suspect the Rust community would not be particularly happy with an implementation of signals that had hardwired sending to MPSC channels. Even having MPSC channels in the library at all is somewhat controversial...