51–60 of 85 posts
Earlier quoted context omitted.
I don't know much about go, but taking a quick look at implementations - they seem to be written by a programming novice, and the are quite primitive. Don't mean to be negative, just my opinion.
I am a novice, and that is one of the reasons why I started this project (to learn).
Earlier quoted context omitted.
bytes, _ := ioutil.ReadAll(os.Stdin) lines := strings.Split(string(bytes), "\n") Tip: use bufio.Scanner. scanner := bufio.NewScanner(reader) scanner.Split(bufio.ScanLines) for scanner.Scan() { // Do stuff } And you can iterate over the lines 'lazily'. If you don't want to consume \r's, make your own ScanLines :).
[deleted]
I like Scanner because it provides a nice high-level interface, but still maintains an internal buffer, reducing GC pressure. Of course, it's not one size fits all.
Earlier quoted context omitted.
We really need a busybox in Rust or Go. The existing one has licensing problems and security problems, and is built into too many embedded devices.
Busybox is GPLv2. That's the same license as the linux kernel; it's not a problem. You just have to release your modified version of the busybox source if you distribute it in a product. The only difference is that busybox developers enforce the license against the many companies who can't be bothered and respond to requests with lawyers. That said, a bsd-licensed re-implementation of busybox (still in c) that's pret…
Why do Go programmers always want to redo everything? It's rare to see something actually new written in Go, proving that Go can do everything C can (except make shared libraries and produce small binary sizes) but not that it's actually better .
If C is still present in the stack, the typical C exploits are possible, which were how many Oracle JVM exploits came to be, for example.
Reducing C presence to the same as Assembly, will just make everything safer in our systems.
Not that it will ever happen in UNIX systems, given how C came to life.
Earlier quoted context omitted.
[deleted]
You mean bufio.ReadLine? As the documentation says, it's low-level, since you have to do the buffer allocation yourself. ReadBytes/ReadString are nicer interface-wise, but it allocates new buffers on every call. I like Scanner because it provides a nice high-level interface, but still maintains an internal buffer, reducing GC pressure. Of course, it's not one size fits all.
I can see now how much of a difference it can make on a really large file, like in the gigabyte range.
BTW, I deleted my earlier comment because the problem I had wasn't anything to do with bufio. I had just made an obvious mistake elsewhere in my code, which I've fixed now.
Earlier quoted context omitted.
I am a novice, and that is one of the reasons why I started this project (to learn).
bytes, _ := ioutil.ReadAll(os.Stdin) lines := strings.Split(string(bytes), "\n") Tip: use bufio.Scanner. scanner := bufio.NewScanner(reader) scanner.Split(bufio.ScanLines) for scanner.Scan() { // Do stuff } And you can iterate over the lines 'lazily'. If you don't want to consume \r's, make your own ScanLines :).
And you may want to mmap the file, rather than open it. Whether that is a speeds up things depends on OS, OS version, file size, file system, available memory, phase of the moon, etc.
Not meaning to bring up a Rust vs Go debate, but since there are a few comments claiming that this is a waste of time, I figured it's worth mentioning the Rust based re-implementation of coreutils: https://github.com/uutils/coreutils/ And another by suckless in plain C: http://git.suckless.org/sbase/tree/README
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.
There's "Perl Power Tools: Unix Reconstruction Project" [0], which doesn't seem to have activity since 2004. I remember something older than 2004, I think, back from when perl was first available on Windows, to bring UNIX command line utilities to Windows through perl. It's great that they all have inline POD documentation too. [0] http://search.cpan.org/dist/ppt/
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.