Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Rust Platform

aturon.github.io

Post reply on HN
Print view View original

231–240 of 256 posts

Re: The Rust Platform

#231

Post by catnaroek »

sclv wrote: post #209
catnaroek wrote: post #142

Earlier quoted context omitted.

> what purpose on god's green earth would be served by introducing univalence directly to haskell? Generally, when I want to reason about tricky data structures, what I do is: (0) Define a set-isomorphic auxiliary type that's easier to analyze, and whose operations are easier to implement, but have worse asymptotic performance. (1) Prove that transporting the operations on the auxiliary type along the isomorphism yie…

> I need univalence for this argument to hold water. No, you don't. Univalence is the axiom that transporting operations across such equivalences _always_ works. If you're doing equational reasoning directly it doesn't arise. Furthermore, all you need to do is to establish that the _type operations_ regarding one type respect the equivalence to the other type as an additional step. As you say "a monoid is a type plus…

> No, you don't. Univalence is the axiom that transporting operations across such equivalences _always_ works.

Sure, but the strategy I outlined is risky (as in “may lead to getting suck and having to undo work”) in a language where this isn't guaranteed to work.

> As you say "a monoid is a type plus two operations" -- so fine, we can treat the monoid And as the type bool and the dictionary of operations on it, and all this still works out.

Yup, but Haskell doesn't let you define types parameterized by entire algebraic structures. It only lets you define types parameterized by the carriers of algebraic structures.

Re: The Rust Platform

#232

Post by catnaroek »

wyager wrote: post #227
catnaroek wrote: post #165

Earlier quoted context omitted.

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! *)

That is more elegant! But do you think they're functionally more or less equivalent?

Assuming you don't mind plumbing value-level proxies all over the place, it's indeed functionally equivalent.

Re: The Rust Platform

#233

Post by AsyncAwait »

steveklabnik wrote: post #222
AsyncAwait wrote: post #178

If the aim of the Rust Platform is to provide a 'blessed set' of 3rd-party libraries, why not have something akin to an official, curated 'Awesome Rust', where depending on what you want to achieve you can get a streamlined list of well-maintained libraries, perhaps with user-submitted usage-examples, comments, alternatives and the like - that way, you're not constraining Rust itself to be in sync with all the 3rd-pa…

How is that different than the proposal? The only part that's maybe different is "feel essentially invisible", which is something that might happen, I'll grant you that. But I don't think that people feel invisible when some package is in a standard library, which is roughly equivalent here.

I just don't think that going beyond a simple website with 'blessed' crates has much benefit, but it certainly has a lot of disadvantages as outlined in this whole thread. I'm simply saying that if the goal is to have a central place to point to when somebody asks, 'how do I do X', then perhaps making a website/improving crates.io in this regard is the better approach for the continued growth of the still very much evolving Rust ecosystem, rather than creating a Rust "distribution" as such.

P.S. Thanks for all your work Steve, it's really appreciated.

Re: The Rust Platform

#234

Post by timtadh »

skybrian wrote: post #220
the_mitsuhiko wrote: post #216

Earlier quoted context omitted.

The standard package cannot be changed.

By "adjust to" I meant living with the standard library's decisions without changing them. Compatibility with GNU syntax doesn't seem very important.

Well, I am the primary user of my command line applications as they are for my research. As the primary user they better be,

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  --support= \
         [data-type-options] 
         [algorithm-options]
Being able to tightly control how the sub-commands chain together is important to me. Support for both short (-s) and long (--long) options make it easy to write both one off commands and self documenting commands in scripts and makefiles.

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.

Re: The Rust Platform

#235

Post by catnaroek »

wyager wrote: post #224
catnaroek wrote: post #159

Earlier quoted context omitted.

The injectivity assumption isn't unjustified - type constructors are injective.

> The injectivity assumption isn't unjustified Strongly disagree. (+2) 3 == (+1) 4 implies neither (+2) == (+1) nor 3 == 4. So Fst goes out the window. (even 5) == (even 7) does not imply 5 == 7. >type constructors are injective. But type functions aren't, and that's what we want. I agree that it's misleading to have type functions look like type constructors syntactically.

The type constructor that's being assumed injective in the section “Deriving `absurd` with type families” is `R`.

Re: The Rust Platform

#236

Post by JoshTriplett »

pcwalton wrote: post #215
JoshTriplett wrote: post #128

