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

201–210 of 229 posts

Re: Replacements for existing software written in Rust

#201

Post by rvz »

staticassertion wrote: post #148
rvz wrote: post #42

Earlier quoted context omitted.

Agreed. I will put it even more directly. I could not care less about the hype squad screaming endlessly about every single side project that is written in Rust because of the sake of the language. If it is useful and it makes me money then fine, other than that I ignore it. If the tool that is being developed doesn't help me make money, then I do not care or I won't use it. As for choosing the best programming langu…

Why even go to a site like HN if your goal is purely to make money? You can make lots of money without reading 99% of the content here. This is Hacker news. It's news for people who want to fuck around with tech.

> Why even go to a site like HN if your goal is purely to make money?

Yet this site seems to be hosted by a company whose goal is purely about making money by investing in companies they find which are likely to give huge returns. i.e A VC fund.

So rewriting it in Rust for the sake of Rust is irrelevant to them and doesn't give any advantage whatsoever and won't get their attention.

Re: Replacements for existing software written in Rust

#202

Post by krapp »

rvz wrote: post #201
staticassertion wrote: post #148

Earlier quoted context omitted.

Why even go to a site like HN if your goal is purely to make money? You can make lots of money without reading 99% of the content here. This is Hacker news. It's news for people who want to fuck around with tech.

> Why even go to a site like HN if your goal is purely to make money? Yet this site seems to be hosted by a company whose goal is purely about making money by investing in companies they find which are likely to give huge returns. i.e A VC fund. So rewriting it in Rust for the sake of Rust is irrelevant to them and doesn't give any advantage whatsoever and won't get their attention.

Yes. Many wannabe entrepreneurs come here hoping to gain "street cred" and get their "insightful" comments and projects noticed by YC, hoping to parlay that into funding or hoping a launch on HN will do for them what it did for others (like Dropbox.) Believe it or not Hacker News is serious business, there's a reason the staff is so guarded about releasing any code or hints about their algorithm that could be gamed.

Re: Replacements for existing software written in Rust

#203

Post by staticassertion »

laumars wrote: post #200
staticassertion wrote: post #183

Earlier quoted context omitted.

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

> If I have owned a dev and can push code to a branch I can likely execute code in their build environment. But then you’re also executing that code as a trusted user. Ie the real hack is owning the dev. > This is how the vast majority of build systems are configured. No. The vast majority of build systems are either locked to private repositories, and/or a subset of developers, and/or run in an ephemeral sandbox. >…

> But then you’re also executing that code as a trusted user. Ie the real hack is owning the dev.

That's like saying the real hack is sending a phishing email, ignoring all privesc, lateral movement, etc.

> No. The vast majority of build systems are either locked to private repositories, and/or a subset of developers, and/or run in an ephemeral sandbox.

I didn't say otherwise. I said that the majority allow untrusted execution. If you consider your engineers laptops to be trusted you're thinking about networks the way people did ~10+ years ago.

> It’s negligible because if someone can exploit a buffer overflow in awk then they can already run arbitrary code in awk

This isn't true, but even if it were you can just replace awk with anything else that's not turing complete.

Re: Replacements for existing software written in Rust

#204

Post by karottenreibe »

jedisct1 wrote: post #169
robenkleene wrote: post #136

Earlier quoted context omitted.

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 t…

ugrep is better than rg.

It would help if you added why it's better to your comment

Re: Replacements for existing software written in Rust

#205

Post by [deleted] »

cb321 wrote: post #192
darthrupert wrote: post #188

Earlier quoted context omitted.

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.

