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

221–230 of 410 posts

Re: Rewriting Rust

#221

Post by simon_o »

lifthrasiir wrote: post #154
cmrdporcupine wrote: post #141

Earlier quoted context omitted.

It's frustrating because the grand-daddy of build systems with automatic transitive dependency management -- Maven -- already had tools from day one to handle this kind of thing through excluded dependencies (a blunt instrument, but sometimes necessary). In my experience, [patch] doesn't cut it or compare. That, and the maven repository is moderated. Unlike crates.io. Crates.io is a real problem. No namespaces, basic…

> In my experience, [patch] doesn't cut it or compare. AFAIK what Maven does is an exclusion of dependency edges , which is technically an unsafe thing to do. Cargo [patch] is a replacement of dependency vertices without affecting any edges. (Maven surely has a plugin to do that, but it's not built-in.) They are different things to start with. Also I believe that the edge exclusion as done by Maven is (not just "tech…

> Namespace is not a solution for name squatting: namespace is just yet another identifier that can be squatted. If you are worried about squatting, the only effective solution is sandboxing, everything else is just moving the goal post.

The problems crates.io struggles with have never been an issue with Maven, regardless of how creatively you try to redefine words.

That's a fact. Deal with it.

Re: Rewriting Rust

#222

Post by senorrib »

withoutboats3 wrote: post #190
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…

These features are slow to be accepted for good reasons, not just out of some sort of pique. For example, the design space around combining `if let` pattern matching with boolean expressions has a lot of fraught issues around the scoping of the bindings declared in the pattern. This becomes especially complex when you consider the `||` operator. The obvious examples you want to use work fine, but the feature needs to…

I think you just proved his point on how hard it is to understand and correctly use Pin.

Re: Rewriting Rust

#223

Post by high_na_euv »

imron wrote: post #14
feelingsonice wrote: post #7

>And I don't know if it will ever be there. Progress on the language has slowed so much. When I first started using it, every release seemed to add new, great features in stable rust. Now? Crickets. Is frustration with Rust on the rise? I just started using Rust few month ago and absolutely love it. I can't tell what's going on with the Rust foundation so I can only judge by reading sentiments. Nothing would kill my…

“There are only two kinds of languages: the ones people complain about and the ones nobody uses.” ― Bjarne Stroustrup

What about C#?

Very popular lang that is actually very nicely designed and has very good ecosystem (compilers, tools like package manager, std lib)

Re: Rewriting Rust

#224

Post by cogman10 »

dist1ll wrote: post #15

I think the dependency situation is pretty rough, and very few folks want to admit it. An example I recently stumbled upon: the cargo-watch[0] crate. At its core its a pretty simple app. I watches for file changes, and re-runs the compiler. The implementation is less than 1000 lines of code. But what happens if I vendor the dependencies? It turns out, the deps add up to almost 4 million lines of Rust code, spread acr…

This is a natural and not really scary thing.

All code is built on mountains of dependencies that by their nature will do more than what you are using them for. For example, part of cargo watch is to bring in a win32 API wrapper library (which is just autogenerated bindings for win32 calls). Of course that thing is going to be massive while watch is using only a sliver of it in the case it's built for windows.

The standard library for pretty much any language will have millions of lines of code, that's not scary even though your apps likely only use a fraction of what's offered.

And have you ever glanced at C++'s boost library? That thing is monstrously big yet most devs using it are going to really only grab a few of the extensions.

The alternative is the npm hellscape where you have a package for "isOdd" and a package for "is even" that can break the entire ecosystem if the owner is disgruntled because everything depends on them.

Having fewer larger dependencies maintained and relied on by multiple people is much more ideal and where rust mostly finds itself.

Re: Rewriting Rust

#225

Post by bormaj »

josephg wrote: post #178
School-Cotton wrote: post #62

Earlier quoted context omitted.

Why, concretely, does this matter? Other than people who care about relatively obscure concerns like distro packaging, nobody is impeded in their work in any practical way by crates having a lot of transitive dependencies.

Author here. If I compile a package which has 1000 transitive dependencies written by different authors, there's ~1000 people who can execute arbitrary code on my computer, with my full user permissions. I wouldn't even know if they did. That sounds like a massive security problem to me. All it would take is one popular crate to get hacked / bribed / taken over and we're all done for. Giving thousands of strangers th…

Are there any attempts to address this at the package management level (not a cargo-specific question)? My first thought is that the package could declare in its config file the "scope" of access that it needs, but even then I'm sure this could be abused or has limitations.

Seems like awareness about this threat vector is becoming more widespread, but I don't hear much discuss trickling through the grapevine re: solutions.

Re: Rewriting Rust

#227

Post by culebron21 »

josephg wrote: post #160
hnlmorg wrote: post #18

Earlier quoted context omitted.

That’s a solution people already use (vendering and / lock files) but it doesn’t solve this particular problem. The closest to a solution we have is dependency scanning against known CVEs. Having per-crate permissions is, I think, the only way languages can evolve past this hell hole we call supply chain attacks. It’s not a silver bullet, there will be edge cases that can be bypassed and new problems it creates. But…

Author here. Yeah thats my thinking. I also think you probably only need to restrict your dependencies. If you have a dep tree like this: a |-b |-c Then if crate a decides b isn't trusted, c would inherit the same trust rules. This would allow crates to be refactored, but keep the list of rules needed in big projects to a minimum. You just have to add explicit rules for sub-crates which need more permissions. Thats p…

What if dep tree is like this:

    a
    |-b
    | |-c
    |
    |-c
    |-d
      |-c
I may have read not carefully, but what happens if you allow crate X to write files, and it gets compromised? Should we set restrictions on per-call base instead?

I see we may catch those situations when a crate starts reading/writing when it hadn't, or in an unexpected place, if we set restrictions per call, but this only limits the attack surface, not eliminates it.

...It may actually make 3rd party libraries such a big bureaucratic pain, that users will minimize their usage.

Re: Rewriting Rust

#228

Post by adastra22 »

withoutboats3 wrote: post #190
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…

These features are slow to be accepted for good reasons, not just out of some sort of pique. For example, the design space around combining `if let` pattern matching with boolean expressions has a lot of fraught issues around the scoping of the bindings declared in the pattern. This becomes especially complex when you consider the `||` operator. The obvious examples you want to use work fine, but the feature needs to…

A properly designed feature shouldn’t require an entire blog post, let alone multiple, to understand.

Re: Rewriting Rust

#229

Post by SkiFire13 »

TwentyPosts wrote: post #210
SkiFire13 wrote: post #112

Earlier quoted context omitted.

AFAIK many of those language features (specialization included) are blocked by the rewrite of the trait solver.

Afaik specialisation (in full generality) would cause soundness issues, so it's not even just blocked by the trait solver, it's also blocked by figuring out a 'slimmed down' proposal that fixes those. And that's not even getting into the problem that it's a fairly controversial feature, since people are worried about terrible, hard to track specialisation trees. (See, inheritance.)

> Afaik specialisation (in full generality) would cause soundness issues, so it's not even just blocked by the trait solver, it's also blocked by figuring out a 'slimmed down' proposal that fixes those.

There is already a proposal for how to prevent unsound specializations [0], but it requires a lot of support from the trait solver, hence why I said it's blocked on it.

[0]: https://smallcultfollowing.com/babysteps/blog/2018/02/09/max...

Re: Rewriting Rust

#230

Post by adastra22 »

gary17the wrote: post #183
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…

I think it would be helpful to clearly distinguish between PL simplification (e.g., " if let Some(x) = x, x == 42 {} ") and convenience-driven PL expansion (e.g., " let @discardable lhs = rhs ?? 0; "). In case of the former, I'm with you. In case of the latter, I'm not. Rust likely isn't meant to be a tool that is easy to learn at all costs (since the borrow checker does exist, after all). Rust is, IMvHO, supposed to…

We should strive for easy to learn, easy to use.
Post reply on HN