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

161–170 of 498 posts

Re: Cross-platform Rust rewrite of the GNU coreutils

#161

Post by dikaiosune »

steveklabnik wrote: post #60
saosebastiao wrote: post #50

Earlier quoted context omitted.

I learned how to program without an IDE, and I'm a pretty big fan of it. And strongly typed functional languages with type inference tend to be really easy to write and refactor without needing specialized IDE tasks for the job. That being said, nowadays I use an IDE because it is extremely helpful to have autocomplete (which is okay with Racer+Vim, but kinda hacky) as well as the hover for type information (name of…

[this post was wrong]

Isn't it the other way around? One can downvote a post and then reply to it, but can't downvote replies to one's own post?

Re: Cross-platform Rust rewrite of the GNU coreutils

#162

Post by gravypod »

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…

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.

Re: Cross-platform Rust rewrite of the GNU coreutils

#163

Post by TheCoelacanth »

codedokode wrote: post #134
0xFFC wrote: post #127

Earlier quoted context omitted.

>Also Rust doesn't have exceptions so you have to wrap almost any function call with let/match/Ok/Err. Ugly. respectfully, This is pure nonsense. First of all rust does not have runtime and AFAIK for providing exception you should have runtime to manage stack. Second not every language should be like high-level languages, it is not the rule to be like C#,Java,Python,etc. I use a lot of them for my work when I need si…

I mean if you have to write that match construct around every function call the code quickly gets bloated, doesn't it? And that is not good.

try! macro results in code that looks pretty similar to exceptions: https://doc.rust-lang.org/std/macro.try!.html

Re: Cross-platform Rust rewrite of the GNU coreutils

#164

Post by gbersac »

stepvhen wrote: post #48
gbersac wrote: post #11

Is there a real need for this project ? I mean, this project has been used for a long time, could it really be better ? Do you intend to replace GNU coreutils ? Not to be mean, just a genuine question (and yes I read the Why section of the readme).

Multiple people have sought to rewrite coreutils, whether it be for fun, exercise, or out of frustration with the current utils. I know folk on 4chan's /g/ were rewriting them once, and the people at suckless are trying to do the same, only with a lot of options and features stripped out due to "bloat" (my word not theirs). Your second question presumes that just because something is old means it is the best. Traditi…

It is a rewrite of gnu coreutils because cureutils sucks. It is a good reason !

I guess it doesn't intend to be a 1:1 rewrite of coreutils then ? The public available function to users will be rewrote.

Re: Cross-platform Rust rewrite of the GNU coreutils

#165

Post by masklinn »

codedokode wrote: post #134
0xFFC wrote: post #127

Earlier quoted context omitted.

>Also Rust doesn't have exceptions so you have to wrap almost any function call with let/match/Ok/Err. Ugly. respectfully, This is pure nonsense. First of all rust does not have runtime and AFAIK for providing exception you should have runtime to manage stack. Second not every language should be like high-level languages, it is not the rule to be like C#,Java,Python,etc. I use a lot of them for my work when I need si…

I mean if you have to write that match construct around every function call the code quickly gets bloated, doesn't it? And that is not good.

> I mean if you have to write that match construct around every function call

Not quite.

1. you're supposed to handle errors around function calls which can fail, which is a strict subset of "every function call"

2. rust has a number of higher-order constructs to facilitate that handling[0][1][2], not just raw `match` statements or expressions.

That aside, for rust explicit error handling is considered a feature both at the language level (allows for less runtime requirements and much stronger guarantees — check out exception-safe C++ for what happens when low-level meets exceptions) and at the user level (by forcing a conscious and explicit decision, whether it's crashing the system, handling the error or passing the ball upwards)

> the code quickly gets bloated, doesn't it?

Does C code quickly get bloated? Because you're also supposed to check for error codes after each function call which can fail, and C doesn't provide much abstractive power to mitigate that.

[0] http://doc.rust-lang.org/std/result/enum.Result.html

[1] http://doc.rust-lang.org/core/macro.try!.html

[2] https://github.com/rust-lang/rfcs/pull/243

Re: Cross-platform Rust rewrite of the GNU coreutils

#166

Post by oldmanjay »

wangchow wrote: post #160
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.

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'm not entirely clear on your point. Are you suggesting that writing in C as opposed to Rust is somehow morally cleansing? Or are you suggesting that having higher level abstractions is somehow ruinous to ability?

The evidence is pretty clear that programming in C does not confer enough skill to prevent disastrous mistakes despite its near-hardware level of abstraction, so I'd really like to know what you're saying here.

Re: Cross-platform Rust rewrite of the GNU coreutils

#167

Post by nickpsecurity »

masklinn wrote: post #39
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.

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

Wow. I was surprised that comment came from a smart, accomplished guy. It's nonsense. What he's essentially saying that the existence of compiler bugs in Rust refutes using it as a C alternative. Let me try that: the existence of hundreds of compiler bugs in C compilers over past years means it can be relied on either. CompCert had a few at spec level so we throw it out, too.

Realistically, you rewrite the components piece by piece in the new language. You make sure each compiles right with testing and review. You report any problems to the compiler team, who fixes them. Eventually, you're whole app is in the safer language without a lot of work. You might even swap them where safer one becomes reference code with other one there for any platforms not supported yet or too buggy. A diversity benefit as Hipp mentions.

With all of this, the program becomes immune to most memory & concurrency issues while being easier to maintain. Its undefined behavior will probably be a fraction of C's in number and severity. That's a net win.

Note: I'd have told him Ada/SPARK instead of Rust given it's been stomping C in embedded safety for a long time w/ lots of tooling for verification activities already there. Counters his compiler maturity argument, too.

Re: Cross-platform Rust rewrite of the GNU coreutils

#168

Post by m0th87 »

wangchow wrote: post #160
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.

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 programmers would only code on assembly.

> Programming becomes easy but in the long term most people forget how algorithms and data structures work, in addition to cache mechanisms and other optimizations.

Why would higher level languages obviate knowledge of any of these things? If anything, I think it would help by reducing "noise" from incidental complexity; e.g. ownership in C vs Rust.

Re: Cross-platform Rust rewrite of the GNU coreutils

#169

Post by dikaiosune »

gravypod wrote: post #93
wyager wrote: post #25

Earlier quoted context omitted.

You could just use atom and install some rust plugins.

I would, but the last time I installed atom and tried to start it the base text editor, without any added plugins, took 3 minutes to start and used ~600mb of system memory. In comparison, Eclipse starts in under a minute and uses about half that on my system. Atom when I tried it was much to large for my system. I might look at it again.

They've done some decent optimizing in the last few releases. I'm finding it much more responsive than it used to be.

Re: Cross-platform Rust rewrite of the GNU coreutils

#170

Post by Santosh83 »

niccaluim wrote: post #37
gravypod wrote: post #21

I'd really love to use rust, given the large growth of projects like this. I only need an IDE to get started, but it seems like there isn't one yet. Anyone have any pointers on where I can find a good IDE for Rust? Should I just start praying to lord-JetBrains for something that works?

If you've never programmed without an IDE I strongly encourage you to give it a go. You'll learn a lot! [Good lord, a downvote on this? I'm being completely sincere.]

True. I taught myself C using vim + gcc under Linux. For those wondering what exactly you learn:

1. You learn the command line interface to your compiler, which is invaluable and something you'll have to learn at some point, even if you start off on an IDE.

2. Similarly you learn the command line interface to the compiler's support tools like make, linker, debugger, profiler, source code revision control, grep, strings and so on, and more importantly how the whole process of 'write-compile-execute-debug' cycle is done.

Post reply on HN