Nim has very easy ways to get full C performance in pure Nim with a trivial FFI to just call C and is both higher level than Go and lower level at the same time because of that. Simple analogies often fail to describe. :-( { This is not intended as a dig/criticism but note on communication limits - you should just learn more about Nim at https://nim-lang.org/ }

[deleted]

Re: Replacements for existing software written in Rust

#206

Post by laumars »

staticassertion wrote: post #203
laumars wrote: post #200

Earlier quoted context omitted.

> If I have owned a dev and can push code to a branch I can likely execute code in their build environment. But then you’re also executing that code as a trusted user. Ie the real hack is owning the dev. > This is how the vast majority of build systems are configured. No. The vast majority of build systems are either locked to private repositories, and/or a subset of developers, and/or run in an ephemeral sandbox. >…

> But then you’re also executing that code as a trusted user. Ie the real hack is owning the dev. That's like saying the real hack is sending a phishing email, ignoring all privesc, lateral movement, etc. > No. The vast majority of build systems are either locked to private repositories, and/or a subset of developers, and/or run in an ephemeral sandbox. I didn't say otherwise. I said that the majority allow untrusted…

> I said that the majority allow untrusted execution. If you consider your engineers laptops to be trusted you're thinking about networks the way people did ~10+ years ago.

i never said anything about trusting engineers laptops.

Let me put it another way, are you running your build pipelines bare metal, allowing anyone to instantiate the pipeline against a branch of code that anyone in the public has written? Or is that build pipeline running against a private repository, or triggered by trusted users, or does it run inside a temporary VM or container that gets destroyed afterwards? That’s where you harden CI/CD. I’m not suggesting fixing buffer overflows aren’t worthwhile (security should be multilayered after all) but it’s missing the real risk since you’ve already got code remotely executing. Thus your threat model should be about ensuring you minimise the blast radius of that code.

To use your colourful language: if your build pipelines are running bare metal then you’re thinking about infra like people did ~10 years ago.

> This isn't true, but even if it were you can just replace awk with anything else that's not turing complete.

But you’re still not addressing the real issue. If you can’t trust the the code executing and you’re not sandboxing that code then you’ve already lost the fight. You can’t give unrestricted access to execute code remotely and then moan “we wouldn’t have been exploited if everything was written in Rust”. The bone headed design was allowing unrestricted remote code execution and not the buffer overflow bug in ‘cat’.

> That's like saying the real hack is sending a phishing email, ignoring all privesc, lateral movement, etc.

It’s really not. What I’m taking about is the equivalent of saying “phishing attacks are always going to happen so you need MFA et al to harden against the array of of ways one can manipulate the system”

You’re entire security model seems to be focused around fixing every fucking executable against every possible class of bug and that’s insanely impractical. Whereas I’m suggesting one shouldn’t implicitly trust remote code in build pipelines to begin with.

Re: Replacements for existing software written in Rust

#207

Post by pjmlp »

benibela wrote: post #190
bdamm wrote: post #149

Earlier quoted context omitted.

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

Imagine an alternative reality where Borland did not went greedy, Java 1.0 would just be like Go, while .NET Native would just be improved VB 7 and a new language C# (just a kind of "managed C++") making COM developer friendly without C++ boilerplate that persists to this day.

Re: Replacements for existing software written in Rust

#208

Post by pjmlp »

dlivingston wrote: post #105
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…

My biggest problem with this list is that when I write shell scripts, I usually intend for them to be used by colleagues or others. Having non-POSIX applications used in these scripts means that portability is limited. Yes, I know that with aliases I can override this, but I’m not convinced yet that straying from “this will work on everyone’s machine” to “set an alias for X, and X will probably be an appropriate stan…

Given that most people don't use POSIX rather GNU extensions, that is besides the point.

Re: Replacements for existing software written in Rust

#209

Post by goodpoint »

marcus_holmes wrote: post #71
goodpoint wrote: post #70

Earlier quoted context omitted.

To clarify: I'm in no way opposed to experimentation, learning and weekend projects. But there current "github-centered" development culture makes it very difficult to tell if authors are invested in their FOSS projects are going to maintain them or not. As the churn keeps increasing we can end up with ecosystems collapsing. In comparison, the library maintained since 2003 by the Nebraska person is less worrying. htt…

Also, the "don't write code, just find a library that does what you want to do and plumb it in" mentality means that people approach a problem by searching Github, find these half-finished experiments, and ship them to prod. I exaggerate, of course, but not by much

This is why FAANGs rewrite a lot of stuff. Having control over a library developed internally VS being at the mercy of random accounts on github.

Re: Replacements for existing software written in Rust

#210

Post by Thiez »

gspr wrote: post #16
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…

I wholeheartedly agree. Especially since one huge strength of Rust is its C interoperability, one would imagine that incrementally replacing or extending parts of the legacy tools would be a much more sound approach. But of course, the point you make does answer this: > And a lot of those projects are just someone’s pet project, often written as a task for learning Rust, and certainly likely to have numerous new bugs…

> Especially since one huge strength of Rust is its C interoperability, one would imagine that incrementally replacing or extending parts of the legacy tools would be a much more sound approach.

When it is unlikely that the maintainers of existing tool written in C would accept pull requests that add Rust as a dependency (and I imagine this would usually be the case), why wouldn't you start anew? It also allows easier experimentation on the architecture of the original tool, and breaking compatibility. For example, ripgrep isn't a drop-in replacement for grep and the author never intends it to be, so forking grep probably wouldn't have made it easier to develop.

I think the difference between a learning project and a "real" project is mostly how many people end up using it.

Post reply on HN