Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Sure it is. We're talking about what should and shouldn't be a dependency. The acute problem with left pad was npm's design, but the cultural problem (if you consider it a problem) was that anything depended upon something so small in the first place.


The circumstances that led to the left-pad fiasco were because of Javascript's uniquely anemic standard library (at least until very recently). Rust's stdlib is not small in the same way that Javascript's historic stdlib was. Rust's stdlib is narrow, yet deep: a relatively small number of modules that themselves provide a very large number of operations and convenience functions. Rust dependency graphs can get pretty big, but in practice they're nowhere near as big as the dependency graphs you'll see in big Node apps because the stdlib is so much more fleshed out. That order of magnitude difference is crucial; one might call it "microdependencies versus minidependencies".


Agree 100%. I think Rust's stdlib is useful and coherent, and shows the way for other libraries. It's a great piece of engineering.


Rust has the capability to, and I believe the developers have expressed they are amenable to, internalizing crates that become the best solutions for a problem.

Would you rather a flawed, or later deemed incomplete internal solution be implemented and then the language is forced to support it in perpetuity, or would you rather one or more solutions get tried and the best implementation and syntax eventually accepted into core?

EcmaScript can do the same, and finally has[1], but it moves so slowly and has so many competing interests that it seems to take forever for that to happen.

1: https://www.ecma-international.org/ecma-262/8.0/index.html#s...


Oh God no, haha. I started out in Python and I'm pretty sure all of us have fallen out of love with batteries included.

You can see what happens when you go too far the other way though. C has effectively no basic data structures like strings, lists, hash tables, etc., so anything you interface with has its own idea on how to handle that stuff. Library X might return an array of Things that's NULL terminated. Library Y might return an array of Thangs and a size_t output param. Or like you pointed out in JS, its standard library is full of holes so you get tiny projects that attempt to plug them, or larger projects that try to make JS into a specific kind of language (Underscore), or full on programming languages that transpile to it.

I just don't think the problem is definitively solved though. Personally I think Bytes should be in Rust's stdlib. I think bit and byte manipulation is a fundamental part of a language and there should be a standard way of doing it, especially if there are things like TCP/UDP and hash tables in there. I understand the arguments against; I really like the design of Rust's stdlib, but I feel like there's room for disagreement. That's all I'm saying :)


> the cultural problem (if you consider it a problem) was that anything depended upon something so small in the first place.

It's not a problem, in my view.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: