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

Rust’s dependencies are starting to worry me

vincents.dev

Post reply on HN
Print view View original

61–70 of 593 posts

Re: Rust’s dependencies are starting to worry me

#61

Post by sophacles »

1vuio0pswjnm7 wrote: post #59

"Not thinking about package management careful makes me sloppy." Isn't the point of a memory safe language to allow programmers to be sloppy without repercussions, i.e., to not think about managing memory and even to not understand how memory works. Would managing dependencies be any different. Does Rust allow programmers to avoid thinking carefully about selecting dependencies.

> Isn't the point of a memory safe language to allow programmers to be sloppy without repercussions, i.e., to not think about managing memory and even to not understand how memory works

No. The point is even the best programmers of unsafe languages regularly introduce both simple and subtle bugs into codebases while being careful about handling memory correctly, and therefore we should use languages that don't even allow those bugs for most every use case. Using these languages still allows crap programmers to waste GBs of correctly allocated and handled memory, and good programmers to write tight, resouce-sipping code.

Dependencies are orthogonal to this.

Re: Rust’s dependencies are starting to worry me

#62

Post by sophacles »

XxiXx wrote: post #14

I think it's a "cultural" thing. With Go you often find developers/projects proudly mentioning that any or just a few non-std dependencies are used. Coming from Go it really feels strange when you see pages of dependencies scrolling over your screen when you build a Rust project.

I have yet to come across a go project that doesn't pull in tons of 3rd party code as well. It seems like maybe you're over-stating the "culture" a bit.

Re: Rust’s dependencies are starting to worry me

#63

Post by geodel »

cogman10 wrote: post #53
wofo wrote: post #27

Earlier quoted context omitted.

There are some voices trying to address this security risk (e.g. the proponents of this new RFC: https://github.com/rust-lang/rfcs/pull/3810 ). However, for some reason (probably culture) there isn't much momentum yet to change the status quo.

The rust RFC process has, frankly, become somewhat of a CF. There's literally 1000s of RFCs for rust with only a small handful that are integrated. Having this forest, IMO, makes it hard for any given proposal to really stand out. Further, it makes duplicate effort almost inevitable. Rust's RFC process is effectively a dead letter box for most.

I think they can constitute committee for RFC review process(in case there is none today) and based on recommendation multiple domain specific teams/ groups can be created to review RFCs in timely manner.

Re: Rust’s dependencies are starting to worry me

#64

Post by jerf »

imtringued wrote: post #48
jerf wrote: post #15

Earlier quoted context omitted.

A strong advantage of that approach is that you don't need to be the core Rust team to do it. Anyone who wants to do this can just start doing it now.

This is only an advantage if the core Rust team is uncooperative, which is sad rather than something to be happy about.

The "Rust core team" should be working on the "Rust core", not every little thing that someone somewhere thinks should go in a standard library. It is part of the job of a "core team" to say "no".

A lot.

Like, a lot a lot a lot. Browse through any programming language that has an open issue tracker for all the closed proposals sometime. Individually, perhaps a whole bunch of good ideas. The union of them? Not so much.

Re: Rust’s dependencies are starting to worry me

#65

Post by schmichael »

delusional wrote: post #55
schmichael wrote: post #41

We need a term like “Mature” or similar for dependencies that are done. Mature dependencies have two characteristics: 1. Well defined scope 2. Infrequent changes Nomad has many of these (msgpack, envparse, cli, etc). These dependencies go years without changing so the dependency management burden rapidly approaches zero. This is an especially useful property for “leaf” dependencies with no dependencies of their own.…

I have a lot of sympathy for this viewpoint, but I also ask that we try to remind ourselves. We are asking for professionalism from hobby projects. If you want a mature protobuf implementation you should probably buy one. Expecting some guy/gal on the internet to maintain one for your for free seems ill advised.

A great point! All of the libraries I mentioned are created and maintained by corporations. Hobbyists, as always, are free to do as they please without judgement from me. :)

I will say I get great satisfaction from the little envparse library I wrote needing near-0 maintenance. It’s a rare treat to be able to consider any project truly done.

