Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The struggle with Rust

ayende.com

Post reply on HN
Print view View original

231–240 of 301 posts

Re: The struggle with Rust

#231

Post by bryanlarsen »

braveo wrote: post #227
Manishearth wrote: post #206

Earlier quoted context omitted.

Rust contests the claim that you actually need to do pointer arithmetic and stuff often in systems languages. You need to do it a bit to implement your abstractions, maybe, but it is not the first tool you should need to reach for. The code in the blog post looks very much like C-translated-to-rust. Right now, systems programming mostly does look like C/C++ because those are the only two mainstream languages that wor…

> Do you really need to use malloc to allocate memory in a systems language? Do you really need to use pointer arithmetic to deal with things in a systems language? Sometimes, but not necessarily often. Even the Rust operating systems have managed to minimize the amount of unsafe/C-like code. If you're adding performance considerations I think the answer is going to be yes.

I'm not an expert, but I believe that Rust's performance will be better if you avoid unsafe pointers. Rust's abstractions are generally cost-free, but if you use unsafe pointers the compiler will have to avoid optimizations that could be broken by potential pointer aliasing.

Re: The struggle with Rust

#232

Post by kibwen »

sh_tinh_hair wrote: post #204
kibwen wrote: post #188

Earlier quoted context omitted.

And I think that's fine; Rust isn't trying to be the one language to rule them all. It's intended as a foundational language: your friend's streaming website survives despite his own code crashing often, but it won't survive if his off-the-shelf HTTP server crashes often (HTTP servers being the sort of thing one would write in Rust). Likewise, your mathematicians aren't going to be very productive if their Python int…

Dictatorial concepts in PL usually fail pretty badly. Rust may become the textbook example of a good idea too far. I'd certainly never use it or use anything written in it given a choice and/or time to rewrite in anything more accessible.

> or use anything written in it

As I often say on HN, I must be missing the sarcasm here...

Re: The struggle with Rust

#233

Post by AstralStorm »

humanrebar wrote: post #225
braveo wrote: post #158

Earlier quoted context omitted.

> if it's an implementation detail and well-tested The same can be said of C and C++, at which point, why does it matter if you use Rust?

Rust has opt-out safety with 'unsafe' blocks. C++ doesn't even have opt-in safety. You can get fairly close with smart pointers and some other techniques, but 'fairly close' doesn't cut it when you're talking about memory corruption issues.

You can enforce safety by using the strict type system combined with polymorphic memory allocators in C++17, and get quite close to that with C++11.

The only thing you cannot exactly prevent is "cast_dammit_cast".

Re: The struggle with Rust

#234

Post by AstralStorm »

stonemetal wrote: post #90
jackmott wrote: post #81

Earlier quoted context omitted.

I don't think they are any error classes that OCaml/F# will let you make that Rust won't.

Rust prevents data races, OCaml/F# don't provide such guaranties. Though it isn't so much of a problem in OCaml since it doesn't have concurrent threads.

First, Rust does not prevent data races, just makes them pain to write.

Second, Rust also prevents legitimate sharing in a bunch of cases where concurrency is not involved. (and a simple scoped allocator succeeds)

This would be fixed if there was an easy way to have typed memory that can be shared but cannot be accessed concurrently. There is none. You get at most full unsafe.

Re: The struggle with Rust

#235

Post by braveo »

bryanlarsen wrote: post #231
braveo wrote: post #227

Earlier quoted context omitted.

> Do you really need to use malloc to allocate memory in a systems language? Do you really need to use pointer arithmetic to deal with things in a systems language? Sometimes, but not necessarily often. Even the Rust operating systems have managed to minimize the amount of unsafe/C-like code. If you're adding performance considerations I think the answer is going to be yes.

I'm not an expert, but I believe that Rust's performance will be better if you avoid unsafe pointers. Rust's abstractions are generally cost-free, but if you use unsafe pointers the compiler will have to avoid optimizations that could be broken by potential pointer aliasing.

