[ddalcino]

What’s with the backlash against Rust? It literally is “just another language”. It’s not the best tool for every job, but it happens to be exceptionally good at this kind of problem. Don’t you think it’s a good thing to use the right tool for the job?

[amelius]

It is good to keep in mind that the Rust language still has lots of trade-offs. Security is only one aspect addressed by Rust (another is speed), and hence it is not the most "secure" language.

For example, in garbage collected languages the programmer does not need to think about memory management all the time, and therefore they can think more about security issues. Rust's typesystem, on the other hand, can really get in the way and make code more opaque and more difficult to understand. And this can be problematic even if Rust solves every security bug in the class of (for instance) buffer overflows.

If you want secure, better use a suitable GC'ed language. If you want fast and reasonably secure, then you could use Rust.

[tialaramex]

A thing to remember about GC is that it solves only one very important resource. Memory.

If your program loses track of which file handles are open, which database transactions are committed, which network sockets are connected, GC does not help you at all for those resources, when you are low on heap the system automatically looks for some garbage to get rid of, but when you are low on network sockets, the best it could try is hope that cleaning up garbage disconnects some of them for you.

Rust's lifetime tracking doesn't care why we are tracking the lifetime of each object. Maybe it just uses heap memory, but maybe it's a database transaction or a network socket. Either way though, at lifetime expiry it gets dropped, and that's where the resource gets cleaned up.

There are objects where that isn't good enough, but the vast majority of cases, and far more than under a GC, are solved by Rust's Drop trait.

[kaba0]

High-level languages can provide abstractions though that can manage object life cycles to a degree for you, for example dependency injection frameworks, like Spring.

Not disagreeing, just mentioning.

[juki]

