The Rust Platform

Post by steveklabnik » Thu, Jul 28, 2016, 5:22 PM UTC

saysjonathan wrote: post #63

steveklabnik wrote: post #49

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 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 sti…

  > 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?

Post by agmcleod » Thu, Jul 28, 2016, 5:48 PM UTC

hubert123 wrote: post #154

sametmax wrote: post #148

Earlier quoted context omitted.

You can still have a tiny install if you want to. But most people not knowing what to do will be able to have batteries included setup. Basically: people knowing will still have freedom, people not knowing will have an easier life. And in the end, in 2016, you generally don't care if you download a few extra 100Mo. If you do, you will just find spend the time to find to have a smaller setup.

people who dont know what to do exactly? Downloading a package? If they can't download a package then they have an entirely different problem to solve which they have to solve anyway if they want to ever productively program Rust.

Post by wyager » Thu, Jul 28, 2016, 6:23 PM UTC

losvedir wrote: post #202

wyager wrote: post #127

Earlier quoted context omitted.

You're right, I believe Haskell's fusion framework could be greatly improved (although it is the best production solution I'm aware of). However, how would you go about solving this? I don't think there's any generalized solution to the problem of creating no-overhead iteration from higher-level iterative combinators.

> Haskell's fusion framework could be greatly improved (although it is the best production solution I'm aware of). However, how would you go about solving this? Given that we're in a rust thread... are you familiar with rust's iterator fusion [0]? Basically there are three components: iterators (something like a source), iterator adapters (where all manipulations happen), and consumers (something like a sink). LLVM w…

Post by wyager » Thu, Jul 28, 2016, 6:27 PM UTC

catnaroek wrote: post #165

wyager wrote: post #162

Earlier quoted context omitted.

>OTOH, type families are sneaky, because they don't look any different from normal type constructors or synonyms. That is fair. I think we're on the same page at this point. You have made me realize that ML-style modules are useful in ways I did not realize before, so thanks for that. Question: How would you feel if the tradition was to do something like insert :: Ord a f => a -> Set f a -> Set f a That is, "f" is so…

Seems a lot more cumbersome than the direct ML solution: signature ORD = sig type t val t end functor RedBlackSet (E : ORD) :> SET = struct type elem = E.t datatype set = Empty | Red of set * elem * set | Black of set * elem * set (* ... *) end structure Foo = RedBlackSet (Int) structure Bar = RedBlackSet (Backwards (Int)) (* Foo.set and Bar.set are different abstract types! *)

Post by bshanks » Thu, Jul 28, 2016, 6:56 PM UTC

rtpg wrote: post #74

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…

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…