Earlier quoted context omitted.

> We have one string type defined in std The standard library also includes Path/PathBuf and OsStr/OsString. And third-party libraries also use [u8] for bytestrings. It'd be nice to improve handling for user-supplied text where you can't assume UTF-8. For instance, git2-rs provides the contents of diffs as [u8], because it can't assume the diffed files use UTF-8. That led to this commit today: https://github.com/ogha…

> That felt like a lot of boilerplate to abstract between str and [u8]. Is there a better way to solve that problem? This doesn't have anything to do with large vs. small standard libraries, because all of these string types are defined in libstd.

libstd defines varying amounts of string manipulation and abstraction for those string types, though.

I'd love to see additional support for handling bytestrings in libstd, to make it easier to write code that handles both &str and &[u8].

Re: The Rust Platform

#237

Post by saghm »

hibbelig wrote: post #123
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 have these built-in objects like Math and String and Array. Are those not the standard library?

I'm not sure I'd classify them as a standard library; they're essentially just pervasive global variables. For a comparison, think of Java; the standard library is things like `java.util` and `java.swing`, which goes far beyond having the `System` and `Math` classes available in `java.lang`.

Re: The Rust Platform

#238

Post by fnord123 »

rspeer wrote: post #218
fnord123 wrote: post #197

Earlier quoted context omitted.

Arrow seems particularly useless as it just wraps stdlib datetime and its awful 10 byte size rather than moving to an 8 byte representation like np.datetime64 uses.

Just because you haven't found a use for it doesn't mean it's useless. The stdlib datetime class is terrible and desperately needs to be wrapped. Arrow is a good wrapper. I don't know what you're on about with counting bytes.

I've wrapped datetime for company work (pre pandas, pre datetime64) to make sure it follows the rules of the data analysis platform we developed (adding functions for moving to next month of year based on various financial calendar rules for example). I wish I hadn't done it and had just wrapped a boost_datetime since the performance of datetime is slow when you have a large timeseries of them. The performance is especially unacceptable if you also have timezones attached to your datetimes.

Now we have pandas, yay. But I don't see why one would use arrow. If you're patient enough, could you explain why you would use it? The website doesn't seem to be very convincing.

Re: The Rust Platform

#239

Post by pc2g4d »

Couldn't much of the function of such a "platform" be automated?

One of the main constraints that would guide selection of crates for this platform metapackage is that they must have compatible dependencies. So package A depending on Bv1 and package C depending on Bv2 wouldn't work because they Bv1 and Bv2 would both have to be included, leading to a conflict.

But this information is (in theory) encoded in semantic versioning. Assuming proper semantic versions for crates, a target set of crates to be included could be specified, and then automatically the various sets of crate versions that do not have conflicting dependencies could be calculated.

These compatible crate/version sets could be automatically generated and published as metacrates.

Consider the following crate/version dependencies:

  Av1 -> Bv1
  Cv1 -> Bv1
  Av2 -> Bv2
  Cv2 -> Bv1
  Av3 -> Bv2
  Cv3 -> Bv2
compatible_sets({'A', 'C'}) returns {{'Av1','Cv1'},{'Av1','Cv2'},{'Av2','Cv3'},{'Av3','Cv3'}}

By imposing an ordering on these compatible sets they could be automatically identified. compatible_A_C_0 is {'Av1','Cv1'}, compatible_A_C_1 is {'Av1','Cv2'}, and so on.

Obviously the semver could be wrong and unexpected incompatibilities could crop up. But couldn't these just be autogenerated and then voted on? Then the top best compatible sets will filter to the top and, de facto, the Rust Platform has been autogenerated?

Re: The Rust Platform

#240

Post by steveklabnik »

AsyncAwait wrote: post #233
steveklabnik wrote: post #222

Earlier quoted context omitted.

How is that different than the proposal? The only part that's maybe different is "feel essentially invisible", which is something that might happen, I'll grant you that. But I don't think that people feel invisible when some package is in a standard library, which is roughly equivalent here.

I just don't think that going beyond a simple website with 'blessed' crates has much benefit, but it certainly has a lot of disadvantages as outlined in this whole thread. I'm simply saying that if the goal is to have a central place to point to when somebody asks, 'how do I do X', then perhaps making a website/improving crates.io in this regard is the better approach for the continued growth of the still very much e…

Thank you both for the compliment, and for elaborating. :)
Post reply on HN