the idea of cost-free came from C++ where the belief is that you don't pay for what you don't use. The underlying meaning there is that you don't pay the cost of virtualized function calls if you're not using polymorphism (this is a big reason why C++ doesn't feature virtualized function calls by default).

polymorphism is of course an abstraction, the idea of cost-free is that you only pay for the abstractions you actually use.

This is not the same as maximizing performance.

The real question is whether or not you can do these things without giving the developer the control to maximize performance, and I think the answer is going to be no. The response will be that it's "good enough", but that's not actionable as we don't know what "good enough" means for any particular project.

Re: The struggle with Rust

#236

Post by dbaupp »

AstralStorm wrote: post #233
humanrebar wrote: post #225

Earlier quoted context omitted.

Rust has opt-out safety with 'unsafe' blocks. C++ doesn't even have opt-in safety. You can get fairly close with smart pointers and some other techniques, but 'fairly close' doesn't cut it when you're talking about memory corruption issues.

You can enforce safety by using the strict type system combined with polymorphic memory allocators in C++17, and get quite close to that with C++11. The only thing you cannot exactly prevent is "cast_dammit_cast".

Could you be specific about how the type system and polymorphic memory allocators defend against things like dangling references, iterator invalidation and use-after-free/move? I can't imagine an allocator affecting these unless it's one that just has a no-op free (which only use-after-free, anyway), nor is the type system strong enough by itself.

Re: The struggle with Rust

#237

Post by [deleted] »

AstralStorm wrote: post #233
humanrebar wrote: post #225

Earlier quoted context omitted.

Rust has opt-out safety with 'unsafe' blocks. C++ doesn't even have opt-in safety. You can get fairly close with smart pointers and some other techniques, but 'fairly close' doesn't cut it when you're talking about memory corruption issues.

You can enforce safety by using the strict type system combined with polymorphic memory allocators in C++17, and get quite close to that with C++11. The only thing you cannot exactly prevent is "cast_dammit_cast".

[deleted]

Re: The struggle with Rust

#238

Post by steveklabnik »

AstralStorm wrote: post #234
stonemetal wrote: post #90

Earlier quoted context omitted.

Rust prevents data races, OCaml/F# don't provide such guaranties. Though it isn't so much of a problem in OCaml since it doesn't have concurrent threads.

First, Rust does not prevent data races, just makes them pain to write. Second, Rust also prevents legitimate sharing in a bunch of cases where concurrency is not involved. (and a simple scoped allocator succeeds) This would be fixed if there was an easy way to have typed memory that can be shared but cannot be accessed concurrently. There is none. You get at most full unsafe.

Rust does prevent data races, as long as you don't use unsafe. If not, it's a bug.

You can write arenas in Rust.

Re: The struggle with Rust

#239

Post by AstralStorm »

pjmlp wrote: post #216
Manishearth wrote: post #206

Earlier quoted context omitted.

Rust contests the claim that you actually need to do pointer arithmetic and stuff often in systems languages. You need to do it a bit to implement your abstractions, maybe, but it is not the first tool you should need to reach for. The code in the blog post looks very much like C-translated-to-rust. Right now, systems programming mostly does look like C/C++ because those are the only two mainstream languages that wor…

> Do you really need to use malloc to allocate memory in a systems language? Do you really need to use pointer arithmetic to deal with things in a systems language? To add to this point, my answer would be a big NO, if one would look to the C alternatives that sadly became niches. Sadly the adoption of C has lead to younger generations thinking that those are the only valid paths in system languages. Thankfully new l…

However, typed and separate memory areas with various allowed kinds of concurrent access are needed. Even simple RAM has multiple modes, plain, atomic of multiple kinds, barriers... On top of that, you get devices that handle access only with delay inbetween, can never be accessed concurrently (volatile), have alignment requirements and more. Rust memory model is too weak to enforce safety in such cases while not sacrificing performance.

It is written from "I have one CPU" side. Even C is far beyond that with things like OpenCL...

Re: The struggle with Rust

#240

Post by Manishearth »

braveo wrote: post #227
Manishearth wrote: post #206

Earlier quoted context omitted.

Rust contests the claim that you actually need to do pointer arithmetic and stuff often in systems languages. You need to do it a bit to implement your abstractions, maybe, but it is not the first tool you should need to reach for. The code in the blog post looks very much like C-translated-to-rust. Right now, systems programming mostly does look like C/C++ because those are the only two mainstream languages that wor…

> Do you really need to use malloc to allocate memory in a systems language? Do you really need to use pointer arithmetic to deal with things in a systems language? Sometimes, but not necessarily often. Even the Rust operating systems have managed to minimize the amount of unsafe/C-like code. If you're adding performance considerations I think the answer is going to be yes.

> If you're adding performance considerations I think the answer is going to be yes.

You can build (or use, from the stdlib) safe abstractions over malloc that have the same performance. This should cover 99% of the use cases of malloc. For the few quirky cases where you still need malloc, you can still use it, but that means that the language doesn't need to make malloc-based memory management easy.

Post reply on HN