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

Rust and the limits of swarm design

esr.ibiblio.org

Post reply on HN
Print view View original

11–20 of 55 posts

Re: Rust and the limits of swarm design

#11

Post by bluejekyll »

rst wrote: post #9
coldtea wrote: post #5

> My use case – foundational network infrastructure with planning horizons on a decadal scale – needs stability guarantees that Rust is not yet equipped to give. Can you be any more pompous?

He may be talking about NTP -- that is core infrastructure code that had been poorly maintained for many years, and he's been involved in the rescue effort. Points off for not saying so, though; without context, your reaction is pretty natural.

The thing is he is attacking Rust not based on the safety the language provides, but more on a feeling that the package, crates, network doesn't fit his belief of how things should be curated. He states that he thinks this is why BDFL is good model, but gives no strong evidence supporting that view.

Rust has curation in its crate system. It's all in really good crowd sourcing numbers. Crates.io, number of downloads, with trends (i.e. Even if it was popular, is it still?). Then GitHub has great ones: stargazers == community interest level; watchers == # of people interested in tracking the project, possibly b/c it's a critical dependency; forks == # of people who've reviewed the code; contributors == overall success in the community; commit graphs = how much work has and is going into the project; issues can help you understand if there are any critical underlying problems with the maintenance.

When I'm evaluating a library I look at all of these numbers to understand how comfortable I am in pulling a dependency on the library. IMO this is far better than the curation of some system level tools, which just become defaults, and don't always offer users the ability to evaluate different options easily, cron stands out in my mind as one that there are better options than the default.

Anyway, his loss... the Rust community is awesome, in my humble opinion.

Re: Rust and the limits of swarm design

#12

Post by Aeolos »

srssays wrote: post #7
ZenoArrow wrote: post #4

Earlier quoted context omitted.

Libraries tend towards standardisation regardless of whether they're being curated by the language designers. Python is actually a good example of this. Look at the library ecosystem built up around scientific computing. None of that is in the standard library, yet there is a common set of packages being used.

Of course. But these projects exist in addition to a rich standard library. C++ takes the approach mentioned of having a rich standard library (Boost) that is a separate project from the core language. It (IMO) does not work very well. Many C++ programmers don't use Boost and generic C++ libraries are unable to use Boost as a dependency.

> Many C++ programmers don't use Boost and generic C++ libraries are unable to use Boost as a dependency.

That is because a boost installation litters your hard drive with several hundred thousand tiny files. I can't in good conscience require end-users to install that monster to compile my 10Kloc project.

Re: Rust and the limits of swarm design

#14

Post by bluejekyll »

srssays wrote: post #10
wwwigham wrote: post #6

Earlier quoted context omitted.

What makes the libraries blessed by the language designers so much better than a library blessed by any other trusted party? Rust is an open source language, and only the core team works on it full time - even then, any one of them could leave at any time and the community at large would need to pick up the slack. This isn't any different than the situation around any of the amazing community libararies in the Rust e…

If a library is supported and maintained by the language designers, then its lifetime will be at least as long as the lifetime of the programming language. Or if the library is replaced, then it will be done through some mechanism of deprecation, rather than sudden abandonment. I don't see the standard library and third-party packages as being in opposition. Far from it. A rich standard library encourages a rich ecos…

Omg. You just made me think about lifetime markers for crates... your project requires a minimum lifetime of stability in a crate or something. Kinda funny.

Re: Rust and the limits of swarm design

#15

Post by nxrabl »

>"A lot of Rustaceans don’t seem to grasp why, when the question is “where do I get feature X?” the answer “oh, there are 23 crates for that” is objectively terrifying."

This is a real problem. Here's a blog idea: "Consumer Reports for libraries"

(As an aside, the phrase "objectively terrifying" bugs the hell out of me. Terror is fundamentally subjective - it's a primal emotion. Please let's not let "objectively" become the new "literally".)

Re: Rust and the limits of swarm design

#16

Post by zzzcpan »

bluejekyll wrote: post #11
rst wrote: post #9

Earlier quoted context omitted.

He may be talking about NTP -- that is core infrastructure code that had been poorly maintained for many years, and he's been involved in the rescue effort. Points off for not saying so, though; without context, your reaction is pretty natural.

The thing is he is attacking Rust not based on the safety the language provides, but more on a feeling that the package, crates, network doesn't fit his belief of how things should be curated. He states that he thinks this is why BDFL is good model, but gives no strong evidence supporting that view. Rust has curation in its crate system. It's all in really good crowd sourcing numbers. Crates.io, number of downloads,…

His specific concerns might not be entirely valid, but it's not an attack. It's more like an expression of a deeper fear of the language not taking off and time wasted.

Re: Rust and the limits of swarm design

#17

Post by oblio »

srssays wrote: post #7
ZenoArrow wrote: post #4

Earlier quoted context omitted.

Libraries tend towards standardisation regardless of whether they're being curated by the language designers. Python is actually a good example of this. Look at the library ecosystem built up around scientific computing. None of that is in the standard library, yet there is a common set of packages being used.

Of course. But these projects exist in addition to a rich standard library. C++ takes the approach mentioned of having a rich standard library (Boost) that is a separate project from the core language. It (IMO) does not work very well. Many C++ programmers don't use Boost and generic C++ libraries are unable to use Boost as a dependency.

Yeah, but C++ doesn't really have a good, cross platform package manager. In Java land, for example, the lingua franca is Maven (even across different build systems).

As a result many libraries are close to de facto standards because any Java dev can easily get those libraries, regardless of being on Win, Mac, random Linux distributions, etc.

Re: Rust and the limits of swarm design

#18

Post by taesis »

It seems like the core thrust of this article is that someone isn't around to perpetually support the libraries the author would like to use; i.e., he/his company is unwilling to fork out the money for someone to keep the 'blessed' libraries fully up to date -- so now that's the implementer's problem! I can understand wanting stability and a promise of timely updates for all one's dependencies, but it doesn't seem like the core language team is the right group to foist that responsibility upon.

Re: Rust and the limits of swarm design

#19

Post by ayrx »

> This isn’t a question that comes up so often with respect to (say) Python because Python has an effective form of curation – blessing things into the standard library, at which point their alternatives generally disappear. In effect, Python modules are quality-filtered on the taste of the BDFL and the devteam.

I love Python but this statement is absolutely coming from someone who does not write Python on a regular basis. Many stdlib modules are greatly outclassed by third-party alternatives - urllib2 vs requests, datetime vs arrow just to name a few - to the point where no one actually uses the stdlib modules in production.

Re: Rust and the limits of swarm design

#20

Post by rntz »

taesis wrote: post #18

It seems like the core thrust of this article is that someone isn't around to perpetually support the libraries the author would like to use; i.e., he/his company is unwilling to fork out the money for someone to keep the 'blessed' libraries fully up to date -- so now that's the implementer's problem! I can understand wanting stability and a promise of timely updates for all one's dependencies, but it doesn't seem li…

In the end, it doesn't matter who it's "fair" to assign responsibility to; a language you can't rely on is a language you can't rely on. All esr is pointing out is that there's a problem. Personally I think the Rust folks are pretty aware of this problem, and are managing just fine; Rust is definitely still in the early stages of language community growth, and locking things down too much would be a mistake.
Post reply on HN