21–30 of 229 posts
Is this accurate? And if so, is it super easy to write rich CLIs, with tabulated, coloured, interactive TUIs in Rust? Are their some common, widely used libraries driving this trend?
I might not be familiar enough with the original tools, nor the Rust ecosystem, so excuse me if this is misinformed. But the trend seems to be that the Rust tooling is a lot richer than their original counterparts. Is this accurate? And if so, is it super easy to write rich CLIs, with tabulated, coloured, interactive TUIs in Rust? Are their some common, widely used libraries driving this trend?
I get the point of wanting to use safer languages but I feel this list somewhat misses the point and looks more like some misguided worship to a single language. For example a lot of complaints that can be made about C and C++ don’t apply to Haskell yet this list parades a Rust counterpart to Shellcheck as if it’s automatically better just by the fact it’s written in Rust (frankly, I’d rather trust the more mature Sh…
I think 40% of the complaints people have about new JavaScript frameworks are from people failing to have the analogous insight to this.
Earlier quoted context omitted.
Because they can be rewritten by removing legacy cruft, in a language that prevents the numerous security issues they had (and still have), and optimizing several things besides... Does anybody miss Sendmail? That had also "stood the test of time".
Sendmail never stood the test of time and is pretty much abandoned now, replaced with Postfix. Guess in what language Postfix was written... The idea is that language will not solve poorly designed software, but a developer that knows what he is doing like Wietse did with Postix. And Postfix stood the test of time pretty well, considering how complex it is.
Another idea is that a software can have a great design but still be full of security holes. C allows for that.
If we leave it to the "adequately advanced programmer" to avoid those, we're doing it wrong - with plenty of historical examples to prove this.
Am I the only one who doesn't care what a tool / software package is written in, provided it does the job? If a Rust port is superior then sure, I'll use it, but I won't use it because it was written in Rust.
I might not be familiar enough with the original tools, nor the Rust ecosystem, so excuse me if this is misinformed. But the trend seems to be that the Rust tooling is a lot richer than their original counterparts. Is this accurate? And if so, is it super easy to write rich CLIs, with tabulated, coloured, interactive TUIs in Rust? Are their some common, widely used libraries driving this trend?
The rust community leadership made a strategic decision to pick 4 areas to suggest focus on. CLIs was one of them. (Scroll to “build it in rust” on https://www.rust-lang.org/)
I think this choice and many others by the rust leadership merit a case study in community technical leadership. Or at least a blog post by the author of https://www.kalzumeus.com/2014/04/09/what-heartbleed-can-tea...
Earlier quoted context omitted.
Sendmail never stood the test of time and is pretty much abandoned now, replaced with Postfix. Guess in what language Postfix was written... The idea is that language will not solve poorly designed software, but a developer that knows what he is doing like Wietse did with Postix. And Postfix stood the test of time pretty well, considering how complex it is.
> The idea is that language will not solve poorly designed software Another idea is that a software can have a great design but still be full of security holes. C allows for that. If we leave it to the "adequately advanced programmer" to avoid those, we're doing it wrong - with plenty of historical examples to prove this.
The only thing that will actually prevent security holes is attentive software engineers deliberately choosing to learn tools and practice habits to avoid security holes by design. The professional judgement of a lot of those engineers is leading them to choose to learn rust right now.
Am I the only one who doesn't care what a tool / software package is written in, provided it does the job? If a Rust port is superior then sure, I'll use it, but I won't use it because it was written in Rust.
Ditto. And I'm one of Rust's recent happy converts – it's probably the language I've learned that scores the highest ever when it comes to the unweighted sum of * joy of coding * (human) efficiency of coding * performance of idiomatic code * interoperability with C * deployability I'm totally sold on Rust. Yet: Why would I want to replace tried and tested tools with new versions just because they're written in Rust?…
* Old tools are well established, not looking for major feature additions or changes
* Hard to add new features to old C-based system tools due to mature codebase and being written in C
* Using Rust to reach a low-bug/maintainable state more quickly than a re-write in C or C++
* Adding a bunch of quality of life features that make it worth switching
The big downside with these tools, of course, is that they are re-writes of tools that have been standard Linux/Unix system tools for a long time and can be generally expected to be present on any system for the purpose of shell scripts, services etc. Using any of these tools in a shell script requires the user to install it, along with the whole dependency graph that rust typically comes with (at least when building from source which is typically the case with rust).
Am I the only one who doesn't care what a tool / software package is written in, provided it does the job? If a Rust port is superior then sure, I'll use it, but I won't use it because it was written in Rust.
Language per se isn't important, but the majority of security vulnerabilities are still caused by non-memory-safe languages. So I'd regard that as a reason not to use a given software package.
Now if that's the case that's also cool. I also love new ways of doing old things and we might sooner or later have something that looks like Redox on Linux/BSD kernels.