The Rust Platform • Hacker News Board

Re: The Rust Platform

#81

Post by tibbe » Thu, Jul 28, 2016, 2:42 AM UTC

catnaroek wrote: post #62

tibbe wrote: post #39

I wouldn't recommend following the Haskell approach. It hasn'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). Small vs large standard library: A small standard library with most functionality in independent, community-maintained packages has given us API fri…

Haskell's actual problem isn't the lack of a comprehensive standard library, but rather the presence of core language features that actively hinder large-scale modular programming. Type classes, type families, orphan instances and flexible instances all conspire to make as difficult as possible to determine whether two modules can be safely linked. Making things worse, whenever two alternatives are available for achi…

There can be more than one problem, including having a small standard library.

Re: The Rust Platform

#82

Post by vvanders » Thu, Jul 28, 2016, 2:43 AM UTC

rcthompson wrote: post #73

yoshuaw wrote: post #70

If a language is to play the long game, they must be conservative on what they add. Even a minimal runtime like Node is still wounded by the addition of a few broken interfaces into the core platform (even emitters, streams, domains to name a few). These cannot be stripped out of the platform because they're "blessed" and now everyone will forever have a bad time. I suggest we don't do that for Rust. For a language t…

> These cannot be stripped out of the platform because they're "blessed" and now everyone will forever have a bad time. I suggest we don't do that for Rust. It sounds like the proposal in the OP avoids this problem by having versioned platforms that are independent of the Rust version. So if something turns out to be a bad idea, it can be stripped out of later platform versions and replaced with something better with…

Yeah, I really liked how DirectX did versioning in that respect. Lets you improve the API while preserving backwards API and signature. If you can give Microsoft something it's that they do backwards compatibility well.

I don't see why that couldn't be worked into this idea.

Re: The Rust Platform

#83

Post by catnaroek » Thu, Jul 28, 2016, 2:50 AM UTC

tibbe wrote: post #81

catnaroek wrote: post #62

Earlier quoted context omitted.

Haskell's actual problem isn't the lack of a comprehensive standard library, but rather the presence of core language features that actively hinder large-scale modular programming. Type classes, type families, orphan instances and flexible instances all conspire to make as difficult as possible to determine whether two modules can be safely linked. Making things worse, whenever two alternatives are available for achi…

There can be more than one problem, including having a small standard library.

The lack of a standard library can be fixed relatively easily: write libraries! OTOH, the existence of anti-modular language features that are extensively used in several major libraries, is a more serious problem, because:

(0) It means that libraries in general won't play nicely with each other, unless they're explicitly designed to do so.

(1) It can't be fixed without throwing away code.

Re: The Rust Platform

#84

Post by brandonbloom » Thu, Jul 28, 2016, 2:51 AM UTC

kibwen wrote: post #72

tibbe wrote: post #39

I wouldn't recommend following the Haskell approach. It hasn'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). Small vs large standard library: A small standard library with most functionality in independent, community-maintained packages has given us API fri…

> Empirically, languages that have large standard > libraries (e.g. Java, Python, Go) seem to do better than > their competitors. You seem to be overlooking the ultimate counterexample: C. :P

You were being down voted, maybe for perceived snark, but I think you raise an interesting point.

To me, C did have a standard library: Unix. It'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.

There is another interesting potential counter example: Lua. It's minimalistic standard library is part of what makes it so attractive for embedding, eg. in game engines. However, Lua's embedding API is so good, you could almost say that it comes with a large standard library too: Your existing C code!

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'd reasonably choose to build something "from scratch", 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.

It's one thing to build a layered system with a small core. It's another thing to completely ignore the fact that the libraries and community _are_ the language, in the only ways that actually matter.

Re: The Rust Platform

#85

Post by goodplay » Thu, Jul 28, 2016, 2:52 AM UTC

sitkack wrote: post #76

pcwalton wrote: post #59

Earlier quoted context omitted.

I don't think most of these are applicable to Rust. > - Conversions between our 5(!) string types are very common. > - Standard library I/O modules cannot use new, de-facto standard string types (i.e. `Text` and `ByteString`) defined outside it because of dependency cycle. We have one string type defined in std, and nobody is defining new ones (modulo special cases for legacy encodings which would not be worth pollut…