And many languages also provide convenient syntax for acquiring and releasing a resource for a dynamic extent (Java try-with-resources, C# `using`, Python `with`, etc.), which cover the majority of use cases.

[fauigerzigerk]

Yes, but these features are usually optional. Library users can easily forget to use them and neither library authors nor the compiler can do anything to enforce it.

The brilliant thing about RAAI style resource management is that library authors can define what happens at the end of an object's lifetime and the Rust compiler enforces the use of lifetimes.

[jolux]

I agree that RAII is superior, but it’s not true that compilers and library authors can’t do anything to enforce proper usage of Drop-able types in GC’d languages. C# has compiler extensions that verify IDisposables are used with the using statement, for example. Granted, this becomes a problem once you start writing functions that pass around disposable types.

[valenterry]

It's not like Rust were the only or even the best language in solving the problems you mentioned. It might be the best performance focused / low-level language though.

[vanviegen]

It's not the best language for solving this type of problems? What (kind of) language would you say is even better for that?

[rurban]

Actually safe languages fOR example. Pony guarantees all three safeties, memory, type and concurrency, whilst in Rust it's only a plan, just not implementated. Stack overflows, type unsafety, dead locks. POSIX compatible stdlib.

Concurrent Pascal or Singularity also fit the bill, with actual operating systems being written in it.

[valenterry]

Any language that offers some kind of effect system that has support for brackets and cancelation, for example Haskell or Scala.

There isn't even specific language support necessary, it's on the library level.

[staticassertion]

> Rust's typesystem, on the other hand, can really get in the way and make code more opaque and more difficult to understand.

I don't disagree with the premise of your post, which is that time spent on X takes away from time spent on security. I'll just say that I have not had the experience, as a professional rust engineer for a few years now, that Rust slows me down at all compared to GC'd languages. Not even a little.

In fact, I regret not choosing Rust for more of our product, because the productivity benefits are massive. Our rust code is radically more stable, better instrumented, better tested, easier to work with, etc.

[tptacek]

I don't think this is a good take. Go, Java, Rust, Python, Swift; they all basically eliminate the bug class we're talking about. The rest is ergonomics, which are subjective.

"Don't use Rust because it is GC'd" is a take that I think basically nobody working on memory safety (either as a platform concern or as a general software engineering concern) would agree with.

[zo1]

It's unusually or suspiciously "hyped". Not to the extent as the other sibling exaggerated to, but enough for it to be noticeable and to rub people the wrong way, myself included. It rubs me the wrong way because something feels off about the way it's hyped/pushed/promoted. It's like the new javascript in the programming world. And if we allow it (like we did with JS), it'll overtake way too much mindshare with the unfortunate detriment and neglect of all others.

[cratermoon]

> What’s with the backlash against Rust?

What's with the hyping of Rust as the Holy Grail as the solution to everything not including P=NP and The Halting Problem?

[pdimitar]

No serious and good programmer is hyping Rust as the "Holy Grail". You are seeing things due to an obvious negative bias. Link me 100x HN comments proving your point if you like but they still mean nothing. I've worked with Rust devs for a few years and all were extremely grounded and practical people who arrived at working with it after a thorough analysis of the merits of a number of technologies. No evangelizing to be found.

Most security bugs/holes have been related to buffer [over|under]flows. Statistically speaking, it makes sense to use a language that eliminates those bugs by the mere virtue of the program compiling. Do you disagree with that?

[tptacek]

Nobody seriously thinks it's "Rust" that's the silver bullet either; they just believe memory-safe languages are. There are a bunch of them to choose from. We hear about Rust because it works in a bunch of high-profile cases that other languages have problems with, but there's no reason the entire iMessage stack couldn't have been written in Swift.

[tialaramex]

Fair. Two further thoughts:

1. Rust also has other safety features that may be relevant to your interests. It is Data Race Free. If your existing safe-but-slow language offers concurrency (and it might not) it almost certainly just tells you that all bets are off if you have a Data Race, which means complicated concurrent programs exhibit mysterious hard-to-debug issues -- and that puts you off choosing concurrency unless it's a need-to-have for a project. But with Data Race Freedom this doesn't happen. Your concurrent Rust programs just have normal bugs that don't hurt your brain when you think about them, so you feel free to pick "concurrency" as a feature any time it helps.

2. The big surface area of iMessage is partly driven by Parsing Untrusted File Formats. You could decide to rewrite everything in Rust, or, more plausibly, Swift. But this is the exact problem WUFFS is intended to solve.

WUFFS is narrowly targeted at explaining safely how to parse Untrusted File Formats. It makes Rust look positively care free. You say this byte from the format is an 8-bit unsigned integer? OK. And you want to add it to this other byte that's an 8-bit unsigned integer? You need to sit down and patiently explain to WUFFS whether you understand the result should be a 16-bit unsigned integer, or whether you mean for this to wrap around modulo 256, or if you actually are promising that the sum is never greater than 255.

WUFFS isn't in the same "market" as Rust, its "Hello, world." program doesn't even print Hello, World. Because it can't. Why would parsing an Untrusted File Format ever do that? It shouldn't, so WUFFS can't. That's the philosophy iMessage or similar apps need for this problem. NSO up against WUFFS instead of whatever an intern cooked up in C last week to parse the latest "must have" format would be a very different story.

[staticassertion]

Totally. I said Rust because I write Rust. Like, that's (part of) my job. Rust is no more memory safe (to my knowledge) than Swift, Java, C#, etc.

I also said "way, way less" not "not at all". I still think about memory safety in our Rust programs, I just don't allocate time to address it (today) specifically.

[paavohtl]

If we include data race safety in the definition of memory safety (which it ultimately is), then Rust is safer than any commonly used garbage collected language with access to multithreading, including Swift, Java and C#.

[tptacek]

This is a RESF trope. We do not include Rust's notion of data race safety in the definition of memory safety as it is used in security. Not all bugs are created equal.

[noizejoy]

If you would have mentioned those other languages in your original post, it might have amplified your valuable and important point even better, rather than triggering some readers effectively accusing you of shilling.

I don’t mean this in a very critical spirit, though.

Communication is really hard - especially in a large setting where not everyone reads you in the same context, and not everyone means well.

On balance, you post was valuable to me!

[staticassertion]

I mentioned Rust because I write Rust professionally. If I wrote Java professionally, as I used to, I would have said "java". So you're probably correct that I could preempt stupid people's posts, but I don't care about the dregs of HN reading into my very clear, simple statement, just because they're upset about rust or whatever. It's just not worth it to me.

I'm glad the post was of value to you. The talk is really good and I think more people should read it.

[pdimitar]

Agreed. I was simply mostly addressing this person's obvious beef with Rust.

[option_greek]

It also doesn't help that Rust has this addictive nature and once you tasted your first major Rust program and tamed the borrow checker, you will want to keep using it everywhere. And that's the reason why people keep looking around to rewrite something in Rust. It's in the same category as any other banned drug :)

[tptacek]

That has not been my experience.

[maqp]

I like what tptacek wrote in the sibling comment. IIUC Rust keeps getting mentioned as "the" memory-safe language because it's generally equally fast compared to C programs. And it's mainly C and C++ that are memory-unsafe. So Rust is good language to combat the argument of speed (that's often interchangeable with profits in business world, especially if security issues have a flat rate of cyber insurance).