<story><title>The Rust Platform</title><url>https://aturon.github.io/blog/2016/07/27/rust-platform/</url></story><parent_chain><item><author>kibwen</author><text>&lt;p&gt;&lt;pre&gt;&lt;code&gt;  &amp;gt; Empirically, languages that have large standard 
  &amp;gt; libraries (e.g. Java, Python, Go) seem to do better than 
  &amp;gt; their competitors.
&lt;/code&gt;&lt;/pre&gt;
You seem to be overlooking the ultimate counterexample: C. :P</text></item><item><author>tibbe</author><text>I wouldn&amp;#x27;t recommend following the Haskell approach. It hasn&amp;#x27;t worked well for us. (I took part in creating the Haskell Platform and the process used to add packages to it. I also used to maintain a few of our core libraries, like our containers packages and networking).&lt;p&gt;Small vs large standard library:&lt;p&gt;A small standard library with most functionality in independent, community-maintained packages has given us API friction as types, traits (type classes), etc are hard to coordinate across maintainers and separate package release cycles. We ended up with lots of uncomfortable conversions at API boundaries.&lt;p&gt;Here&amp;#x27;s a number of examples of problems we currently have:&lt;p&gt;- Conversions between our 5(!) string types are very common.&lt;p&gt;- Standard library I&amp;#x2F;O modules cannot use new, de-facto standard string types (i.e. `Text` and `ByteString`) defined outside it because of dependency cycle.&lt;p&gt;- Standard library cannot use containers, other than lists, for the same reason.&lt;p&gt;- No standard traits for containers, like maps and sets, as those are defined outside the standard library. Result is that code is written against one concrete implementation.&lt;p&gt;- Newtype wrapping to avoid orphan instances. Having traits defined in packages other than the standard library makes it harder to write non-orphan instances.&lt;p&gt;- It&amp;#x27;s too difficult to make larger changes as we cannot atomically update all the packages at once. Thus such changes don&amp;#x27;t happen.&lt;p&gt;Empirically, languages that have large standard libraries (e.g. Java, Python, Go) seem to do better than their competitors.</text></item></parent_chain><comment><author>brandonbloom</author><text>You were being down voted, maybe for perceived snark, but I think you raise an interesting point.&lt;p&gt;To me, C did have a standard library: Unix. It&amp;#x27;s a runtime system too! Due to the nature of the original C bootstrapping process it just happens to be possible to remove this standard library, and Windows was evidence of this.&lt;p&gt;There is another interesting potential counter example: Lua. It&amp;#x27;s minimalistic standard library is part of what makes it so attractive for embedding, eg. in game engines. However, Lua&amp;#x27;s embedding API is so good, you could almost say that it comes with a large standard library too: Your existing C code!&lt;p&gt;I guess my larger point is that languages rarely are able to stand completely on their own. They need some sort of valuable body of code to justify people to choose the language and libraries together. It might have been the case 40 years ago that you&amp;#x27;d reasonably choose to build something &amp;quot;from scratch&amp;quot;, but today, if you start on an island, you need to build a bridge, lest you remain on an island forever. Better to start on the mainland.&lt;p&gt;It&amp;#x27;s one thing to build a layered system with a small core. It&amp;#x27;s another thing to completely ignore the fact that the libraries and community _are_ the language, in the only ways that actually matter.</text></comment>
<story><title>The Rust Platform</title><url>https://aturon.github.io/blog/2016/07/27/rust-platform/</url></story><parent_chain><item><author>kibwen</author><text>&lt;p&gt;&lt;pre&gt;&lt;code&gt;  &amp;gt; Empirically, languages that have large standard 
  &amp;gt; libraries (e.g. Java, Python, Go) seem to do better than 
  &amp;gt; their competitors.
&lt;/code&gt;&lt;/pre&gt;
You seem to be overlooking the ultimate counterexample: C. :P</text></item><item><author>tibbe</author><text>I wouldn&amp;#x27;t recommend following the Haskell approach. It hasn&amp;#x27;t worked well for us. (I took part in creating the Haskell Platform and the process used to add packages to it. I also used to maintain a few of our core libraries, like our containers packages and networking).&lt;p&gt;Small vs large standard library:&lt;p&gt;A small standard library with most functionality in independent, community-maintained packages has given us API friction as types, traits (type classes), etc are hard to coordinate across maintainers and separate package release cycles. We ended up with lots of uncomfortable conversions at API boundaries.&lt;p&gt;Here&amp;#x27;s a number of examples of problems we currently have:&lt;p&gt;- Conversions between our 5(!) string types are very common.&lt;p&gt;- Standard library I&amp;#x2F;O modules cannot use new, de-facto standard string types (i.e. `Text` and `ByteString`) defined outside it because of dependency cycle.&lt;p&gt;- Standard library cannot use containers, other than lists, for the same reason.&lt;p&gt;- No standard traits for containers, like maps and sets, as those are defined outside the standard library. Result is that code is written against one concrete implementation.&lt;p&gt;- Newtype wrapping to avoid orphan instances. Having traits defined in packages other than the standard library makes it harder to write non-orphan instances.&lt;p&gt;- It&amp;#x27;s too difficult to make larger changes as we cannot atomically update all the packages at once. Thus such changes don&amp;#x27;t happen.&lt;p&gt;Empirically, languages that have large standard libraries (e.g. Java, Python, Go) seem to do better than their competitors.</text></item></parent_chain><comment><author>saghm</author><text>JS, too, right? Forget &amp;quot;large&amp;quot; standard library, there really isn&amp;#x27;t any standard library at all</text></comment>