> Virtually everything in the Rust ecosystem is permissively licensed.

I just did our license audit and 100% of our shipped deps were Apache | MIT. If you can clear those two licenses with legal, you should be good to go for virtually any crate.

Might be worth releasing my one liner for this if anyone else finds it useful.

Do it! This is HN after all, no better place to gain free karma and appreciation for your command line prowess

That does sound pretty useful!

Please do.

The spartan C standard library was what my comment regarding 'small languages' was referencing. I don't have much experience with many of C's contemporaries, but for an opposing view take for instance the standard library of Ada ( I use the term 'standard' here to connote the library that is mandated as per the standard of these languages ). It is definitely orders of magnitude larger than that of C, and takes a fundamentally different perspective. Ada's standard library, while dated by modern standards, looks more like it was designed to address the specific needs of its domain. Mind you, it could be argued that C's stdlib was also, if you restrict its domain to 'OS development'. My point is that for a language like Rust, that does not have a tiny stdlib like C, its standard library should address the common use cases required by its developers. Node.js is another bad offender here. If you look at the most popular npm modules, you'll see things like 'body-parser' and 'async', which clearly show gaps in the functionality that Node's stdlib is catering for.

Which is only true if we forget about POSIX support that everyone kind of expects in every platform that offers C compilers.

Actually they don't, C standardization just dumped that standard library into POSIX instead, which I why all major OS end up supporting POSIX if they want to make C developers feel at home.

And you usually see them cursing the platforms that don't care about POSIX support.

And ISO C++ has repented themselves from following C's footsteps and have been improving the standard library since C++11, mostly by integrating boost libraries.

I don't understand what point you're trying to make. All I did was ask a simple question: if trust in Rust is hard, how do you handle trust in other ecosystems? The details on exactly how big or how small the standard libraries are (or why they are that way) are less important for this particular question. Consider the size of Python's standard library vs C or C++ or Rust. The size of C or C++ is much closer to Rust's size than Python's size.

Also, while some of your historical context is interesting, I don't really appreciate your editorialization, which I often find is off the mark personally.

My point is that although many only think about ISO C libc when talking about C's standard library, the reality is that with a few exceptions, libc always goes alongside POSIX across the large majority of platforms with a C compiler.

So in reality POSIX complements libc as C's "runtime platform", even though ISO C never considered to make libc that big.

My historical context is how I experienced how things went, throughout the media we had available at the time.

I surely welcome factual corrections when I fail off the mark.

Everyone benefits from learning proper history facts.

> My point is that although many only think about ISO C libc when talking about C's standard library

I wasn't. Even with POSIX, it is spartan by today's standards. Look at the standard libraries of Python and Go. POSIX doesn't have JSON (de)serialization, HTTP servers, XML parsing and a whole boatload of other crap. So I don't think there is anything wrong with my characterization.