cw | shake | |
---|---|---|
5 | 11 | |
100 | 756 | |
- | - | |
0.0 | 6.7 | |
over 1 year ago | 4 months ago | |
Rust | Haskell | |
MIT License | BSD 3-clause "New" or "Revised" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
cw
-
why GNU grep is fast
For things that are commonly and almost-ideally represented as text files, there’s a lot of Rust based alternatives are faster and have more features than the old unix/GNU tools: ripgrep, fd, cw, and you can find more in this list.
-
A wc clone, written in Go
Nice, beats my old Rust wc through sheer brute force on my old 12c/24t server:
-
How to learn Rust by own tiny applications?
A lot of unix-y tools have been rewritten in rust, where the usefulness comes from it being faster or having more features. Examples: bat, cw, lsd, ripgrep, diskonaut, gping. Maybe you could find an interesting program to rewrite?
-
Awesome Rewrite It In Rust - A curated list of replacements for existing software written in Rust
cw, an optionally-multithreaded bytecount-accelerated wc clone
-
Debian Running on Rust Coreutils
Having written a Rust wc implementation a few years ago (https://github.com/Freaky/cw), I had a look at theirs.
It's pretty naive - a simple linewise read_until loop, a conditional to avoid word splitting and such if it's not needed, and for some reason it collects results into an array and prints when it's done rather than printing as it goes.
It doesn't support --files0-from like GNU wc, so isn't a drop-in replacement from that perspective. It also has the sadly common Rust trope of only supporting filenames that are valid UTF-8.
It doesn't seem overly slow considering its simplicity - usually trading blows with GNU and BSD wc. Perhaps the most glaring omission is the lack of a fast path for -c, which should reduce to a stat() call. Also unfortunate not to use the excellent bytecount crate to provide a very fast -l/m path.
The read_until loop also makes its memory use unpredictable compared with other wc's. If you run it on /dev/zero it will try to eat your computer.
shake
-
Ninja is enough build system
Another interesting implementation is Shake: https://shakebuild.com/
It is technically a Haskell DSL, but supports Ninja files, time estimates and has tools for linting and profiling.
-
Buck2: Our open source build system
They explicitly refer to Shake build system and Build Systems a la Carte paper.
-
Straightforward Makefile Tutorial that bring together best practices once and for all.
The one paper that gave me hope about build systems was Build systems à la carte: Theory and practice, by Andrey Mokhov, Neil Mitchell, and Simon Peyton Jones. Among other things, it describes the theoretical underpinnings of the Shake build system. To be honest I believe any build system that ignores the maths described in this paper can safely be ignored. (You may however ignore the paper itself if the maths checks out. See Daniel J. Bernstein's redo, which matches Shake very closely.)
-
Worst language you ever used? Really used not just looked at the manual.
Yeah, they don't have to be terrible. I haven't used it, but people in my circles tend to really like Shake, which uses a Haskell embedded DSL to describe builds.
- Shake Build System
-
Strengths, weaknesses, opportunities, and threats facing the GNU Autotools
You could try Shake. It's a sane build system written by a former co-worker of mine. https://shakebuild.com/
-
Overview of the CMake controversy, and break down the pros and cons of the critical C++ tool.
Shake does require compilation as it's essentially just a Haskell library providing a DSL and it works just fine, I guess in gradle's case it's a thing about Java-typical overengineering and complete blindness to resource usage. Shake's underlying engine can actually go head-to-head with ninja itself when building ninja files.
-
Need recommendations for a dependency-tracking system
Did you look at shake: https://shakebuild.com/ ?
- The Shake Build System
-
Trouble Linking Dynamic Library for Package
For reasons I don't want to get into, I am building my own GHC package without cabal. The documentation is a little sketchy, but I've succeeded in build and installing it in my own user database (I'm on linux x86_64, using GHC 8.6.5). I am using shake to do all of this, and I've been pretty pleased with how it works.
What are some alternatives?
gping - Ping, but with a graph
gitHUD - command-line HUD for your git repo
CompactGUI - Transparently compress active games and programs using Windows 10/11 APIs [Moved to: https://github.com/IridiumIO/CompactGUI]
marvin - The paranoid bot (framework)
regex - An implementation of regular expressions for Rust. This implementation uses finite automata and guarantees linear time matching on all inputs.
leksah - Haskell IDE
ht - Friendly and fast tool for sending HTTP requests
shake-language-c - Cross-compilation framework based on the Shake Haskell library.
nushell - A new type of shell
bumper - Haskell tool to automatically bump package versions transitively.
awesome-rewrite-it-in-rust - A curated list of replacements for existing software written in Rust [Moved to: https://github.com/TaKO8Ki/awesome-alternatives-in-rust]
clone-all - clone all the github repositories of a particular user.