Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cross-platform Rust rewrite of the GNU coreutils

github.com

Post reply on HN
Print view View original

211–220 of 498 posts

Re: Cross-platform Rust rewrite of the GNU coreutils

#211

Post by zwischenzug »

aidenn0 wrote: post #142
gkya wrote: post #109

Earlier quoted context omitted.

For my use case, it's way more preferrable: a) SVN seems daunting and complex, tho I didn't ever dive into it. CVS is so simple and easy, a half-arsed programmer like me can actually understand it. Things like git and mercurial are way more complex. b) RCS is real handy for single files, e.g. a free-standing text file or shell script. But when the thing grows up, it is very easy to integrate the fileset into a CVS re…

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.

Re: Cross-platform Rust rewrite of the GNU coreutils

#212

Post by steveklabnik »

andrepd wrote: post #187
thegeomaster wrote: post #12

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.

If equivalent Rust code is significantly slower than C or C++, it's a bug. Please file them if you find them.

Re: Cross-platform Rust rewrite of the GNU coreutils

#213

Post by lomnakkus »

jfoutz wrote: post #103
masklinn wrote: post #39

Earlier quoted context omitted.

I expect it's because because the first part is essentially preaching to the choir, and because Richard Hipp very much disagrees with the second part[0] > Rewriting SQLite in Rust, or some other trendy “safe” language, would not help. In fact it might hurt. (see link for expansion on that matter, which is a question of tooling and testing) [0] http://blog.regehr.org/archives/1292#comment-18452

The quality of tooling, and the ability of experts to verify the output of machine code is a really important point. I think I'd agree, rust at this point would hold back an elite developer like Richard Hipp. The promise of rust, which may or may not be realized is pushing some very common problems down to the compiler. All code has bugs, so the compiler probably does things wrong in some cases. As the tools mature,…

> C requires you to be really smart all the time, or at least be aware of when you're not smart enough to get a chunk of code right.

It's not so much that it requires smarts. It's that is requires you to be ever-vigilant and to never make any mistakes. (That's why UB and bounds overflows are so devastating to software security. Almost any slip-up by the developers can be exploited.)

Incidentally, the ever-vigilant bit is also why we really want compilers to be doing the bounds-checking (or proving that it isn't necessary). Compilers are really good at being ever-vigilant. Humans (no matter how smart)... not so much.

Re: Cross-platform Rust rewrite of the GNU coreutils

#214

Post by jordigh »

mapleoin wrote: post #22

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?

Reading GPL'ed code and reimplementing it makes a good case for why the rewrite should also be GPL'ed. I don't know if they did this here, but if so, they should GPL their version as well.

For GNU Octave, we stress very strongly that anyone who has read Matlab's source code is ineligible to contribute to Octave. This is because, should it ever come down to it, we want to be able to ascertain that our implementation is completely original, because nobody has read Matlab's source code. In a similar vein, I'm still waiting[1] for someone to implement the medcouple for Python's statsmodels, because I cannot do it myself.

--

[1] https://groups.google.com/forum/#!topic/pystatsmodels/LpsmIJ...

Re: Cross-platform Rust rewrite of the GNU coreutils

#215

Post by mikevin »

yberreby wrote: post #124
gravypod wrote: post #64

Earlier quoted context omitted.

Here are the features I like in an IDE that make be very productive: - Autocompletion - Mass rename - Source formatting - Integrated debugger interface with breakpoint insertion and overlying of state on source - Integrated VCS control - Automated deploy - Error display - Automatic importing of modules - Source cleanup (Automatic loop transformation) - Automatically building my project That's just a few things that I…

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…

Do you use all of the autocompletion options you listed? Or is YCM with --racer-completer enough?

Re: Cross-platform Rust rewrite of the GNU coreutils

#216

Post by steveklabnik »

aidenn0 wrote: post #135
steveklabnik wrote: post #118

Earlier quoted context omitted.

The Rust standard library does assume that allocation succeeds. The language itself knows nothing about the heap, and so you can write allocators that do whatever you wish. Side note: on most Linux distros, overcommit is on, and so malloc will basically always succeed; the OOM killer will kill your program before you'd get a failure. I am less knowledgeable about OSX and Windows. I cannot speak to SQlite in this rega…

Even with overcommit on, malloc can return NULL on linux.

liballoc does check for NULL IIRC.

Re: Cross-platform Rust rewrite of the GNU coreutils

#217

Post by jordigh »

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

> Todays reality has Microsoft and Apple sharing part of their codebase under permissive licenses.

In that case, they should have no problem sharing it back under a copyleft license either.

Re: Cross-platform Rust rewrite of the GNU coreutils

#219

Post by jordigh »

thedevil wrote: post #111
mapleoin wrote: post #22

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?

Does anyone have more solid info on whether the GPL would apply in this case? I would really like to know if licensing agreements (and copyrights) still apply to ported code (assuming there's no patents on the algorithm).

> Does anyone have more solid info on whether the GPL would apply in this case?

It would if they did indeed read GPL'ed code to implement this. The SFLC has advised us to make sure we do not read Matlab code when implementing Octave code. The only thing that is known to legally work is clean-room reverse engineering. It's ok to read independently-written specifications of how the software works and reimplement that. Reading the software itself and reimplementing it constitutes a strong case for derivative work.

Re: Cross-platform Rust rewrite of the GNU coreutils

#220

Post by weberc2 »

pcwalton wrote: post #95
masklinn wrote: post #39

Earlier quoted context omitted.

I expect it's because because the first part is essentially preaching to the choir, and because Richard Hipp very much disagrees with the second part[0] > Rewriting SQLite in Rust, or some other trendy “safe” language, would not help. In fact it might hurt. (see link for expansion on that matter, which is a question of tooling and testing) [0] http://blog.regehr.org/archives/1292#comment-18452

Disappointing to see Hipp make that argument. It's trivially refuted. Yes, all programming languages allow the programmer to write bugs. But languages very much vary in how many , and what kinds of bugs programmers write in practice . Saying "well, Rust doesn't eliminate all bugs" is attacking a straw man. 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…

> 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 proposed rewrite will be justified?

Post reply on HN