zlacker

[parent] [thread] 11 comments
1. ameliu+(OP)[view] [source] 2021-07-20 22:21:50
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.

replies(3): >>tptace+f2 >>static+V2 >>tialar+Qt
2. tptace+f2[view] [source] 2021-07-20 22:42:51
>>ameliu+(OP)
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.

3. static+V2[view] [source] 2021-07-20 22:47:16
>>ameliu+(OP)
> 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.

4. tialar+Qt[view] [source] 2021-07-21 03:10:25
>>ameliu+(OP)
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.

replies(2): >>valent+tx >>kaba0+CS
◧◩
5. valent+tx[view] [source] [discussion] 2021-07-21 03:57:11
>>tialar+Qt
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.
replies(1): >>vanvie+4m1
◧◩
6. kaba0+CS[view] [source] [discussion] 2021-07-21 07:45:40
>>tialar+Qt
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.

replies(1): >>juki+Lg1
◧◩◪
7. juki+Lg1[view] [source] [discussion] 2021-07-21 11:42:24
>>kaba0+CS
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.
replies(1): >>fauige+fT1
◧◩◪
8. vanvie+4m1[view] [source] [discussion] 2021-07-21 12:21:48
>>valent+tx
It's not the best language for solving this type of problems? What (kind of) language would you say is even better for that?
replies(2): >>rurban+ZG4 >>valent+897
◧◩◪◨
9. fauige+fT1[view] [source] [discussion] 2021-07-21 15:10:59
>>juki+Lg1
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.

replies(1): >>jolux+Kr3
◧◩◪◨⬒
10. jolux+Kr3[view] [source] [discussion] 2021-07-21 23:13:56
>>fauige+fT1
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.
◧◩◪◨
11. rurban+ZG4[view] [source] [discussion] 2021-07-22 12:37:44
>>vanvie+4m1
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.

◧◩◪◨
12. valent+897[view] [source] [discussion] 2021-07-23 05:36:43
>>vanvie+4m1
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.

[go to top]