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

Rewriting Rust

josephg.com

Post reply on HN
Print view View original

401–410 of 410 posts

Re: Rewriting Rust

#401

Post by josephg »

steveklabnik wrote: post #296
josephg wrote: post #282

Earlier quoted context omitted.

> the exploits are impossible to write by accident, but they are possible to write on purpose. Can you give some examples? What ways are there to write safe rust code & do nasty things, affecting other parts of the binary? Is there any reason bugs like this in LLVM / rustc couldn't be, simply, fixed as they're found?

https://github.com/Speykious/cve-rs They can be fixed, but as always, there’s a lot of work to do. The bug that the above package relies on has never been seen in the wild, only from handcrafted code to invoke it, and so is less of a priority than other things. And some fixes are harder than others. If a fix is going to be a lot of work, but is very obscure, it’s likely to exist for a long time.

Yes, true. But as others have said, there’s probably still some value in making authors of malicious code jump through hoops, even if it will take some time to fix all these bugs.

And the bugs should simply get fixed.

Re: Rewriting Rust

#403

Post by 3np »

adastra22 wrote: post #372
Measter wrote: post #329

Earlier quoted context omitted.

Though we should also accept that some things are just hard. Though that's not to say that we should give up on trying to make them as easy to learn and use as possible.

I don’t know. This certainly isn’t provable. What’s the difference between a something being intrinsically difficult and something for which adequate UI just hasn’t been figured out yet? I don’t know anything that hasn’t been made simpler and easier over time.

> I don’t know anything that hasn’t been made simpler and easier over time.

Ever implemented a cyclic linked list or graph in Rust?

Re: Rewriting Rust

#404

Post by cdaringe »

josephg wrote: post #171
gary17the wrote: post #138

> The rust RFC process is a graveyard of good ideas. I actually have quite an opposite view: I think the Rust core team is 100% correct to make it very hard to add new "features" to the PL, in order to prevent the "language surface" from being bloated, inconsistent and unpredictable. I've seen this happen before: I started out as a Swift fan, even though I have been working with Objective-C++ for years, considered it…

Author here. I hear what you're saying. But there's lots of times while using rust where the language supports feature X and feature Y, but the features can't be used together. For example, you can write functions which return an impl Trait. And structs can contain arbitrary fields. But you can't write a struct which contains a value returned via impl Trait - because you can't name the type. Or, I can write if a && b…

Dude YES. This stuff was maddening in rust. “How many links to GitHub issues will the compiler fire at me today” was a sincere feeling. I think it’s much better these days, but you still get em doing async work

Re: Rewriting Rust

#405

Post by adastra22 »

cogman10 wrote: post #395
wahern wrote: post #394

Earlier quoted context omitted.

It's a stretch to argue that Go's concurrency model is pi calculus. Go supports lexical closures, and even the initial body of a goroutine can close over variables in the parent scope. Go's concurrency model is fundamentally lexical closures[1] and threading, with channels layered on top. Lexical closing is, afterall, how channels are initially "passed" to a goroutine, and for better or worse it's not actually a comm…

Just to add, Go was inspired by Hoare's CSP paper [1]. Hoare came up with the ideas of CSP separately from Milner [2] even though they have some cross over concepts. The two collaborated later on, but really had somewhat independent approaches to concurrency. To respond to the OP. Go's concurrency model absolutely has multiple blogs written about it and explaining how it works. It's actually a little funny OP was thi…

They're equivalent: https://www.cs.ox.ac.uk/files/2340/hoarecomplete2.pdf

Re: Rewriting Rust

#406

Post by Arch485 »

mathw wrote: post #202
Arch485 wrote: post #116

Earlier quoted context omitted.

> I am by far no expert, but I am very sure that its not something you "just" go do. As someone who has dabbled in compiler writing (i.e. I may be totally wrong), I believe that from a technical standpoint, modifying the borrow checker as proposed in the article (w.r.t. self-referential structs) is actually something you can "just do". The issues that come up are due to backwards compatibility and such, meaning it ca…

Before you can "just do" a change to the borrow checker you have to be able to precisely describe how those new behaviours for the borrow checker actually work, how it interacts with the rest of the borrow checker's behaviour and how it doesn't lead to unsoundness problems. Otherwise, you might as well just not have a borrow checker.

Indeed. In the case of self-referential borrows, this is not allowed because Rust wants copying structures byte-for-byte (e.g. `memcpy`) to always be safe.

The solution was `Pin` et. al., which gives a way to make some value immovable in memory.

An equivalent yet simpler version of this system could be integrated into the borrow checker (this was a proposed solution for Rust), but as I said before, it would not be backwards-compatible, hence the need for `Pin`.

Re: Rewriting Rust

#407

Post by pdimitar »

cdaringe wrote: post #404
josephg wrote: post #171

Earlier quoted context omitted.

Author here. I hear what you're saying. But there's lots of times while using rust where the language supports feature X and feature Y, but the features can't be used together. For example, you can write functions which return an impl Trait. And structs can contain arbitrary fields. But you can't write a struct which contains a value returned via impl Trait - because you can't name the type. Or, I can write if a && b…

Dude YES. This stuff was maddening in rust. “How many links to GitHub issues will the compiler fire at me today” was a sincere feeling. I think it’s much better these days, but you still get em doing async work

I hate it as well and I also feel async Rust needs years of much better love than it received at its conception. But... some info is still better than no info.

Re: Rewriting Rust

#408

Post by pdimitar »

epage wrote: post #314

RE: Rust's pacing I've had a lot of talks with my management about that. For context, I'm on the Cargo team and have authored 11 RFCs (10 approved, 1 pending). I feel like a lot of the pacing feels slow because: - As the project matures, polishing whats there takes up a lot of effort - Conversely, hitting local maximas where things are "just good enough" that individuals and companies don't feel the need to put effor…

> As for things being approved but not completed, thats a "we need more help" problem usually.

You know, I would LOVE working on Rust (not just with Rust) and be a part of some of the core team(s).

But my impression is that nobody truly has any powerful agency over things and even if you formulate a near-perfect and a PR to go with it, things would still end with several smarter people than me saying "Oh this looks really neat, we should ponder it more and test it further and merge it!" and then it never happens.

That, plus I am not sure how is the job stability situation there.

Re: Rewriting Rust

#410

Post by anonfordays »

hitekker wrote: post #377
anonfordays wrote: post #353

Earlier quoted context omitted.

[flagged]

I have a few pieces of info, but they're not linkable. Not yet. IMHO, I don't think she was trash. I think she was the face of Rust's lack of integrity, in many respects.

Reposting for posterity:

Yup, glad she's gone, working on a project no one uses and no one cares about. Basically a containment project. The trash really does take itself out sometimes.

I can't think of any other core Rust contributors that were pushed out though, any links?

AND flagged below:

She was trash, and cancer. Glad to see the cancer excised itself. Remember what she did to Node/npm? Pepperidge Farms remembers: https://archive.is/XcxSf

Post reply on HN