Rust and the limits of swarm design
esr.ibiblio.org
Rust and the limits of swarm design
1–10 of 55 posts
Re: Rust and the limits of swarm design
#2i 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.
Re: Rust and the limits of swarm design
#3i 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 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 standard library and big frameworks and tends to keep working for years.
Programming language designers should see themselves as builders and curators of great standard libraries, the language itself is almost incidental to that goal.
Re: Rust and the limits of swarm design
#4i 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 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.
Re: Rust and the limits of swarm design
#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?
Re: Rust and the limits of swarm design
#6i 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 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…
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 ecosystem. Heck, libs blessed by the language designers aren't even always the best choice - just look at json manipulation in .NET; you get multiple different stdlib ways to work with json, yet the community still gathers around the much better JSON.NET package.
In terms of value proposition, I think the author is just hankering for some .NET style support agreements in order to hedge his maintenance cost bets - and I'm sure there are or will be plenty of consultancies willing to provide this service, so long as the demand exists. That open source language users are entitled enough to expect this service for free from language maintainers... I'm not sure that's completely justifiable.
Re: Rust and the limits of swarm design
#7Earlier 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.
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.
Re: Rust and the limits of swarm design
#8Actually, 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 validation.
But this article raises an other question : if you want 10 years long stability, is it wise to rely on third party code? If you plan on maintaining your own project that long, it's probably acceptable to take time to write your own implementation and maintain it. Or you could even use a third party dependency, then progressively replace it with your own API compatible implementation.
Re: Rust and the limits of swarm design
#9> 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.
Re: Rust and the limits of swarm design
#10Earlier 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…
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 ecosystem of third-party packages.
Maintenance costs affect the authors of open source packages even more than they affect commercial users. They are working for free and in their spare time. A rich standard library makes a language attractive to people who want to write packages.