Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Replacements for existing software written in Rust

github.com

Post reply on HN
Print view View original

131–140 of 229 posts

Re: Replacements for existing software written in Rust

#131

Post by username90 »

pdimitar wrote: post #62
alpaca128 wrote: post #43

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…

Would you feel better about this is if the badge was "Written in a memory-safe language"?

Rust isn't a memory safe language though. Unsafe is a part of the language, so it wouldn't get that badge.

Re: Replacements for existing software written in Rust

#132

Post by staticassertion »

laumars wrote: 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…

For CLI programs Rust is a really nice alternative to languages that require a runtime. I've significantly sped up the time for my bashrc to execute (my bashrc is heavy) by replacing certain tools with Rust tools.

If I wanted my IDE to execute something like ShellCheck on every save, or even every few character presses, I feel like I'd much rather not have to spin up a big runtime.

Re: Replacements for existing software written in Rust

#133

Post by ibraheemdev »

darthrupert wrote: post #89

These Rust replacements are unique in the way that most of them vastly improved on the original. I still don't quite understand what about Rust made that happen. They could have been easily written in, say, Nim years before Rust existed.

Systems programmers got really excited :) I don't know much about Nim but I don't think it, or Go, etc. are aimed as low-level as Rust is. Rust is pretty unique in being as low-level as C, yet providing safety and higher level abstractions.

Re: Replacements for existing software written in Rust

#134

Post by bluGill »

laumars wrote: post #77
lmm wrote: post #15

Earlier quoted context omitted.

> Half those applications are going to have other classes of new bugs simply because it’s new code and they’ve had less people audit the code. True. But most other classes of bug are not security bugs by default in the way that memory safety bugs are.

That’s not true at all. 2 of the 3 biggest security vulnerabilities I’ve had to deal with in my career were completely unrelated and wouldn’t have been prevented had software been written in Rust instead. Also half the software mentioned in that gist should never be used in security-focused applications anyway (if your depending on ‘cat’ or ‘awk’ to be bug free for your application to be hardened then you’re already…

I use cat and awk in my build system. I can imagine bugs in either that I wouldn't notice in general that would compromise my application. They are off the wall enough that I don't think they have ever happened, but my application is an embedded system that has the ability to kill people so I'm a little paranoid. (not so much that I don't use awk in my build system where it is a useful tool)

Re: Replacements for existing software written in Rust

#135

Post by staticassertion »

deeviant wrote: post #122
singhrac wrote: post #102

Earlier quoted context omitted.

I mostly agree with this sentiment but I think it's not that necessary to point out. Yes, some of these are abandonware but many are written by the same set of strong Rust programmers. I think you'd be hard pressed to argue that ripgrep or fd is not a valuable contribution to the OSS ecosystem. The more interesting question is - why is that? Sure, Rust is memory safe, but I suspect the real reason people built high q…

> but I suspect the real reason people built high quality software in Rust is because cargo is good Do we actually have factual evidence that people do write high quality software in Rust. Something showing the average rust program is "higher quality" than the average C++ program?

It's way too hard to build evidence for something like that. Virtually all research into PL effectiveness ends up not account for the absurd number of variables.

Re: Replacements for existing software written in Rust

#136

Post by robenkleene »

Zhyl wrote: post #52

Wow, a lot of hate for this list, but I'll unpick something that is slightly below the surface here: We are currently seeing a bit of a command line renaissance. The justification for this is a 'rust rewrite', but as many have pointed out, just because something is in such-and-such a language doesn't make it good. However, what I tend to find with the new rust CLI tools is that they bring with them modern design sens…

I agree with this so much, in particular I want to highlight these tools from the list, just because I love them so much:

# `rg` / Ripgrep (`grep` replacement)

`rg` uses `ack`-semantics (i.e., automatically searches files recursively).

Here's what my search workflow looks like, this is the main way I program:

1. `rg something`

2. Too many hits? `rg -l something` to just list matching filenames

3. Hopefully based on that we can narrow enough using a glob: `rg something -g "*.m"`. Otherwise write a regular expression to get more specific matches.

4. After I have exactly the set of matches I'm interested in, I pipe the results to a text editor that can interpret grep-style output (e.g., quickly jump between results, I usually use Vim).

The key here is that the command-line excels at iteratively refining a command based on output, and that's exactly what we're looking for to use search effectively. `rg` provides a more ergonomic UI than `grep` (recursive, automatically ignoring version control files, including ignored), which is really important if this is the main command that you're running all-day, which it is for me.

# `fd` (`find` replacement)

This advantages here are the similar as for `rg`, quickly being able to recursively find a file by name, a problem that similarly benefits from iteratively refining a command.

# `bat` (`cat` replacement)

`bat` is just the best way I've found to quickly view a file from the command-line, it adds syntax highlighting and line numbers, which are both invaluable.*

Re: Replacements for existing software written in Rust

#137

Post by the-alchemist »

Perhaps someone already mentioned it here, but GraalVM lets you interop between Java and anything LLVM, and therefore Rust, without the JVM startup cost, with breakpoints across languages, even (as I understand it). Compile time is long, though.

borkdude has been releasing for some very cool stuff using this stuff. Here's a Clojure/Rust combo:

https://github.com/borkdude/clojure-rust-graalvm

Re: Replacements for existing software written in Rust

#138

Post by cestith »

laumars wrote: post #119
Zababa wrote: post #65

Earlier quoted context omitted.

I don't think that list misses the point, a lot of what's in here is actually a better/more modern alternative. Starting with "An experimental container runtime" isn't a great idea, but bat, tokei, dust, fd, skim, exa, fnm, hyperfine, tealdeer and just are all serious projects. I do think the list could be curated a bit harder (and ripgrep should be added, fortunately there's already a pull request). > And a lot of t…

“A lot” is certainly a subjective term and thus open to interpretation. One might argue that the entirety of the collection isn’t “a lot” since it only amounts to 34. Others might argue that 17% is “a lot” as it’s that means near enough 1 in 5 projects isn’t mature and that’s a pretty poor signal to noise ratio. If the repo advertised itself as a curated list of interesting Rust alternatives to standard tools then I…

My take is that was just poor wording and they should be considered alternatives or potential future replacements in progress. Once you give up on that word, the page makes more sense.

Re: Replacements for existing software written in Rust

#139

Post by pirocks »

username90 wrote: post #131
pdimitar wrote: post #62

Earlier quoted context omitted.

Would you feel better about this is if the badge was "Written in a memory-safe language"?

Rust isn't a memory safe language though. Unsafe is a part of the language, so it wouldn't get that badge.

Pretty much ever safe language has unsafe features though, either by calling out to C or something like sun.misc.Unsafe in java.

Re: Replacements for existing software written in Rust

#140

Post by justwalt »

senderista wrote: post #130

I (mostly) love Rust, but the fact is that it makes lots of easy things hard. Most software should be written in a GC language. Even Java or Go are a better choice for most “backend” development, despite the fact that from a PL design standpoint they’re vastly inferior to Rust.

Why do you think that most modern software should be written in a GC language?
Post reply on HN