Earlier quoted context omitted.
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.
yeah but not on this list
Replacements for existing software written in Rust
191–200 of 229 posts
Re: Replacements for existing software written in Rust
#192Earlier quoted context omitted.
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.
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/ }
Re: Replacements for existing software written in Rust
#193Earlier quoted context omitted.
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.
Right, I figured as much. There is so much misunderstanding about what 'unsafe' is and does that it's really really important to be precise about it when your audience isn't Rust programmers.
Re: Replacements for existing software written in Rust
#194I 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…
Indeed, in fact the Microsoft Security Guidelines explicitly states .NET languages should be taken when having a GC around is not a show stopper.
Re: Replacements for existing software written in Rust
#195Earlier 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…
> I find it more interesting to ask the question "why do people spend so much hobby time writing interesting programs in Rust?". My theory is that people that like Rust want to work with Rust, and for that the best way is to prove that it's a good replacement in multiple times. By making modern and good versions of classic CLI tools, they prove that it can replace C in that space. By making good new CLI tools, they p…
[deleted]
Re: Replacements for existing software written in Rust
#196Earlier 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
[deleted]
Re: Replacements for existing software written in Rust
#197Earlier quoted context omitted.
Somehow this feels like sarcasm, given that Pascal is older that pretty much everyone on this forum.
The novelty of a tool is not directly correlated to its worth, because we can always make new, worse tools. Newer tools CAN make use of new information in a better design, but it doesn't always happen.
[deleted]
Re: Replacements for existing software written in Rust
#198I 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…
> looks more like some misguided worship to a single language this pretty much sums up Rust atm. There is a lot of hard-core evangelizing which is off-putting imho. I still like the language but wonder if a rewrite for rewrite sake will convince the majority, considering this is a community effort and not a large org controlling the future of the language. Especially that there are other ecosystems like Zig or Nim th…
In what concerns Zig, I would rather have the use-after-free scenario be taken care of before the whole RIZ starts.
Regarding Java, it had a major killer feature that triggered adoption even before the whole marketing wave started.
It was actually portable, not like trying to write C or C++ code in the middle of ongoing standards, compilers still stuck in the old ways, POSIX on paper and on actual UNIX clones not being 100% the same thing.
It was like a fresh air of portability even with an interpreted runtime, JIT only came in by 1.2 days.
Re: Replacements for existing software written in Rust
#199I 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…
If a common question in a job interview is "have you written any OSS projects that are used by others?" and a positive answer is expected, then this is where we end up. Thousands of new developers, eager to learn Rust and get a job, rewriting anything they can get their hands on and pushing it out for the community to use.
This is how my github is a mix of almost 30 years old university assignments and unfinished weekend projects.
To tick the checkbox of some HR people that insist that I provide something.
Total amount of times anyone asked me anything about them on a job interview, zero.
Re: Replacements for existing software written in Rust
#200Earlier 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. 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…
> 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 I do wonder what the cumulative impact of every binary on your system being memory safe would be.
I’d already answered that. It’s negligible because if someone can exploit a buffer overflow in awk then they can already run arbitrary code in awk (remember, awk is a programming language). So if you’re not already taking precautions about who is running what on your build system and how running code is sandboxes then it’s not going to take a buffer overflow bug to RCE it.