Live data from Hacker News

Replacements for existing software written in Rust

github.com

81–90 of 229 posts

Re: Replacements for existing software written in Rust

#81
post #21

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?

Some are supersets and many are experimental subsets. It's early days, similar to when everyone wrote their own editor in TurboPascal.

Regarding TUIs, have a look at thes screenshots and example codebases for these libraries:

https://crates.io/crates/tui

https://crates.io/crates/spotify-tui

https://crates.io/crates/cursive

TUIs are in many ways more ergonomical, in particular they make experienced users more productive and they can help reduce RSI by limiting the need to move the mouse.

Re: Replacements for existing software written in Rust

#82
The main thing that interests me in Rust and Go rewrites of common tools (bat, ripgrep, broot, etc.) is that they use their newness as an opportunity to have nicer output and simpler CLIs or nice TUIs. It's not really about the language for me.

Re: Replacements for existing software written in Rust

#83

Earlier quoted context omitted.

As a fan of the language I also don't get this. I mean I welcome wider adoption of Rust for various reasons, but this whole "it's written in Rust!" checkbox filling doesn't have any connection to what matters in reality. If you're rewriting something anyway, or creating something new then Rust should be considered. But a lot of the value of old software is not the set of features listed in the Readme. Not every area…

To me it makes sense. I predict the future of the tool/product partly on the technology, and the programming language is part of it

I wonder if in the future, it will be easier to find contributors for Rust projects than C projects, just because Rust is more pleasant to use.

Re: Replacements for existing software written in Rust

#84
post #24

Earlier quoted context omitted.

> 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.

Caveat: Saying “Just write it in rust” won’t change the fact that writing secure software is hard. 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.

>Caveat: Saying “Just write it in rust” won’t change the fact that writing secure software is hard.

No. But it will make sure there are no issues of the type buffer overflow and such.

The rest, we can judge when the software is delivered.

Re: Replacements for existing software written in Rust

#85

Earlier quoted context omitted.

Caveat: Saying “Just write it in rust” won’t change the fact that writing secure software is hard. 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.

> Caveat: Saying “Just write it in rust” won’t change the fact that writing secure software is hard. Absolutely. It's just that statistically the memory safety bugs have been the dominant percent of all the bugs, so rewriting core tools in a memory-safe language does make sense.

Indeed.

Time & attention are limited resources. By eliminating the dominant class of bugs you have more time and attention for more subtle bugs.

Re: Replacements for existing software written in Rust

#86

Earlier quoted context omitted.

If a common question in a job interview is "have you written any OSS projects that are used by others?" and a positive answer is expected, then this is where we end up. Thousands of new developers, eager to learn Rust and get a job, rewriting anything they can get their hands on and pushing it out for the community to use.

Uh, is this a common question? I've never been asked anything remotely close.

I get it pretty often. I am assuming they want to use this as a means to see code that I have written in collaboration with others.

Re: Replacements for existing software written in Rust

#88
post #8

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’m fully in favour of using newer and safer languages...

And the ONLY way C/C++, that cost BILLONS on bugs alone, is replaced is that people rewrite things on something better (and Rust IS better).

And this start for fun.

And it could get new bugs? yeah... but it also NOT continue the old bugs that C/C++ cause, some that will be erased of existence (like nulls) for the rest of the life of the codebase.

And this is the point. Logic bugs eventually are squashed, but language design mistakes are nearly eternal for the life of the codebase.

Re: Replacements for existing software written in Rust

#90
post #8

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 have been rewriting things in Pascal for years, because it is much safer than C, and no one cares about that :(
Post reply on HN