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

31–40 of 55 posts

Re: Rust and the limits of swarm design

#31

Post by steveklabnik »

plandis wrote: post #28
LeanderK wrote: post #2

i think he is exaggerating a bit. Many languages have a model where most of the functionality lies in packages and not in the standard library. And it's working. You just have to get used to it and try to develop a taste in choosing the right package. But it's not fundamental and not the limit of swarm design, because you can use statistics to assess maturity.

That's not a great reason to move languages though. For instance basically nothing comes in the standard library for C. If basically nothing is offered in the standard library of Rust then why switch? It's valid point. If we want a lot of adoption to Rust, people need to have an easy way to find quality implementations in crates or add them to the standard library so they are easy to find. Either way, you need one of…

> then why switch?

Languages are a lot more than the standard library.

Re: Rust and the limits of swarm design

#32

Post by jacobush »

moomin wrote: post #25

Reminder that before you take anything ESR says remotely seriously, you should read http://www.catb.org/~esr/writings/dancing.html from beginning to end.

It actually pains me to say this in this case but, let's take arguments on their own merits. (Though I think it does not hurt to be aware of that stuff he wrote.)

Re: Rust and the limits of swarm design

#33

Post by wott »

oelmekki wrote: post #8

Actually, the kind of features ESR asks for are covered by github, IMO. It's easy to review code quality from there, the number of stars and forks reflect project popularity, the list of committers (how many they are and who they are) can help having an idea about long term maintenance expectations, etc. The cool thing is that it works for almost any language : github is "social coding", thus it's also social validat…

10 years is "that long", now?

Re: Rust and the limits of swarm design

#34

Post by sidlls »

bluejekyll wrote: post #30
sidlls wrote: post #22

Earlier quoted context omitted.

> 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. One might easily argue that folks who criticize C and C++ for its ecosystem are also "attacking" it, by your reasonin…

'Attack' is a bit of hyperbole, so it's fair criticism, but I do feel that the article he wrote had much less to do with issues with the language, but a very monocular and subjective view of how ecosystems should be maintained. He does have some good ideas in there about how to possibly to make crates.io help you more easily identify the best crate for your usecase, but I think the solution to that is a fairly detail…

I meant my opinion wasn't humble, not yours.

Re: Rust and the limits of swarm design

#35

Post by sidlls »

steveklabnik wrote: post #29
sidlls wrote: post #23

I can't say I agree with the author's first article (which he mentions in this one), but I think he has the kernel of a good argument here. That's not to say I agree with it entirely. At some point "design by everyone" turns into "design by committee" by another name. This criticism of Rust has manifested itself in other ways, too. For example the amount of "unsafe" used in various crates (the idea being that "the co…

Do you have any numbers on the amounts of unsafe? I would be interested in a decent methodology to figure this out. I've seen people assert that this is true in the same vague way you're referring to for the other perspective.

I haven't any numbers and I wasn't asserting anything about the quantity that exists.

Re: Rust and the limits of swarm design

#36

Post by steveklabnik »

sidlls wrote: post #35
steveklabnik wrote: post #29

Earlier quoted context omitted.

Do you have any numbers on the amounts of unsafe? I would be interested in a decent methodology to figure this out. I've seen people assert that this is true in the same vague way you're referring to for the other perspective.

I haven't any numbers and I wasn't asserting anything about the quantity that exists.

Cool. If anyone else has ideas here, get in touch.

Re: Rust and the limits of swarm design

#37

Post by taesis »

rntz wrote: post #20
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.

I suppose I'm not arguing from the perspective of fairness, but moreso about incentives + experience. If we applied the author's argument against other fields and languages, e.g. machine learning and python, then the cpython maintainers would be right in including TensorFlow in the python stdlib (or whichever competitor dethrones in and sticks around for long enough).

