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.
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).
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.
Is there a place where I can read more on this?
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.
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.
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.
This may be not as important in a replacement for `less` or `du` than in a HTTP or SMTP daemon, but still.
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.