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

171–180 of 229 posts

Re: Replacements for existing software written in Rust

#171

Post by staticassertion »

atombender wrote: post #158
staticassertion wrote: post #132

Earlier quoted context omitted.

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.

ShellCheck starts in a few milliseconds on my machine, easily fast enough to run on every character press. Haskell's runtime isn't like the Java JVM, and GHC compiles to machine code, not interpreted bytecode.

Nice, that's impressive.

Re: Replacements for existing software written in Rust

#172

Post by senderista »

sweeneyrod wrote: post #170
justwalt wrote: post #140

Earlier quoted context omitted.

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

Would you consider using a non-GC language that isn't Rust outside the various domains where C/C++ is the only realistic (non-Rust) choice?

Deterministic memory deallocation makes it harder to reason about not just “easy” code, but also linked structures and lock-free algorithms (actually it is a substantial implementation obstacle for the latter). It must offset these costs by providing predictable latency or low memory footprint. Most applications don’t require either.

Re: Replacements for existing software written in Rust

#173

Post by gkfasdfasdf »

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…

Ditto re. fzf. Fzf works amazingly well and is a recent development, who cares if it's not written in Rust?

Re: Replacements for existing software written in Rust

#174

Post by steveklabnik »

sweeneyrod wrote: post #164
pdimitar wrote: post #100

Earlier quoted context omitted.

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

I don't think memory safety bugs are the most widespread kind at all, unless you add the qualification "in languages with manual memory management".

I imagine what they're alluding to is that it seems like most of the security bugs are memory-safety related. The number is about 70%, and has been replicated independently at a number of places.

That is of course a very different thing!

Re: Replacements for existing software written in Rust

#175

Post by pdimitar »

sweeneyrod wrote: post #167
pdimitar wrote: post #66

Earlier quoted context omitted.

OCaml's community has been pretty elitistic up until just some few short years ago. Stuff like "build your project", "build docs", "generate parts of your project" have been a dark territory there for a long time where people invent their own stuff and just look down on many others who want an experience similar to Elixir's `mix` or Rust's `cargo`. This is changing, happily, but OCaml I always viewed as kind of an el…

I think you are definitely pointing at something that has been a weakness of OCaml for a long time (but as you say is happily changing). But I wouldn't characterise it as elitism; IME the OCaml community is very friendly. Instead, I think it comes from the fact that when it was first developed in the 90s, it was viewed in the context of C (and this attitude has carried over somewhat to the modern day where it makes m…

Thank you for the constructive comment. ^_^

What you say is fair. It seems that OCaml's niche with time moved from competing with C to competing with Haskell and Rust -- at least from where I am standing. Maybe some members of the community aren't OK with that goalpost moving. That would be understandable.

But to be fair, I like OCaml more than Rust but I got very spoiled by both Elixir's and Rust's tooling -- both are excellent enablers of productivity.

Once OCaml overcomes this barrier (and introduces multicore) I am definitely going in, neck deep! :)

Re: Replacements for existing software written in Rust

#176

Post by pdimitar »

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.

unsafe{} is an explicit escape hatch so it's much easier to audit and control for. So you are simply nitpicking.

Re: Replacements for existing software written in Rust

#177

Post by pdimitar »

burntsushi wrote: post #145
clappski wrote: post #141

Earlier quoted context omitted.

> the chances for triggering a buffer underflow / overflow exploit are zero Doesn't the mere existence of unsafe make this untrue? From a quick google I can see at least one[1] so the chances are definitely a lot higher than zero [1] https://github.com/servo/rust-smallvec/issues/252

The GP is either being incorrectly absolutist, or left out an important qualifier: "In safe Rust, the chances of are zero." But that is also absolutist. Instead, you might say, "In safe Rust, the chances of are zero, modulo bugs in the compiler." But that's not quite the fully story either. So instead, you might say, "In safe Rust, the chances of are zero, modulo bugs in the compiler or any dependencies or any other…

What I simply meant was "it's quite hard to introduce memory non-safety in Rust in a normal everyday work". But your explanation is definitely much more precise.

Re: Replacements for existing software written in Rust

#178

Post by pdimitar »

steveklabnik wrote: post #174
sweeneyrod wrote: post #164

Earlier quoted context omitted.

I don't think memory safety bugs are the most widespread kind at all, unless you add the qualification "in languages with manual memory management".

I imagine what they're alluding to is that it seems like most of the security bugs are memory-safety related. The number is about 70%, and has been replicated independently at a number of places. That is of course a very different thing!

Yeah, seems I messed up some words. :(

But yes, I meant the majority of the security bugs indeed.

Re: Replacements for existing software written in Rust

#179

Post by sweeneyrod »

pdimitar wrote: post #175
sweeneyrod wrote: post #167

Earlier quoted context omitted.

I think you are definitely pointing at something that has been a weakness of OCaml for a long time (but as you say is happily changing). But I wouldn't characterise it as elitism; IME the OCaml community is very friendly. Instead, I think it comes from the fact that when it was first developed in the 90s, it was viewed in the context of C (and this attitude has carried over somewhat to the modern day where it makes m…

Thank you for the constructive comment. ^_^ What you say is fair. It seems that OCaml's niche with time moved from competing with C to competing with Haskell and Rust -- at least from where I am standing. Maybe some members of the community aren't OK with that goalpost moving. That would be understandable. But to be fair, I like OCaml more than Rust but I got very spoiled by both Elixir's and Rust's tooling -- both a…

Yes, I think everyone would agree that OCaml has gone from competing with the predominant high-level language of 1996 (C) to the predominant languages of today (definitely not C).

Another factor is that creating a language (Rust, Go etc.) from scratch lets you have nice unified tooling to an extent that is probably just not possible with languages with baggage. So I doubt OCaml will ever manage to be quite as seamless as those, but IMO it's already gone from significantly worse tooling than e.g. Python/Java to significantly better, and is still improving all the time!

Re: Replacements for existing software written in Rust

#180

Post by ttt0 »

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

Language per se isn't important, but the majority of security vulnerabilities are still caused by non-memory-safe languages. So I'd regard that as a reason not to use a given software package.

I had no idea that memory safety was that big of an issue in cat and ls.
Post reply on HN