That doesn't sit well with me, at least. I'd want the top ML developers looking at TensorFlow, and the best language implementers doing the same for cpython, not the latter trying desperately to improve code they have no expertise in. From that perspective, what matters is community: is there a knowledgable community supporting codebase 'x', where x could be the stdlib or some third party library. Some other commenters in this thread proposed better library curation/discovery tools in place of a formal commitment of long term support by the core team, which seems ideal! Using such an approach, you rely on the language for the core-language bits, and on third parties for the third-party bits, which seems on the surface to be healthier than arbitrarily choosing the only constant group (core language devs) as your supporters of everything.

Re: Rust and the limits of swarm design

#38

Post by Manishearth »

sidlls wrote: post #24
Manishearth wrote: post #21

Earlier quoted context omitted.

FWIW, this is not as bad a problem as he makes it out to be -- the reason folks don't seem to grasp it's a problem is because from inside the community the answer is usually "there are 2 crates for that, with the following tradeoffs". You have to ask, however; and it's hard to find out which crate you want to use without asking someone. This is still a problem, however, but it's one the community has been aware of fo…

"Inside the community" isn't a very strong argument in my opinion, because there is a strong bias. Folks "inside the community" are developing Rust packages because they really, really enjoy it. This is much different from having a mature language where folks who aren't as gung-ho about it develop things (out of curiosity, because work made them, etc.). I understand there's a recognition of the problem, and I think i…

My point about "inside the community" was solely to say that it's not as bad as he makes it out to be. You usually get recommendations and help picking one within minutes of posting on a Rust forum. (Or by googling it). Survivorship bias is irrelevant here.

This is not an ideal situation to be in, but it is better than he makes it out to be. And of course, we're already working on fixing it.

Re: Rust and the limits of swarm design

#39

Post by camus2 »

ZenoArrow wrote: post #4
srssays wrote: post #3

Earlier quoted context omitted.

I wouldn't say it works , rather that people will put up with it. When I write JavaScript/node.js code, I have no idea whether the dependencies I'm using will be supported 6 months from now. It's not so easy to just "choose the right package". Often all the packages for a given function are someone's hobby. Consequently JavaScript code needs constant, expensive maintenance. Whereas Python code can rely more on the st…

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.

Scientific libraries are a complex problem, writing yet another web framework isn't. Furthermore most sci/num libs are heavily linked to C/C++ and FORTRAN code, where most of the work is done.

Re: Rust and the limits of swarm design

#40

Post by wott »

LeanderK wrote: post #2

i think he is exaggerating a bit. Many languages have a model where most of the functionality lies in packages and not in the standard library. And it's working. You just have to get used to it and try to develop a taste in choosing the right package. But it's not fundamental and not the limit of swarm design, because you can use statistics to assess maturity.

I don't think "it's working".

Perl users brags about the numbers of packages in CPAN. For me, that's a nightmare. There are a dozen packages for everything. Each time I pick up one (more or less at random after wondering for hours which one I should pick between all those, which are irregularly accurately described), I discover a few weeks later that there are bugs in this package, or that it is deprecated, or that it has been reimplemented for better performance with a slightly different name, or that the procedural access to the features disappeared in next version, or that the package Y version 0.12.3 is more stable than the package X version 2.1 that I chose, or that oh in fact this package function is TODO so I have to switch to another package because it's been marked TODO for 13 years, or that I have to ditch the package I use when my program grows because it does have the extra features I now need and I should have picked up another one from the start, etc.

So I try as much as possible to stay away from packages which are not in Core. The problem now is that even those 'standard' modules are in fact not so standard for Perl distributions which may omit some of them...

And then you have to fight between the packages provided by your OS/Perl distribution and the ones provided by CPAN...

I sometimes end up rewriting everything in C, where there is one standard library, and then de facto standard/widespread libraries with not many alternatives, so it's hard to pick a wrong one.

-------

Same problems for CTAN (Latex). Plenty of packages but most of them are incompatible with some others. In the end you may not be able to use them if you happen to need the 'wrong' combination of features.

Post reply on HN