Live data from Hacker News

Replacements for existing software written in Rust

github.com

161–170 of 229 posts

Re: Replacements for existing software written in Rust

#161
post #149

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.

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.

Re: Replacements for existing software written in Rust

#163
post #98
post #84

Earlier quoted context omitted.

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

I think this comment (on this same post) is relevant here https://news.ycombinator.com/item?id=27318979

Re: Replacements for existing software written in Rust

#164
post #79

Earlier quoted context omitted.

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

Re: Replacements for existing software written in Rust

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

> 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 that are pretty cool too and fit into a similar niche. Hard-core evanglism just feels like advise from somebody who's only tool is a hammer.

on the other hand I do remember the amount of marketing and advertising budget that Sun and later Oracle pumped into Java to make it fly in the late 90ies. They made deals with University professors to make sure the language is favored. It was a hype-shit machine unmatched by anything we've seen since (and when I use the word shit I mean your browser being hi-jacked and reconfigured with a new toolbar and a search engine simply because you installed a JRE. not too different from how malware behaves). It's not that early Java was terrible (though it certainly over-promised and under-delivered for over a decade) but if Java would have had to grow organically back then like Rust/Nim/Zig do today, then Java wouldn't have stood a chance. There were even ads at airports and on TV. Ads for a programming language during a time most people watching TV didn't know or care what computers are for!

So I'm quite glad that this is just a couple of people who are overly excited about what they do. We've had a lot more asymmetry with larg-corp sponsored garbage. Go Rust!! (and Nim and Zig)

Re: Replacements for existing software written in Rust

#166
post #97
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 ma…

The way pacman installs new kernels by default is just replacing the old package with the new one. This is bad because if for some reason the new kernel package gets corrupted, the system will fail to boot, and you will have to arch-chroot into the system to install the kernel again. Fedora on the other hand keeps old kernels for some time before removing them.

Re: Replacements for existing software written in Rust

#167
post #31

Earlier quoted context omitted.

I don't disagree - IMO 95% of what's written in Rust should have been written in OCaml years ago. But often those languages aren't used, for whatever reason. If Rust is what gets us the actual big rewrite into memory-safe languages, I'll take it.

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 much less sense). For example, building non-trivial projects with just the compiler is very painful from most modern perspectives, but it's very similar to what you have to do for C.

Re: Replacements for existing software written in Rust

#168

Earlier quoted context omitted.

Rust isn't a memory safe language though. Unsafe is a part of the language, so it wouldn't get that badge.

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.

Re: Replacements for existing software written in Rust

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

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.

Re: Replacements for existing software written in Rust

#170

I (mostly) love Rust, but the fact is that it makes lots of easy things hard. Most software should be written in a GC language. Even Java or Go are a better choice for most “backend” development, despite the fact that from a PL design standpoint they’re vastly inferior to Rust.

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?
Post reply on HN