I think rust needs to slow down in this regard. I have been with Python since 1999 and the stdlib has held it back, I have also used Scala and Haskell and have witness the mess that platform libs on each have caused. What Rust has right now is pretty amazing. What needs to happen is a way for devs to easily break the dependency cycle and include multiple versions of the same crate. Something that has plagued Haskell.…

If you can, could you elaborate more on python's stdlib holding it back? I think batteries-included experience is one of the reasons why so many people (including myself) use python.

It's also one of the features I sorely miss when using Rust. Luckily, Rust's stdlib is starting to tend towards being more practical with recent additions like system time.

Re: The Rust Platform

#86

Post by brandonbloom » Thu, Jul 28, 2016, 2:53 AM UTC

saghm wrote: post #77

kibwen wrote: post #72

Earlier quoted context omitted.

> Empirically, languages that have large standard > libraries (e.g. Java, Python, Go) seem to do better than > their competitors. You seem to be overlooking the ultimate counterexample: C. :P

JS, too, right? Forget "large" standard library, there really isn't any standard library at all

You don't consider the dynamic, rich document presentation engine that is HTML to be a standard "library"? Seems like it is to me.

Re: The Rust Platform

#87

Post by sitkack » Thu, Jul 28, 2016, 3:15 AM UTC

goodplay wrote: post #85

sitkack wrote: post #76

Earlier quoted context omitted.

I think rust needs to slow down in this regard. I have been with Python since 1999 and the stdlib has held it back, I have also used Scala and Haskell and have witness the mess that platform libs on each have caused. What Rust has right now is pretty amazing. What needs to happen is a way for devs to easily break the dependency cycle and include multiple versions of the same crate. Something that has plagued Haskell.…

If you can, could you elaborate more on python's stdlib holding it back? I think batteries-included experience is one of the reasons why so many people (including myself) use python. It's also one of the features I sorely miss when using Rust. Luckily, Rust's stdlib is starting to tend towards being more practical with recent additions like system time.

The 'std lib is where libraries go to die' was invented by Python. The libs are shallow, don't break backwards compat and provide a substandard experience. Things that continue to improve provide an out of tree alternative package name. Python codebases that are resilient don't use much of "core", arrow for time, requests for http, simplejson, etc. Using core is an antipattern that will get you stuck on a version of the language which is ridiculous.

Linking the language and the libraries together is a mistake.

Re: The Rust Platform

#88

Post by kibwen » Thu, Jul 28, 2016, 3:19 AM UTC

brandonbloom wrote: post #86

saghm wrote: post #77

Earlier quoted context omitted.

JS, too, right? Forget "large" standard library, there really isn't any standard library at all

You don't consider the dynamic, rich document presentation engine that is HTML to be a standard "library"? Seems like it is to me.

HTML doesn't do anything for JS other than provide a way to create visual interfaces. It might be comparable to the role that `tkinter` plays for Python's stdlib, but HTML alone is emphatically not a standard library.

Re: The Rust Platform

#89

Post by kibwen » Thu, Jul 28, 2016, 3:21 AM UTC

brandonbloom wrote: post #84

kibwen wrote: post #72

Earlier quoted context omitted.

> Empirically, languages that have large standard > libraries (e.g. Java, Python, Go) seem to do better than > their competitors. You seem to be overlooking the ultimate counterexample: C. :P

You were being down voted, maybe for perceived snark, but I think you raise an interesting point. To me, C did have a standard library: Unix. It'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. There is another interesting potential counter example: Lua. It's minimalistic standard library…

  > It's another thing to completely ignore the fact that 
  > the libraries and community _are_ the language, in the 
  > only ways that actually matter.

I'm unclear, what is this aimed at? Who's ignoring anything?

Re: The Rust Platform

#90

Post by ufo » Thu, Jul 28, 2016, 3:28 AM UTC

brandonbloom wrote: post #84

kibwen wrote: post #72

Earlier quoted context omitted.

> Empirically, languages that have large standard > libraries (e.g. Java, Python, Go) seem to do better than > their competitors. You seem to be overlooking the ultimate counterexample: C. :P

You were being down voted, maybe for perceived snark, but I think you raise an interesting point. To me, C did have a standard library: Unix. It'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. There is another interesting potential counter example: Lua. It's minimalistic standard library…

Lua's lack of a stdlib is also a curse. I can't imagine how many incompatible versions of string.trim and OOP libraries are out there in the wild right now...

Things have been getting better lately because of Luarocks but its still an uphill battle.