91–100 of 256 posts
Earlier quoted context omitted.
Cargo.toml isn't in language. It's for the package manager and the build tool. The language shouldn't be married to either thing. As for dropping extern crate, it either marries rust to cargo, or it makes imports implicit. Neither is desirable.
One possibility is for rustc to take extern crate declarations as commandline args and for cargo to invoke them based on what's in the toml.
I'm a bit worried when a language develops a "platform" and an "ecosystem". This usually means you need to bring in a large amount of vaguely relevant stuff to do anything. It adds another layer of cruft, and more dependencies. Write standalone tools, but don't create a "platform". Don't make the use of the language dependent on your tools. C++ does not have a "platform". Nor does it need one.
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.…
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…
But if you have a large standard library and want to break the API, you can. If you have 100 different libs that are basically "standard" (who doesn't have `mtl` in their applications at this point), now you have to coordinate 100 different library updates roughly at the same time. If you forget even one of them, then you've broken everything. I think the argument for a large Prelude/standard lib is similar to Google…
see: javascript
Earlier quoted context omitted.
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.
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...
CSV, logger, json, fileutils, tempfile, pp, and on and on are used all the time...
Earlier quoted context omitted.
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?
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.
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.
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…
Earlier quoted context omitted.
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...
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...
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…
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…
Out of curiousity: what do the 5 string types do differently?