Re: Rust’s dependencies are starting to worry me

#66

Post by wolvesechoes »

echelon wrote: post #52
bigstrat2003 wrote: post #37

Earlier quoted context omitted.

> We do not need to saddle Rust with garbage that will feel dated like Python's standard library. Python's standard library is a strength, not a weakness. Rust should be so lucky. It's wonderful to have basic functionality which is guaranteed to be there no matter what. Many people work in environments where they can't just YOLO download packages from the Internet, so they have to make do with whatever is in the stdl…

> Python's standard library is a strength, not a weakness. Rust should be so lucky. Rust is luckier. It has the correct approach. You can find every battery you need in crates.io. Python has had monstrosities like urllib, urllib2, http, etc. All pretty much ignored in favor of the external requests library and its kin. The standard library also has inconsistencies in calling conventions and naming conventions and it…

"Rust is doing it right."

Standard response every time there is some criticism of Rust.

Re: Rust’s dependencies are starting to worry me

#67

Post by 1vuio0pswjnm7 »

1vuio0pswjnm7 wrote: post #59

"Not thinking about package management careful makes me sloppy." Isn't the point of a memory safe language to allow programmers to be sloppy without repercussions, i.e., to not think about managing memory and even to not understand how memory works. Would managing dependencies be any different. Does Rust allow programmers to avoid thinking carefully about selecting dependencies.

If careful programmers who can manage memory should use the same language as careless ones who cannot, then does this mean both should also automatically use third party libraries by default.

Are there systems languages that provide memory management but do not default to using third party libraries. If yes, then do these languages make it easier for programmers to avoid dependencies.

Re: Rust’s dependencies are starting to worry me

#68

Post by eddd-ddde »

neilv wrote: post #19

In the past (not in Rust, but other languages), for important systems, I've instituted policies of minimizing dependencies from these language-specific package repositories, and for the ones you do use, having to copy it to our own repos and audit each update before use. But that's not practical for all situations. For example, Web frontend developer culture might be the worst environment, to the point you often can'…

The cool thing about rust is you can implement async yourself. You aren't tied to any specific implementation.

Re: Rust’s dependencies are starting to worry me

#69

Post by echelon »

wolvesechoes wrote: post #66
echelon wrote: post #52

Earlier quoted context omitted.

> Python's standard library is a strength, not a weakness. Rust should be so lucky. Rust is luckier. It has the correct approach. You can find every battery you need in crates.io. Python has had monstrosities like urllib, urllib2, http, etc. All pretty much ignored in favor of the external requests library and its kin. The standard library also has inconsistencies in calling conventions and naming conventions and it…

"Rust is doing it right." Standard response every time there is some criticism of Rust.

bigstrat2003's argument is approximately "Python is batteries included"

My counter argument is that the "batteries included" approach tends to atrophy and become dead weight.

Your counter seems to be "that's not an argument, that's just Rust hype."

Am I interpreting you correctly? Because I think my argument is salient and correct. I don't want to be stuck with dated APIs from 20 years of cruft in the standard library.

The Python standard library is where modules go to die. It has two test frameworks nobody uses anymore, and how many XML libraries? Seven? (The correct answer is "four", I think. And that's four too many.) The Python standard library has so much junk inside, and it can't be safely removed or cleaned up.

A standard library should be data structure/collections, filesystem/os libraries, and maybe network libraries. That's it. Everything else changes with too much regularity to be packed in.

Re: Rust’s dependencies are starting to worry me

#70

Post by empath75 »

1vuio0pswjnm7 wrote: post #59

"Not thinking about package management careful makes me sloppy." Isn't the point of a memory safe language to allow programmers to be sloppy without repercussions, i.e., to not think about managing memory and even to not understand how memory works. Would managing dependencies be any different. Does Rust allow programmers to avoid thinking carefully about selecting dependencies.

No, the point is to stop you from being sloppy. The code won't compile if you're sloppy with memory management.

You can be _relatively_ sure that you're not introducing memory unsafety by adding a dependency, but you can't be sure that it isn't malware unless you audit it.

Post reply on HN