Live data from Hacker News

Gonix – Unix tools written in Go

github.com

61–70 of 85 posts

Re: Gonix – Unix tools written in Go

#61
post #13

Forget the haters, this is awesome. GNU started as GNU's Not Unix, reimplementing Unix userland for free. The people who are adamant about calling it GNU/Linux are, on some level, remembering that the userspace is historically a reimplementation. Give me a busybox that I can 'go build' and that becomes really quite interesting.

Except for the fact that it'll be years before all of the subtle bugs are worked out and you can rely on those apps to be as stable as the ones we've got: http://www.joelonsoftware.com/articles/fog0000000069.html

Yeah, just because Joel said so doesn't mean it's true.

I've been responsible for a bunch of rewrites that were resounding successes and typically reduced the bug load (subtle or not) by orders of magnitude.

Re: Gonix – Unix tools written in Go

#62
post #57

It would be cool to have a "busybox" alternative targeted at Plan9 commands. I personally find Plan9 utils much more logical (and easier to implement!). Something like 9base from suckless, but as a single binary and hopefully in a more modern language (most of the code like sam or rc is not so easy to understand).

> I personally find Plan9 utils much more logical

Could you elaborate on that?

Re: Gonix – Unix tools written in Go

#64

Earlier quoted context omitted.

I must say that yours is much more complete than mine, though.

Work together! It would be great if complete coreutils was implemented!

I'd love some help. I'm juggling 3 side projects right now, and it's hard making time for all of them. :)

Re: Gonix – Unix tools written in Go

#65
Very neat. I started rewriting GNU's coreutils in Rust and find it to be a nice way to learn the language.

Also, it is interesting how many obscure and less-known features some of the tools provide. In this case I clearly see the 80/20 rule, you can implement 80% of the main functionality in 20% of the time, but if you want to make exact clones you're going to need invest a lot more time.

Re: Gonix – Unix tools written in Go

#66

Earlier quoted context omitted.

Or my rewrite of GNU's coreutils in Go: https://github.com/EricLagerg/go-coreutils It's not complete yet, but I couldn't pass up this thread :-)

I must say that yours is much more complete than mine, though.

I'd love if our projects could somehow work together. My contact info is in my account's description, so shoot me a message!

Re: Gonix – Unix tools written in Go

#67
post #13

Forget the haters, this is awesome. GNU started as GNU's Not Unix, reimplementing Unix userland for free. The people who are adamant about calling it GNU/Linux are, on some level, remembering that the userspace is historically a reimplementation. Give me a busybox that I can 'go build' and that becomes really quite interesting.

https://github.com/surma/gobox

Re: Gonix – Unix tools written in Go

#68
A few data points on GNU coreutils.

1. It has a fairly good test suite, that rewrites should leverage. That can be easily done by setting $PATH to prepend the dir of the new tools, and running `make check`

2. To give an indication of the size of coreutils:

$ for r in gnulib coreutils; do (cd $r && git ls-files | tr '\n' '\0' | wc -l --files0-from=- | tail -n1); done

985050 total 243154 total

Re: Gonix – Unix tools written in Go

#69

A few data points on GNU coreutils. 1. It has a fairly good test suite, that rewrites should leverage. That can be easily done by setting $PATH to prepend the dir of the new tools, and running `make check` 2. To give an indication of the size of coreutils: $ for r in gnulib coreutils; do (cd $r && git ls-files | tr '\n' '\0' | wc -l --files0-from=- | tail -n1); done 985050 total 243154 total

It's also worth pointing out, since busybox was mentioned a few times, that the latest release of coreutils has the ./configure --enable-single-binary option to build as a multi-call binary linke busybox etc.

Re: Gonix – Unix tools written in Go

#70

Heh, this brings me back. I was a young guy at Sun, perl 4 was a thing, I actually argued that we should redo /usr/bin in perl. In the days of a 20mhz SPARC. Silly me. Maybe it makes sense now.

I'm curious: what was your main motivation? I can understand it as a worthy challenge, but it would probably have led to a worse performance than the C-based utilities, no?

It would be pretty cool if all applications on your system were written as scripts, especially if they are very simple scripts, as it means you can open any of them in a text editor and see what they do.

It means you can modify any of them just as easily.

I remember one time when I needed information about how much CPU usage a program was using, I could see it in the output from `top`. So to figure out how `top` was getting that info, I had to download the source code, and grep through several .c files. If I could just `vim top`, and read the code, it would be very cool.

As an educational resource, being able to tell all your students "all binaries in /bin and /usr/bin are editable! Read them! Find out how they do what they do!" would be incredible.

Post reply on HN