Comment by neilv | Hacker News Reader

Comment by neilv | Hacker News Reader

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't get many things done in feasible time, if you don't adopt the same reckless practices.

I'm also seeing it now with the cargo-culting of opaque self-hosted AI tools and models. For learning and experimenting, I'd spend more time sufficiently compartmentalizing an individual tool than with using it.

This weekend, I'm dusting off my Rust skills, for a small open source employability project (so I can't invest in expensive dependency management on this one). The main thing thing bothering me isn't allocation management, but the sinking feeling when I watch the cast-of-thousands explosion of transitive dependencies for the UI and async libraries that I want to use. It's only a matter of time before one of those is compromised, if not already, and one is all it takes.

Best way is to have CI/CD systems only connected to the official internal repos.

Devs can add whatever they feel like on their workstations but it will be a sad build server if they get pushed without permission.

s/Best way/The only safe way/

Anything else will get abused in the name of expediency and just-this-one-time.

Also, the process for adding a crate/gem/module/library needs to be the same as anything else: license review, code review, subscription to the appropriate mailing list or other announce channel, and assignment of responsibility. All of these except code review can be really, really fast once you have the process going.

All problems are, at least in part, dependency chain management problems.

I agree that some amount of friction when including third party dependencies is a vital thing to push people to consider the value versus cost of dependencies (and license review, code review, channel subscriptions are all incredibily important and almost always overlooked), however how should this work for transitive dependendencies? And the dependencies of _those_ dependencies?

The dependency trees for most interpreted or source-distributed languages are ridiculous, and review of even a few of those seems practically impossible in a lot of development environments.

You understand the problem clearly, but you haven't put your finger on the solution.

It's an obvious one, but distasteful to many people.

Perhaps the distaste is blinding me.

Would you care to state the obvious very clearly, for the dense ones among us?

"The dependency trees for most interpreted or source-distributed languages are ridiculous,"

Therefore, you must only use software for which the dependency trees are not ridiculous.

And that means giving up on software with ridiculous dependencies.

> Devs can add whatever they feel like on their workstations

A compromised dev machine is also a problem.

True, hence we can go next level and also deal with limited accounts for developers, and I can tell you most folks on HN would hate to work in such corporate environments.

I'd leave. If I have to beg IT security every other day for something,it's just not worth it. I was in that situation once before and it was endlessly frustrating. It also wasn't even their choice, the CEO dictated it after attending some security talk once upon a time, and then instantly "you can't trust anyone or anything". You can trust my stay there will be short though :)

No doubt, although this is always a job market situation, in many places around the globe being a developer isn't much different from any other office job, where many folks have to be happy to have a job in first place.

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.

> isn't much momentum yet to change the status quo.

it's complex problem with tons of partial solutions which each have tons of ways to implement them with often their no being a clear winner

i.e. it's the kind of hard to solve by consensus problem

e.g. the idea of a extended standard library is old (around since the beginning of rust) but for years it was believed it's probably the best to make it a separate independent project/library for various reason. One being that the saying "the standard library is the place where code goes to die" has been quite true for multiple ecosystems (most noticeably python)

as a side note ESL wouldn't reduce the LOC count it would increase it as long as you fully measure LOCs and not "skip" over some dependencies

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

Or not use async at all.

Same in C++, partially true in .NET/C# and F#.

Except that libraries using different async libraries in Rust seem generally incompatible.

Reply on news.ycombinator.com