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?
How about: "std is where code goes when it's done".
As is, really done. The API's won't need changing.
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?
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?
> 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?
CSV, logger, json, fileutils, tempfile, pp, and on and on are used all the time...
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-j...
[1]: https://github.com/search?q=simplejson+ImportError&type=Code...
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).
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.
That fact that thousands of files catching ImportError does not necessarily implies folks are questioning stdlib's stability. That merely means some people are deliberately choosing to prefer simplejson over json. The benchmarks demonstrated json module before Python 3 could be slower than simplejson, but json module since Python 3 has beaten simplejso in terms of speed of execution. Furthermore, there are old Stackoverflow threads on usjon vs simplejson vs json regarding performance. All the above would naturally suggest folks who choose to prefer simplejson over json is due to the concern of speed, rather than opinion on stability.
Also, stability is the wrong term for the problem you are describing. Agility is probably the better word. Python release tends ot be backward compatible (of course except Python 2 vs Python 3 and a few other modules like asyncio). Python core developers try not to break applications. If anything, non-core libraries will break compatibility more frequently without having to face larger opposiitons; I can break simplejson if I were the maintainer of simplejson. The consequence is maybe a couple angry GitHub issues and a few blog posts, unlike Python 3 which still gets a lot of angry media coverage till this day.
The problem with stdlib is absolutely about agility. The core community is extremely small. It can take many weeks and sometimes months to get your commit merged. The reason I like to keep stdlib around is good citizenship. I would love to have requests in the stdlib, but in a more agile and more frequent release. Python isn't the only player. OS distro are also responsible for the slowness. There's been discussion on python-dev regarding more frequent release and even potentially breaking up stdlib could be an option for the Python community.
Even more code just use the standard json package without any fallback. The ease of development or deployment is clearly worth more to them than what small speed advantage they can get from going with the external dependency.
The calculus will be different for Rust, of course, with different build and deployment system.
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.
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
1. Easy to use
2. Have standardized syntax for flags across languages
3. Be easy to maintain
4. Be well documented so that I can use them a year or 5 years from now.
My applications often have complex syntax. For instance I work in frequent pattern mining, the basic syntax for some of my programs looks like:
program [global options] -o <output> --support=<int> \
<datatype> [data-type-options] <path-to-data>
<algorithm> [algorithm-options]
<filter-chains>
<logging-and-serialization>
I write programs in more languages than just Go, and the programs in Go need to work the same way the programs in other languages work. That means GNU option syntax, which is the superior syntax for my needs in any case.
http://www.slideshare.net/jpetazzo/docker-and-go-why-did-we-...
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.
>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).
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/ ).
Plus, there are plenty of ways to test standard SQL, you can easily do so through stored procedures.
Read this if you think I'm wrong: https://github.com/bradfitz/go-sql-test/blob/master/src/sqlt...
Great abstraction, right? Love how you have to mangle the raw SQL right? no. It's a bad abstraction.
When you test the implementation and you have to know the details of the implementation to test it, that's like, the definition of a bad abstraction.
It is what it is.
...and ultimately, we're stuck with it because its part of the standard library.
/shrug