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

181–190 of 229 posts

Re: Replacements for existing software written in Rust

#181

Post by laumars »

kevinmgranger wrote: post #103
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…

The page claims they're awesome, it doesn't claim they're better.

The page has been changed since my post. It originally called them “replacements”, which paints a totally different picture. From reading the GitHub Issue thread regarding the name change, it sounds like various people on Reddit were making similar concerns about the original choice of wording too.

Re: Replacements for existing software written in Rust

#182

Post by alpaca128 »

username90 wrote: post #168
pirocks wrote: post #139

Earlier quoted context omitted.

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

Calling unsafe libraries isn't the same thing as having unsafe language features.

Calling unsafe libraries automatically makes the calling code unsafe by definition. You cannot have a 100% safe language that also interacts with its (unsafe) environment in any way.

The language needs a way to express the lack of safety of an external library in order to clearly isolate it from the safe code sections. In Rust that's the unsafe block.

Re: Replacements for existing software written in Rust

#183

Post by staticassertion »

laumars wrote: post #142
bluGill wrote: post #134

Earlier quoted context omitted.

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)

My point was if you’re exposing your build system to untrusted individuals inputting untrusted data then you’ve already lost the game. Rust won’t save you from a RCE bug because you’ve already granted them RCE from the beginning. An overflow bug in awk is only exploitable if someone can craft input into awk. And if you’re allowing people to do that then you’ve already given them access to remotely run code without th…

> My point was if you’re exposing your build system to untrusted individuals inputting untrusted data then you’ve already lost the game.

This is how the vast majority of build systems are configured. If I have owned a dev and can push code to a branch I can likely execute code in their build environment. If they then parse that build output with something like awk, that's attack surface.

Is it the first thing I'd try to attack? Nope. But I do wonder what the cumulative impact of every binary on your system being memory safe would be. I'd definitely feel better.

Re: Replacements for existing software written in Rust

#185

Post by DoctorOW »

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?

How does one objectively measure quality in a way that isn't dependent on the specific goals the program is trying to accomplish?

Re: Replacements for existing software written in Rust

#186

Post by cerved »

pdimitar wrote: post #160
cerved wrote: post #125

Earlier quoted context omitted.

tbh, I would feel better if the badge was "tested for 50 years on every system you can think of"

I, too, enjoy sci-fi. :)

cat has been around for 49 years and 8 months, give or take a few days

Re: Replacements for existing software written in Rust

#187

Post by pdimitar »

cerved wrote: post #186
pdimitar wrote: post #160

Earlier quoted context omitted.

I, too, enjoy sci-fi. :)

cat has been around for 49 years and 8 months, give or take a few days

Sure, there are a few of these around. 99% of the software you use every day has been around for less however.

Re: Replacements for existing software written in Rust

#188

Post by darthrupert »

ibraheemdev wrote: post #133
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.

Nim is aimed at pretty much the same level as Go, I would say. Only with more modern abstractions.

And currently (with Nim 1.4 and its memory management), it's moving towards Rust's field. Their performance has always been in the same space, especially regarding cmdline tools, where latency is more important than most other tools.

Re: Replacements for existing software written in Rust

#189

Post by pdimitar »

alpaca128 wrote: post #182
username90 wrote: post #168

Earlier quoted context omitted.

Calling unsafe libraries isn't the same thing as having unsafe language features.

Calling unsafe libraries automatically makes the calling code unsafe by definition. You cannot have a 100% safe language that also interacts with its (unsafe) environment in any way. The language needs a way to express the lack of safety of an external library in order to clearly isolate it from the safe code sections. In Rust that's the unsafe block.

`cargo-geiger` provides nice detailed output. I found it eye-opening and it made me more conscious what dependencies to use.

Re: Replacements for existing software written in Rust

#190

Post by benibela »

bdamm wrote: post #149
a-nikolaev wrote: post #106

Earlier quoted context omitted.

That's awesome though!

Somehow this feels like sarcasm, given that Pascal is older that pretty much everyone on this forum.

Seriously: https://github.com/benibela?tab=repositories

I have been doing it for 20 years, and all the time Pascal had null-safe strings and C-like performance. And the strings even had mutability xor aliasing with copy on write

Post reply on HN