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

91–100 of 229 posts

Re: Replacements for existing software written in Rust

#91

Post by zurn »

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…

Are you implying that Rust is only / mostly used as a replacement for unsafe C/C++, and Rust programs should always be evaluated in the context of this choice?

Re: Replacements for existing software written in Rust

#93

Post by nicoburns »

lbhdc wrote: post #86
brailsafe wrote: post #60

Earlier quoted context omitted.

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.

I get it pretty often too. Having said that, I haven't typically had much to show and I've usually been offered the job anyway so I'm not sure it's typically given that much weight.

Re: Replacements for existing software written in Rust

#94

Post by nicoburns »

Cthulhu_ wrote: post #33
bschwindHN wrote: post #25

Earlier quoted context omitted.

You're probably not the only one. However, I will always prefer CLI tools written in C/Go/Rust/anything native because Python dependency management is a shitshow and its startup time is way too slow.

But you're bringing up a good argument for preferring a binary over a script there - portability, external dependencies, performance are important factors. I don't believe performance will be significantly different if you're comparing a C vs a Rust tool though.

IME Rust/Go/Python/Node tools tend to have better ergonomics / feature sets compared to C tools. This can be because the C tool is simply older, but I also think it's because writing and maintaining extra quality of life features is a major pain in C, so they tend not to get added. The same can also apply to performance optimisation in some cases (e.g. multithreading is much easier to add without introducing bugs in Rust than in C).

Rust and Go thus occupy a sweet spot for CLI tools, because they have the advantage of high-level maintainable code AND being fast, easily installable binary executables.

Re: Replacements for existing software written in Rust

#95

Post by blacktriangle »

nicoburns wrote: post #93
lbhdc wrote: post #86

Earlier quoted context omitted.

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.

I get it pretty often too. Having said that, I haven't typically had much to show and I've usually been offered the job anyway so I'm not sure it's typically given that much weight.

I've asked that question. I use it as a way to offer an alternative demonstration of work to developers who are early in their careers. It's not about seeing the code as much as it is wanting to see that a person has taken software through the full lifecycle. I'd rather see an app in an App Store or a live site on the web, or even just talk about an in-house project that they've managed over a period of years.

Re: Replacements for existing software written in Rust

#96

Post by duped »

de_keyboard wrote: post #5

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.

One reason to care is because some languages (go, Rust) are statically linked by default which is quite useful for system tools that can be disabled entirely by messing with shared dependencies.

Re: Replacements for existing software written in Rust

#97

Post by pxc »

csomar wrote: post #39

I know people here are a bit touchy about Rust, and writing everything in Rust. But here is one advantage I have found with Rust programs: The installation just works. Cargo, as a package manager, is just wonderful. I have lost counts of how many times my "brew" or "pacman" failed to install something. It's much worse if it's Python; and things that work in macOS are not guaranteed to compile in Linux, and vice-versa…

It's been ~11 years since I used a distro based on pacman as a daily driver, and I was very harsh on pacman at the time. It seemed to lag behind the high-level package management tools of contemporaneous distros in terms of flexibility (and, once you had a lot of things installed, performance).

But I never, ever had it just fail to install a package, and I don't remember much fuss with dependency resolution taking manual fiddling, either.

I'd love to hear your pacman horror stories; gimme the hot package manager gossip :D

Re: Replacements for existing software written in Rust

#98

Post by scoutt »

coldtea wrote: post #84
afarrell wrote: post #27

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

> it will make sure

https://www.cvedetails.com/vulnerability-list/vendor_id-1902...

I'm not so sure....

And those are bugs from from people writing core stuff, like you know, the people who should know Rust better than you and me. People writing foundational code that your program will run on top of.

Of special danger is the last CVE, that was rushed and backported into the last release. But nobody talks about it. I can imagine why.

I can bet that the "but the bug happened within unsafe code" excuse will be the next Rust meme.

Re: Replacements for existing software written in Rust

#100

Post by pdimitar »

hulitu wrote: post #79
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"?

Is a memory-safe language a safe language ? Is it not possible to exploit rust ?

Of course it is possible. If you get your hands on the binary itself there's nothing that a good reverse-engineer will not be able to do.

Point however is, if you have a SaaS which uses Rust, the chances for triggering a buffer underflow / overflow exploit are zero.

As for other aspects of security, Rust makes no special effort there. The main win for using Rust is to eliminate the most widespread bugs (the memory safety ones) from the get go. Everything else is still fair game and has to be paid proper attention to.

Post reply on HN