jan kili (Sep 25 2022 at 08:46): jan kili (Sep 25 2022 at 08:46):A GNU Core Utilities app could be fun/useful :smiley:
https://en.wikipedia.org/wiki/List_of_GNU_Core_Utilities_commands
roc build coreutils.roc
cu cat foo.txt | cu tee bar.txt | cu split --separator=','
Useful for sure but also a lot of work, many commands have a large amount of options.
jan kili (Sep 26 2022 at 01:26):Is there any value beyond educational?
Brendan Hansknecht (Sep 26 2022 at 01:29):practicing making performant platforms? You need a really good base to make a fast unix util.
Brendan Hansknecht (Sep 26 2022 at 01:29):Especially around potential accidental copies (though might need to improve Roc with seamless slices before this really works well)
jan kili (Sep 26 2022 at 01:57):I'm sold! Perhaps starting optionless and then adding incrementally as priorities dictate would be sufficient.
jan kili (Sep 26 2022 at 01:59):I initially thought of this as an example app, but I changed my mind because it seems out of scope. When you say practicing, do you see CI/CD benchmarking value in it? or more like a useful third-party reference point?
jan kili (Sep 26 2022 at 02:02):Would forking the CLI platform raise the performance ceiling greatly, or would it be reasonable for this project to use that platform as-is and be a platformless repo? (beyond the prototyping phase)
jan kili (Sep 26 2022 at 02:05):Speaking of performance, this month I learned about turning on timing info logging during roc build with one of its flag arguments... does anything comparable exist for timing info during roc run or executable execution? Maybe that would require adding a time getter function to the platform and manually logging timestamps to stdout "from" the Roc app?
Brendan Hansknecht (Sep 26 2022 at 02:09):When you say practicing, do you see CI/CD benchmarking value in it? or more like a useful third-party reference point?
I was thinking third part reference, but depending how much of the performance is tied to roc optimizations, i could see value in CI. If it is mostly platform optimizations, i don't think CI is too useful
Brendan Hansknecht (Sep 26 2022 at 02:11):Would forking the CLI platform raise the performance ceiling greatly, or would it be reasonable for this project to use that platform as-is and be a platformless repo? (beyond the prototyping phase)
I would hope we could improve the cli platform and share. I don't think it is worth overly abusing a platform for max performance. I think we still want a great API and beginner friendliness with the performance.
Brendan Hansknecht (Sep 26 2022 at 02:13):does anything comparable exist for timing info during
roc run
I think the same flag should exist and print the same info
or executable execution?
I don't think roc rum should likely deal with this. That is more the job for hyperfine or just the general use time util on the output exe.
Maybe that would require adding a time getter function to the platform and manually logging timestamps to stdout "from" the Roc app?
If you are trying to time a subset of app executions, i think you should just get the current time from a platform and use it as you need.
jan kili (Sep 26 2022 at 02:15):just get the current time from a platform and use it as you need
Yeah, I was asking about timing between effects/functions, and that approach makes sense.
jan kili (Sep 26 2022 at 02:17):Perfect - any better start than me creating a JanCVanB/roc-coreutils repo and starting by naively implementing optionless cp/mv/rm commands?
jan kili (Sep 26 2022 at 02:18):Would be very fun to see how close we can get to native bash speed :sunglasses:
jan kili (Sep 26 2022 at 02:19):Though I'm more in it for the arg parsing, tbh
Brendan Hansknecht (Sep 26 2022 at 02:28):That sounds good. Also, you could make a platform specifically for benchmarking a roc function if you wanted, but that is only useful for non-io roc code
jan kili (Sep 26 2022 at 05:34):Let the party begin! https://github.com/JanCVanB/roc-coreutils
Brian Hicks (Sep 26 2022 at 12:44):this is maybe a hair late but it sounds like a busybox implementation rather than a coreutils one!
jan kili (Sep 27 2022 at 03:01):I've never heard of busybox until your mention of it, so thank you for that! It's a much more apt analogy, and perhaps a better comparison target (for size, speed, etc.)
jan kili (Sep 27 2022 at 03:01):Is there any reason not to retarget this project at mimicking busybox rather than gcu?
jan kili (Sep 27 2022 at 03:04):(and most importantly, of course... "rocbox" or "busyrox"??)
Brendan Hansknecht (Sep 27 2022 at 03:11):busybox probably makes more sense overall and is a common container target for something barebones. Not sure the perf of busybox vs gnu coreutils.
jan kili (Sep 27 2022 at 03:13):"better" target also because it seems more well-defined what it can do and how well it does those things. One definitive list of commands to mimic https://www.busybox.net/downloads/BusyBox.html#commands and one executable to compare perf against
jan kili (Sep 27 2022 at 03:14):plus significantly fewer options per command, so @Anton's point about extra work is alleviated significantly
jan kili (Sep 27 2022 at 03:45):Thank you very much for the redirect, @Brian Hicks !
jan kili (Sep 27 2022 at 04:17):... unrelated... apparently DuckDuckGo has figured out that I live in Boulder, and it hurts to be reminded about this for the first time in months :((( why?! what keyword overlaps?!
Screen-Shot-2022-09-26-at-10.14.37-PM.png
Brendan Hansknecht (Sep 27 2022 at 04:33):Yikes :flushed:
jan kili (Sep 27 2022 at 05:02):Repo updated: https://github.com/JanCVanB/rocbox
Brendan Hansknecht (Sep 27 2022 at 05:05):Rocbox makes me think of an emulator, kinda like dosbox or similar
Brendan Hansknecht (Sep 27 2022 at 05:05):Obviously a future game console
Kevin Gillette (Nov 04 2022 at 14:05):there are different niches. busybox is certainly the most well known, but targets binary size rather than performance, iirc.
toybox was created due to concerns about the use of busybox, after the fact, as gnu's license enforcement cudgel, and due to design and implementation concerns (there's a fair bit of drama in open source sometimes).
I don't believe either aim for full posix compatibility (there are some flags that never made sense, or were not widely used, or are but relevant on semi-modern systems).
I believe there are others that don't aim for posix correctness ("what if we could have done this differently?"), perhaps with a different arrangement of tools atop the same unix philosophy, or challenging parts or all of that philosophy (for example, there are several shells that have been built that utilize structured data streams rather than text streams).
We don't necessarily need more coreutils implementations (though more won't hurt, of course), so it'd really come down to what your interests are. Following the 90/10 rule, if you're aiming for full posix compatibility, then the first 10% of your effort would result in an implementation of the 90% of the commands and flags that are most often used, while the remaining 90% of your effort would be spent on the plurality of commands and flags that almost never get used.
Last updated: Jun 16 2026 at 16:19 UTC