5 ms·

One of the common mantras I've heard among Rust core devs is "std is where code goes to die". Where do you feel the line should be drawn between standard lib an

One of the common mantras I've heard among Rust core devs is "std is where code goes to die". Where do you feel the line should be drawn between standard lib and external libraries?

skybrian 10y ago
Maybe a change in attitude? Stability can be a good thing. Go's standard library doesn't change that much, and that's a strength. How about: "std is where code goes when it's done". As is, really done. The API's won't need changing.
- steveklabnik 10y ago
  In the Ruby world, very few people use the standard library because it's got so many flaws, and they can't be fixed. So you end up with Nokogiri rather than REXML, all the various HTTP libs rather than net/*, etc. So it just ends up being bytes sent over the wire, wasting disk and bandwidth...
  - skybrian 10y ago
    Well, the trick is to actually get it right before standardizing it - much easier said than done. Keeping the standard library small helps with that since the bar is higher.
    - pcwalton 10y ago
      > Well, the trick is to actually get it right before standardizing it - much easier said than done. And that's what we're doing. > Keeping the standard library small helps with that since the bar is higher. But weren't you just advocating for a large standard library?
      - skybrian 10y ago
        I guess I didn't understand what was meant by "where code goes to die". Graduation != dying.
  - saysjonathan 10y ago
    I wonder if identifying the atomic aspects of what you intend your language to be used for ultimately helps in narrowing down what should be in std lib. Go prioritizes network programming and bundles the necessary components, like http & rpc servers and json. The http libraries are extensible enough to allow for customization where it's wanted (like http mux) while still creating a canonical implementation that'a still viable. Has Rust identified the core demographics of who they're targeting in order to provide the most applicable platform? Is the target everyone and all application type, therefore there is no default platform? Edit: To put it another way, is there a set of packages that is either necessary for rust, rust development, or most development in rust? If std lib includes everything necessary, then who are you targeting with the default platform?
    - steveklabnik 10y ago
      > Has Rust identified the core demographics of who they're targeting > in order to provide the most applicable platform? Is the target > everyone and all application type, therefore there is no default platform? Our target audience is still a bit too broad; "systems programming" can mean a lot of things. Application developers build a _lot_ of different applications, those who embed Rust in other languages have different set of requirements, OS/embedded devs have another. There's a lot of stuff in common, but there's also significant differences.
  - anamoulous 10y ago
    I wouldn't say very few people use the standard library? CSV, logger, json, fileutils, tempfile, pp, and on and on are used all the time...
    - steveklabnik 10y ago
      There are some parts that are good, and some parts that are bad, for sure.
- jsmthrowaway 10y ago
  The counterpoint being Python simplejson vs json. Most working Python developers I know try simplejson first (when they are not controlling dependencies in the environment) and fall back to stdlib json because simplejson got much faster as it evolved outside of the standard library[0]. Most who don't know this go the other way[1]. There are a number of counterpoints in Python, in fact, which epitomizes the "standard library is where code goes to die" thing. Adding modules to the standard library in Python is, more often than not, overall a bad thing for the module. Python has not historically been awesome with standard library quality, either; see Java-style logging and unittest (I mean naming, not "Java idiomatic," which I think is fine for both). This comes down to release cycles for the language, mostly. So I think API stability is a bit of a red herring when discussing Python, at least. I tend to appreciate languages where I can remove the entire standard library and "start over," like C. (Yes, you can.) This can be good for a number of things: porting, embedding, frameworks, and so on. [0]: http://artem.krylysov.com/blog/2015/09/29/benchmark-python-json-libraries/ http://artem.krylysov.com/blog/2015/09/29/benchmark-python-j... [1]: https://github.com/search?q=simplejson+ImportError&type=Code&utf8= https://github.com/search?q=simplejson+ImportError&type=Code...
  - yeukhon 10y ago
    Case by case. If you absolutely need the speed, go with what gives you the boost. Otherwise, I always encourage people to use json and not have to have an additional external dependency. One of the reasons some people was using simplejson isn't really speed IMO, but because json module was not in stdlib until what, late 2.6? I try to keep my dependency list as tiny as possible, and use what makes sense for my development and for future maintenance. Also, look at the result, in Python 3, json module beats simplejson. But speed isn't the only thing that matters, it seems ujson would use more memory (https://news.ycombinator.com/item?id=9326499 https://news.ycombinator.com/item?id=9326499).
    - jsmthrowaway 10y ago
      It wasn't "late" 2.6 (that's not how Python releases work for changes like that), it was 2.6, which was October 2008. Nearly eight years ago. Most distributions are even on Python 2.6 now. Anyway, my point isn't the specific example. That you and I even have this discussion at all and that there are hundreds of thousands of caught ImportErrors on that specific example on GitHub is my point regarding standard library stability; folks seem to think the standard library is the end-all (wherein we wouldn't be having this conversation at all), but Python has shown it is anything but when not carefully maintained. I think Rust is wise to approach this with caution. Honestly, I'm not extremely familiar with Rust, but it seems it elected the C approach where you can gut the language. A+. Good. How it should be for a systems language like that, because now it can be ported, embedded, and so on.
- threatofrain 10y ago
  I think that Go can pull off a good standard library because there's a big corporate sponsor behind it, whereas Ruby may have had difficulty with its standard library for the lack of a sponsor. Standard doesn't mean completely done. Standard should be able to accomodate things like HTTP2, as Go has done, whether that means expanding the API or whatever.
  - tibbe 10y ago
    The "big corporate sponsor" argument often comes up when discussing language success. Google doesn't really put more than a few people's time into Go, the rest is open source. Other languages like Python didn't have any real backing until way after success.
    - pjmlp 10y ago
      Guido and a few other core developers were employed to work full time on Python for quite some time, even before it became successful.
- pcwalton 10y ago
  > Maybe a change in attitude? Stability can be a good thing. I haven't seen anybody say otherwise. New standard library APIs are stabilized at a steady clip with every new release: https://github.com/rust-lang/rust/blob/master/RELEASES.md https://github.com/rust-lang/rust/blob/master/RELEASES.md
- kibwen 10y ago
  Go isn't immune to the problem either. See the `flag` package, which is something that new users are encouraged to avoid in favor of e.g. https://github.com/jessevdk/go-flags https://github.com/jessevdk/go-flags .
  - ainar-g 10y ago
    I am a Go programmer and I've never seen anyone anywhere encouraging people to use anything over the flag package. How did you get such impression?
    - the_mitsuhiko 10y ago
      Everybody I have ever seen do CLI applications in Go will recommend heavily against it.
      - themihai 10y ago
        The package you mentioned has about 200 imports. Compare that with the standard package. https://godoc.org/?q=Flag https://godoc.org/?q=Flag
        timtadh 10y ago
        If you want to write command line apps that conform to the GNU flags convention you can't use the "flag" library. I wrote my own simple getopt implementation (github.com/timtadh/getopt) years ago so I could just get some work done. It works fine and has no dependencies. I write a lot of complicated command line applications and having a small simple getopt implementation makes it a lot easier. Sometimes a higher level tool would be nice but I have never found one I actually like.
        skybrian 10y ago
        Why do minor variations in flag syntax matter so much you'd write your own? It seems easier to adjust to using the standard flag package.
- shadowmint 10y ago
  Sql? It does all the wrong things; singletons, no testability, cgo for implementations, side effects and you have to use every database differently based on their individual semantics. Virtually everyone I've ever spoken to either uses a high level wrapper around the sql library or a no-sql solution. That's the definition of 'stdlib is where packages go to die'. It's not that the API is unusable, it's just basically not used by the community because there are other better things out there...but you're stuck with it forever, because it's there and some people do use it, and changing or removing it would be a breaking change. Anyhow, we're just speculating. Does anyone actually collect metrics about the usage of different parts of the stdlib for any language? Without hard data to back it up, you couldn't really make a strong argument either way.
  - saysjonathan 10y ago
    I didn't see anyone actually mention sql so I'll just assume your first line is to be interpreted as "sql is the counterexample of why Go's standard library is not as great as it may seem." >Virtually everyone I've ever spoken to either uses a high level wrapper around the sql library or a no-sql solution. How does that reflect the quality of the std lib implementation? All the high-level wrappers I've seen still utilize database/sql, they just provide convenience methods on top of the existing functionality. Are people using NoSQL databases because database/sql is so bad or merely because that technology fits their project's requirements? >That's the definition of 'stdlib is where packages go to die'. steveklabnik's example of Ruby XML parsing libraries is a better example of this, if only because the std lib implementations are almost completely ignored by all other gems. Go's database/sql is actively used outside of the std lib to great affect, whether in wrappers and ORMs or in implementing other SQL databases (like Postgres).
  - ZenoArrow 10y ago
    > "Sql? It does all the wrong things; singletons, no testability, cgo for implementations, side effects and you have to use every database differently based on their individual semantics." SQL has its flaws, but it is testable. The testing approaches available vary depending on the implementation. For example, can write unit tests for SQL Server (using tSQLt, to give one example: http://tsqlt.org/ http://tsqlt.org/ ).
- lmm 10y ago
  It's too early to draw conclusions about Go's standard library. Python's standard library seemed like a good idea at the time too. Come back in 15 years and let's see how good it looks then.

One of the common mantras I've heard among Rust core devs is "std is where code goes to die". Where do you feel the line should be drawn between standard lib and external libraries?

skybrian 10y ago

Maybe a change in attitude? Stability can be a good thing. Go's standard library doesn't change that much, and that's a strength. How about: "std is where code goes when it's done". As is, really done. The API's won't need changing.

steveklabnik 10y ago
In the Ruby world, very few people use the standard library because it's got so many flaws, and they can't be fixed. So you end up with Nokogiri rather than REXML, all the various HTTP libs rather than net/*, etc. So it just ends up being bytes sent over the wire, wasting disk and bandwidth...
- skybrian 10y ago
  Well, the trick is to actually get it right before standardizing it - much easier said than done. Keeping the standard library small helps with that since the bar is higher.
  - pcwalton 10y ago
    > Well, the trick is to actually get it right before standardizing it - much easier said than done. And that's what we're doing. > Keeping the standard library small helps with that since the bar is higher. But weren't you just advocating for a large standard library?
    - skybrian 10y ago
      I guess I didn't understand what was meant by "where code goes to die". Graduation != dying.
- saysjonathan 10y ago
  I wonder if identifying the atomic aspects of what you intend your language to be used for ultimately helps in narrowing down what should be in std lib. Go prioritizes network programming and bundles the necessary components, like http & rpc servers and json. The http libraries are extensible enough to allow for customization where it's wanted (like http mux) while still creating a canonical implementation that'a still viable. Has Rust identified the core demographics of who they're targeting in order to provide the most applicable platform? Is the target everyone and all application type, therefore there is no default platform? Edit: To put it another way, is there a set of packages that is either necessary for rust, rust development, or most development in rust? If std lib includes everything necessary, then who are you targeting with the default platform?
  - steveklabnik 10y ago
    > Has Rust identified the core demographics of who they're targeting > in order to provide the most applicable platform? Is the target > everyone and all application type, therefore there is no default platform? Our target audience is still a bit too broad; "systems programming" can mean a lot of things. Application developers build a _lot_ of different applications, those who embed Rust in other languages have different set of requirements, OS/embedded devs have another. There's a lot of stuff in common, but there's also significant differences.
- anamoulous 10y ago
  I wouldn't say very few people use the standard library? CSV, logger, json, fileutils, tempfile, pp, and on and on are used all the time...
  - steveklabnik 10y ago
    There are some parts that are good, and some parts that are bad, for sure.
jsmthrowaway 10y ago
The counterpoint being Python simplejson vs json. Most working Python developers I know try simplejson first (when they are not controlling dependencies in the environment) and fall back to stdlib json because simplejson got much faster as it evolved outside of the standard library[0]. Most who don't know this go the other way[1]. There are a number of counterpoints in Python, in fact, which epitomizes the "standard library is where code goes to die" thing. Adding modules to the standard library in Python is, more often than not, overall a bad thing for the module. Python has not historically been awesome with standard library quality, either; see Java-style logging and unittest (I mean naming, not "Java idiomatic," which I think is fine for both). This comes down to release cycles for the language, mostly. So I think API stability is a bit of a red herring when discussing Python, at least. I tend to appreciate languages where I can remove the entire standard library and "start over," like C. (Yes, you can.) This can be good for a number of things: porting, embedding, frameworks, and so on. [0]: http://artem.krylysov.com/blog/2015/09/29/benchmark-python-json-libraries/ http://artem.krylysov.com/blog/2015/09/29/benchmark-python-j... [1]: https://github.com/search?q=simplejson+ImportError&type=Code&utf8= https://github.com/search?q=simplejson+ImportError&type=Code...
- yeukhon 10y ago
  Case by case. If you absolutely need the speed, go with what gives you the boost. Otherwise, I always encourage people to use json and not have to have an additional external dependency. One of the reasons some people was using simplejson isn't really speed IMO, but because json module was not in stdlib until what, late 2.6? I try to keep my dependency list as tiny as possible, and use what makes sense for my development and for future maintenance. Also, look at the result, in Python 3, json module beats simplejson. But speed isn't the only thing that matters, it seems ujson would use more memory (https://news.ycombinator.com/item?id=9326499 https://news.ycombinator.com/item?id=9326499).
  - jsmthrowaway 10y ago
    It wasn't "late" 2.6 (that's not how Python releases work for changes like that), it was 2.6, which was October 2008. Nearly eight years ago. Most distributions are even on Python 2.6 now. Anyway, my point isn't the specific example. That you and I even have this discussion at all and that there are hundreds of thousands of caught ImportErrors on that specific example on GitHub is my point regarding standard library stability; folks seem to think the standard library is the end-all (wherein we wouldn't be having this conversation at all), but Python has shown it is anything but when not carefully maintained. I think Rust is wise to approach this with caution. Honestly, I'm not extremely familiar with Rust, but it seems it elected the C approach where you can gut the language. A+. Good. How it should be for a systems language like that, because now it can be ported, embedded, and so on.
threatofrain 10y ago
I think that Go can pull off a good standard library because there's a big corporate sponsor behind it, whereas Ruby may have had difficulty with its standard library for the lack of a sponsor. Standard doesn't mean completely done. Standard should be able to accomodate things like HTTP2, as Go has done, whether that means expanding the API or whatever.
- tibbe 10y ago
  The "big corporate sponsor" argument often comes up when discussing language success. Google doesn't really put more than a few people's time into Go, the rest is open source. Other languages like Python didn't have any real backing until way after success.
  - pjmlp 10y ago
    Guido and a few other core developers were employed to work full time on Python for quite some time, even before it became successful.
pcwalton 10y ago
> Maybe a change in attitude? Stability can be a good thing. I haven't seen anybody say otherwise. New standard library APIs are stabilized at a steady clip with every new release: https://github.com/rust-lang/rust/blob/master/RELEASES.md https://github.com/rust-lang/rust/blob/master/RELEASES.md
kibwen 10y ago
Go isn't immune to the problem either. See the `flag` package, which is something that new users are encouraged to avoid in favor of e.g. https://github.com/jessevdk/go-flags https://github.com/jessevdk/go-flags .
- ainar-g 10y ago
  I am a Go programmer and I've never seen anyone anywhere encouraging people to use anything over the flag package. How did you get such impression?
  - the_mitsuhiko 10y ago
    Everybody I have ever seen do CLI applications in Go will recommend heavily against it.
    - themihai 10y ago
      The package you mentioned has about 200 imports. Compare that with the standard package. https://godoc.org/?q=Flag https://godoc.org/?q=Flag
      - timtadh 10y ago
        If you want to write command line apps that conform to the GNU flags convention you can't use the "flag" library. I wrote my own simple getopt implementation (github.com/timtadh/getopt) years ago so I could just get some work done. It works fine and has no dependencies. I write a lot of complicated command line applications and having a small simple getopt implementation makes it a lot easier. Sometimes a higher level tool would be nice but I have never found one I actually like.
        skybrian 10y ago
        Why do minor variations in flag syntax matter so much you'd write your own? It seems easier to adjust to using the standard flag package.
shadowmint 10y ago
Sql? It does all the wrong things; singletons, no testability, cgo for implementations, side effects and you have to use every database differently based on their individual semantics. Virtually everyone I've ever spoken to either uses a high level wrapper around the sql library or a no-sql solution. That's the definition of 'stdlib is where packages go to die'. It's not that the API is unusable, it's just basically not used by the community because there are other better things out there...but you're stuck with it forever, because it's there and some people do use it, and changing or removing it would be a breaking change. Anyhow, we're just speculating. Does anyone actually collect metrics about the usage of different parts of the stdlib for any language? Without hard data to back it up, you couldn't really make a strong argument either way.
- saysjonathan 10y ago
  I didn't see anyone actually mention sql so I'll just assume your first line is to be interpreted as "sql is the counterexample of why Go's standard library is not as great as it may seem." >Virtually everyone I've ever spoken to either uses a high level wrapper around the sql library or a no-sql solution. How does that reflect the quality of the std lib implementation? All the high-level wrappers I've seen still utilize database/sql, they just provide convenience methods on top of the existing functionality. Are people using NoSQL databases because database/sql is so bad or merely because that technology fits their project's requirements? >That's the definition of 'stdlib is where packages go to die'. steveklabnik's example of Ruby XML parsing libraries is a better example of this, if only because the std lib implementations are almost completely ignored by all other gems. Go's database/sql is actively used outside of the std lib to great affect, whether in wrappers and ORMs or in implementing other SQL databases (like Postgres).
- ZenoArrow 10y ago
  > "Sql? It does all the wrong things; singletons, no testability, cgo for implementations, side effects and you have to use every database differently based on their individual semantics." SQL has its flaws, but it is testable. The testing approaches available vary depending on the implementation. For example, can write unit tests for SQL Server (using tSQLt, to give one example: http://tsqlt.org/ http://tsqlt.org/ ).
lmm 10y ago
It's too early to draw conclusions about Go's standard library. Python's standard library seemed like a good idea at the time too. Come back in 15 years and let's see how good it looks then.