Common *nix commands written in Rust
gcollazo.com
gcollazo.com
Uh, because squinting at blue-on-black text is much more difficult. Human eyes focus best at yellow-green, they see that as brightest, and they don't even have long-wavelength (blue) receptors in the fovea.
I also looked at the alternatives to ps, top, cat, find, and du.
My overall feeling is that these are really not like UNIX tools at all. They are not very scriptable. Output is full of Unicode, color, column dividers, headers, underlining, and pagination. Values are in so-called "human readable" form, like "1.4M" instead of 1474560 or whatever it may be, which is a real pain for scripting.
I also notice some features that seem out of place to me, a long-time UNIX user. The tools waste space on displaying things related to git, docker, and network connections. I would expect the proper tools to be more like "git ls", "docker ls", "docker ps", and "netstat -p". (for those ones that don't actually exist, take that as a suggestion for a coding project) Not all the world is devops on a web site.
Terrible color combinations for text: blue/black, magenta/red, cyan/green, white/yellow.
The example uses blue/black.
Very UNIX-y imo.
There are still quite a few folks out there who don't know about Rust, Go, or anything else that's gotten popular over the past few years here.
A year or so back I found out that I got passed over for an embedded job because I had a big emphasis for Rust on my side projects and they thought it was a toy GCed language and a weird anachronism to put on there.
Rust has long been something intellectually interesting (solving memory issues found in C and C++, while keeping their low level and with equal performance is quite a feat), but it recently started to become affordable to use (libraries are maturing, there's tons of quality learning material, and even the language itself reached a level of polish that was simply not here before), then many people who have had it somewhere on their radar for a while took the leap, and now share their enthusiasm. And the interested ones who are still waiting for a good occasion to learn it upvote and then it ends up on the front page. And now, you get this kind of low-quality content, which is merely surfing on the trend to get some clicks.
This kind of things happened with Go a few years back, or with node before that, such is the fashion life of the programming world.
I am not sure why some programmers think, complex and convoluted the syntax, the better the language, especially taking rust as an example. Go has been successful in it’s niche as systems programming language because it’s syntax is easy and can fit the brain easily. A similar simple good programming language I see is zig language which makes memory safety as a choice for the programmer to implement rather than forcing on them with complex borrow checker syntax. On top rely of unsafe C library and code to do anything useful. Zig eschews complexity and embraces C with simple syntax and semantics and provide easy tools to build memory safe code and not shoot the foot. But anyways like democracy in programming complicated languages can win due to majority by marketing or in fashion.
Zig helps programmer with tools to write memory safe programs by not shooting in foot with sane and easy syntax and memory allocator. Still like Rust it needs to prove, so time will tell whether marketing and fashion or simplicity and sanity wins. There are enough examples where fashion and marketing with minuscule benefits did win.
Nine times out of ten a network server isn't systems programming. And even at google, golang is starting to be banned for real systems use by some projects.
> Rust rely on underlying C library for doing anything useful today
Go relies on libraries everywhere except Linux too, because that's where the stable boundaries are.
And even in Linux it was a bad plan for them not to rely on the C lib, because they miss out on other system configuration stuff like locale information because of their choices there.
> Zig helps programmer with tools to write memory safe programs by not shooting in foot with sane and easy syntax and memory allocator.
So.. the same way C does?
Quite curious. Got a source? Would like to read more on that.
Actually I don't really understand why some people complain about Rust syntax. The only alien thing is the lifetime ('a) syntax, but you don't need it that often, and the concept behind it is way more difficult to learn than the syntax itself (and it's where Rust's breakthrough comes so you have to learn this concept anyway).
Is there a place where I can read more on this?
It's quite hard to see how these bugs will come from 'the syntax is complicated'. For one, the syntax is simpler than C++, and secondly, complex syntax is not necessarily a cause of bugs: Rust is not prone to errors in syntax becoming runtime bugs.
There are fast implementations (C) and there are somewhat safe implementations (Python, Java, ...). If I were to place Rust in this hierarcy - it is both fast AND safe, and there's rarely a good reason to replace it, so you've software that's already at the top of the hierarcy. This means that the particular implementation is likely to be the one that doesn't get replaced.
"...in Rust" has a lot of implications other than being an exercise in marketing.
There's also some advocacy involved which many people obviously find distasteful. To me it's a bonus though: tell me why your tech choice makes a difference, I'll check and maybe learn it.
Anything wrong what that?
We don't need to re-stratify development so that only people with expensive computers with > 4 gigs of memory can compile what they run.
Now, by default the "cargo" build uses all CPU threads, so if you have a 32 core Threadripper then yes, running 64 simultaneous "rustc" compiles will use 6 or 7 gigabytes.
That's one of the reasons it was rejected in OpenBSD: https://marc.info/?l=openbsd-misc&m=151233345723889&w=2
"> 4 gigs of memory"
https://www.ebay.com/sch/i.html?_fsrp=1&_nkw=computer&_sacat...
by my standards, $5 is not an "expensive computer".
and more to the point, the language has little to do with the compilation memory required. Firefox and Chrome require significantly more memory than that to compile nowadays; they passed the 4 GB mark that could be compiled on a 32-bit machine many years ago, and both Firefox and Chrome were written entirely in C++ at the time. furthermore, you can always enable swap. it'll be slow, but if you can't afford a $5 computer, you take what you can get.
If the compiler targets multi-cores and the language helps express implicit parallelism or asynchronous code possibilities which map to multi core, better than the original language, then thats net beneficial too.
If the language encourages coding patterns which are extensible or re-usable, then its possible the runtime code state gets smaller as increased use of shared code patterns leads in the longer term to more COW shared libraries.
This may be not as important in a replacement for `less` or `du` than in a HTTP or SMTP daemon, but still.
A fantastic `ls` implementation in Java would not be very practical. OTOH it's not an accident that Rusty replacements of these programs tend to be multi-threaded, because that's a thing Rust encourages and makes practical.
Glad they wrote their collection, but not something I’m excited about.
In general I’d love to hear “this was better in Rust because of X, Y and Z and the tradeoffs I had to make were A, B and C”.
But again, this isn’t on the author to do, I’m pretty sure I can find other articles on the internet that talk to that.
Edit: most of the READMEs of the projects look pretty good about that on a quick skim.
Any new programming tech that avoids my SSHD letting anyone get in because of this or that is very welcome by me.
There's Sonic, which is a searching software, although not on the level of ElasticSearch. People are working hard to bring more safety to widely used technologies, every day, we just don't hear much about it.
And it's Rust! https://www.nushell.sh/
The poster is not the author, but the collector.