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

241–250 of 498 posts

Re: Cross-platform Rust rewrite of the GNU coreutils

#241

Post by binarycrusader »

_ph_ wrote: post #209
binarycrusader wrote: post #114

Earlier quoted context omitted.

Realistically? Never. If you're running on a UNIX system, libc is your only portable interface to the system. You can use the syscall layer on some NIX-like platforms (such as Linux), but it will leave you to replicate a lot of the work that it already does. On Solaris, as one example, there is no stable syscall layer -- libc is your only interface to the system. There's good reason for that too; on Solaris, libc is…

Most of the Go codebase is portable across systems without using libc, so being libc free is definitely possible.

No, on Solaris Go uses libc. I know because I am one of the people that worked on the port.

Windows is similar in that regard to a degree as well.

Re: Cross-platform Rust rewrite of the GNU coreutils

#242

Post by spaceheeder »

rhelmer wrote: post #173

Redox has been working on smaller, more BSD-like versions of the basic Unix utilities, also written in Rust: https://github.com/redox-os/coreutils I am excited to see this as I was working on a similar project last year (rewriting the BSD userland in Rust), but it's from pre-1.0 Rust so not really as idiomatic as what is coming out of the Redox project.

From the README: "These are based on BSD coreutils rather than GNU coreutils as these tools should be as minimal as possible."

If all of these utilities are running in userspace, per Redox's microkernel architecture, then what is the advantage of intentionally not making them feature-rich?

Re: Cross-platform Rust rewrite of the GNU coreutils

#243

Post by wangchow »

oldmanjay wrote: post #166
wangchow wrote: post #160

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

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 this simplicity, unit-testing is very easy yet lots of legacy codebases don't use these testing strategies to their potential. If they did lots of issues would be corrected.

Although I cannot refute there are additional memory-related issues to be aware of in C, it is precisely such awareness that make someone a better programmer because its how the underlying hardware works. For instance, parallelizing algorithms must take into account cache-alignment boundaries and so on.

Abstractions are good. However, too much abstraction is bad. Just as too much of anything is a bad thing. When people rely solely on such abstractions, it is in fact ruinous to ability.

That being said, higher-level languages certainly have their place. But I firmly believe that C is a high-enough abstraction for systems programming and with proper idioms and testing strategies, it can be just as safe as the plethora of garbage-collected languages out there in the wild.

Re: Cross-platform Rust rewrite of the GNU coreutils

#244

Post by _ph_ »

jordigh wrote: post #217
_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…

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

Well, there is a huge problem - copyleft does not only require you to share changes to the source you used and modified, but also to unrelated source of your own. Which kills it for most corporations. Some of their code might contain trade secrets or just isn't freely relicenseable by them as it might involve third party rights. Which is why LGPL mostly works for corporations but GPL not.

Re: Cross-platform Rust rewrite of the GNU coreutils

#245

Post by wangchow »

m0th87 wrote: post #168
wangchow wrote: post #160

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…

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

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 this simplicity, unit-testing is very easy yet lots of legacy codebases don't use these testing strategies to their potential. If they did lots of issues would be corrected.

Although I cannot refute there are additional memory-related issues to be aware of in C, it is precisely such awareness that make someone a better programmer because its how the underlying hardware works. For instance, parallelizing algorithms must take into account cache-alignment boundaries and so on.

Abstractions are good. However, too much abstraction is bad. Just as too much of anything is a bad thing. When people rely solely on such abstractions, it is in fact ruinous to ability.

That being said, higher-level languages certainly have their place. But I firmly believe that C is a high-enough abstraction for systems programming and with proper idioms and testing strategies, it can be just as safe as the plethora of garbage-collected languages out there in the wild.

Re: Cross-platform Rust rewrite of the GNU coreutils

#246

Post by pcwalton »

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…

> It's quick, but detrimental (to programmers ability) in long term.

Do you know how the lifetime/borrow check system works?

I've heard plenty of criticisms of it, but I've never heard "the lifetime system doesn't make you understand manual memory management".

Re: Cross-platform Rust rewrite of the GNU coreutils

#247

Post by cname »

ChristianBundy wrote: post #188
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.

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.

What on earth does the GPL have to do with owning _ideas_? Please explain.

Also, do you think that Linux, for example, is draining the world's resources? If so, how?

Re: Cross-platform Rust rewrite of the GNU coreutils

#248

Post by dikaiosune »

frutiger wrote: post #235
dikaiosune wrote: post #159

Earlier quoted context omitted.

Is the cygwin port just some different build files, or is it genuinely different code? A Rust codebase probably wouldn't (in most cases) need to be modified to run on different supported platforms.

I'm not going to comment about cygwin (because its build process is not as transparent) but instead about msys2, the spiritual successor to cygwin. See for yourself: https://github.com/Alexpux/MSYS2-packages/blob/master/coreut... is the `pacman` style `PKGBUILD` used to build the `coreutils` package.

That looks pretty clean, but they're still applying looks like 5 patches which would need to be maintained separately. It's certainly not as bad as a full port, but it's still not the same codebase. Rust's cross-platform efforts would (I think?) obviate that process.

Re: Cross-platform Rust rewrite of the GNU coreutils

#249

Post by krylon »

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

> That said, array bounds checking is responsible for so many problems, it seems worth it to raise the minimum for a language.

Amen to that! If I could just add one feature to C - at least as an option - it would be array bounds checks.

I have no trouble with manual memory management - a garbage collector is nice to have, but I have not had many problems with memory leaks or dangling pointers. And the ones I had were relatively easy to locate and fix.

But array bounds violations are so easy to commit and so nasty to track down... When I still wrote C code for a living, I would have gladly sacrificed quite a bit of performance to get bounds checks on all array accesses, at least for testing and debugging...

Re: Cross-platform Rust rewrite of the GNU coreutils

#250

Post by pcwalton »

wangchow wrote: post #243
oldmanjay wrote: post #166

Earlier quoted context omitted.

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…

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-alignment boundaries and so on.

…which Rust makes you just aware of as C does.

> But I firmly believe that C is a high-enough abstraction for systems programming and with proper idioms and testing strategies, it can be just as safe as the plethora of garbage-collected languages out there in the wild.

1. Rust isn't garbage collected.

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

Post reply on HN