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

241–250 of 410 posts

Re: Rewriting Rust

#241

Post by hawski »

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…

The friction in C and C++ library ecosystem is sometimes a feature for this sole reason. Many libraries try to pull as little as possible and other things as optional.

Re: Rewriting Rust

#242

Post by josephg »

bormaj wrote: post #225
josephg wrote: post #178

Earlier quoted context omitted.

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: solu…

Not that I know of - hence talking about it in this blog post!

Re: Rewriting Rust

#243

Post by M4Luc »

iforgotpassword wrote: post #22
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…

Maybe they can learn from the Javascript folks, I heard they're very good at this.

The Javascript folks are at least aware and self critical of this. In the Rust community it's sold as a great idea.

Re: Rewriting Rust

#244

Post by josephg »

Ygg2 wrote: post #185
josephg wrote: post #179

Earlier quoted context omitted.

> This isn't necessarily a language problem, though, more of a "culture" problem, I think. Author here. We could make it a language problem by having the language sandbox dependencies by default. Seems like an easy win to me. Technical solutions are almost always easier to implement than social solutions.

Edit: replied to wrong person.

Huh?

> It's throwing the baby and bathwater into lava.

Is it really so controversial to want to be able to limit the access that utility crates like humansize or serde have to make arbitrary syscalls on my computer?

Seems to me like we could get pretty far with just compile-time checks - and that would have no impact whatsoever on the compiled code (or its performance).

I don't understand your criticism.

Re: Rewriting Rust

#245

Post by M4Luc »

olalonde wrote: post #142
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…

Why do you care how many lines of code the dependencies are? Compile time? Lack of disk space?

Security and maintenance. That's what's so compelling about Go. The std lib is not a pleasure to use. Or esp. fast and featureful. But you can rely on it. You don't depend on 1000 strangers on the internet that might have abandoned their Rust crate for 3 years and nobody noticed.

Re: Rewriting Rust

#246

Post by josephg »

gary17the wrote: post #193
josephg wrote: post #184

Earlier quoted context omitted.

Author here. > Javascript has a quite different use-case audience than Rust. Eh. That sounds like a "just so" explanation to me. Linus Torvalds doesn't work on the rust compiler. I think I could make much more convincing arguments that javascript should move slower than rust - given there's so many large language runtime projects. (V8, Safari, Javascript, Node, Deno, Bun, etc etc). But evidently, that isn't the case.…

No, Linus Torvalds doesn't work on the Rust compiler, but it is up to people like Linus to support or shoot down a particular PL for a particular use case. And here we arrive at the heart of our discussion: I am personally much more interested in being able to use Rust for Linux kernel development at the cost of any programming convenience, while you are more interested in being able to use cutting-edge PL features.…

> I am personally much more interested in being able to use Rust for Linux kernel development at the cost of any programming convenience, while you are more interested in being able to use cutting-edge PL features.

Some of the "cutting-edge PL features" I want are things like function effects - which would allow you to (at compile time) mark that a function cannot panic.

This is something the linux kernel has been asking for from rust for years. I think our interests are aligned.

Re: Rewriting Rust

#247

Post by lifthrasiir »

simon_o wrote: post #221
lifthrasiir wrote: post #154

Earlier quoted context omitted.

> 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.

How can you be that sure? :-) It is not even like that Maven repositories don't suffer from malicious packages with confusing names (for example, [1])...

[1] https://github.com/spring-projects/spring-ai/issues/537

Re: Rewriting Rust

#248

Post by M4Luc »

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…

Another example is Axum. Using Go, C#, Deno or Node you don't even need any third party provided more or less secure and maintained lib. It all comes from the core teams.

Re: Rewriting Rust

#249

Post by lifthrasiir »

simon_o wrote: post #235
lifthrasiir wrote: post #127

Earlier quoted context omitted.

Isn't that trivial? Just use Rust but reject any occurrence of `async` or `await` in your code or dependencies. Rust doesn't even force the use of async code for certain features in its standard library.

The problem is the ecosystem split and the decades of man hours of churn caused in libraries and user code – that's time and effort that could have been spent on making those dependencies better. This applies to both suggestions ("fork" and "don't use it").

So does forking, as the parent originally suggested.

Re: Rewriting Rust

#250

Post by tommiegannert »

lifthrasiir wrote: post #129
tommiegannert wrote: post #75

> Rust doesn't have syntax to mark a struct field as being in a borrowed state. > ast_nodes: Vec , Oh, that would be neat to replace the https://github.com/tommie/incrstruct I wrote for two-phase initialization. Unlike Ouroboros and self_cell, it uses traits so the self-references can be recreated after a move. Whether it's a good idea, I don't know, but the magic Ouroboros applies to my struct feels wrong. But I say…

`if some_var.is_some_and(|x| some_expr)` is the current way to do that. It is less flexible and doesn't actually bind `x` into the conditional body (hence the proposal) but works today.

Thanks for the suggestion. It does avoid a nested if-statement, so agreed it's useful.
Post reply on HN