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

151–160 of 256 posts

Re: The Rust Platform

#151

Post by comex »

kibwen wrote: post #72
tibbe wrote: post #39

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…

> Empirically, languages that have large standard > libraries (e.g. Java, Python, Go) seem to do better than > their competitors. You seem to be overlooking the ultimate counterexample: C. :P

> You seem to be overlooking the ultimate counterexample: C. :P

I think one reason (of many) that C++ has replaced C almost completely for new development is the STL. Of course, the STL fundamentally depends on the language feature of templates, which you can only approximate in C, but considering that Java and Objective-C, among other languages, lasted pretty long with no generics and only non-type-safe containers, I think C could have benefitted greatly from basic things like resizable arrays, hash tables, trees, better strings, etc. in the standard library. Now it is probably too late for it to matter (which most people consider a good thing).

Re: The Rust Platform

#152

Post by moomin »

pcwalton wrote: post #59
tibbe wrote: post #39

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 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 really really would advise having a word with Snoyberg about this. The Haskell Platform has been a pretty deadly experience. It's also ridiculously beginner-hostile (sounds like it won't be, is in practice).

Re: The Rust Platform

#153

Post by catnaroek »

sclv wrote: post #136
catnaroek wrote: post #121

Earlier quoted context omitted.

> Type classes allow huge flexibility while maintaining type safety, to a much greater degree than fundeps allow. Um, aren't functional dependencies an add-on to multiparameter type classes? I don't see where the opposition is. > Which they do. Perhaps you have some examples of when type families confused you or made you perform an error? I already gave an example above. I defined two type instances that violate the…

> Parametricity is too good to give up. With the minor exception of reference cells (`IORef`, `STRef`, etc.), if two types are isomorphic, applying the same type constructor to them should yield isomorphic types. You know that's not what parametricity means, right? Like, at all? Here's a challenge. `foo :: forall a. a -> a` Now, by parametricity that should have only one inhabitant (upto iso). Use your claimed break…

> Now, by parametricity that should have only one inhabitant (upto iso).

I can count at least three: `undefined`, `const undefined` and `id`.

> Use your claimed break in parametricity from type families and provide me two distinct inhabitants.

Does this count? Here Oleg constructs an inhabitant of False using just some means to case-analyze types (GADTs or type families): http://okmij.org/ftp/Haskell/impredicativity-bites.html

Re: The Rust Platform

#154

Post by hubert123 »

sametmax wrote: post #148
hubert123 wrote: post #146

I mean really, why is this necessary? The reasons for adding this much bloat are tiny and irrelevant. You get a big download full of packages you dont all need, you dont know if you need and all for what? We all have Google, if I want an HTTP library for Rust I'll google whatever the best one is and make a judgement call myself.

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.

Re: The Rust Platform

#155

Post by catnaroek »

wyager wrote: post #138
catnaroek wrote: post #126

Earlier quoted context omitted.

> We're not doing abstract category theory; we're writing computer programs (well, I am). Have you ever run into a problem with type families in that capacity ? I like being able to reason about my programs. For that to be a smooth process, the language has to be mathematically civilized. > Agreed, but there's a difference between type functions and type constructors. TFs are (a limited form of) type functions. By “t…

> I make a ML-style functor parameterized by a structure containing 15 abstract type members. You can do this in Haskell with DataKinds (you just pass around a type of the correct kind which contains all the parameters). Admittedly, it is quite clunky at the moment. I did this to pass around CPU configuration objects for hardware synthesis a la Clash, as CPU designs are often parametrized over quite a few Nats. > par…

> Whenever one introduces a typeclass constraint to a function, one can only assume that the function exhibits uniform behavior up to the differences introduced by different instances of the typeclass.

Of course.

> Would you say that the fact that "instance Ord Word" and "instance Ord Int" are non-isomorphic is a problem? After all, the types themselves are isomorphic!

It's already bad enough, but at least the existence of non-uniform behavior is evident in a type signature containing type class constraints. OTOH, type families are sneaky, because they don't look any different from normal type constructors or synonyms.

Re: The Rust Platform

#156

Post by themihai »

the_mitsuhiko wrote: post #131
ainar-g wrote: post #125

Earlier quoted context omitted.

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?

Everybody I have ever seen do CLI applications in Go will recommend heavily against it.

The package you mentioned has about 200 imports. Compare that with the standard package. https://godoc.org/?q=Flag

Re: The Rust Platform

#157

Post by wyager »

catnaroek wrote: post #153
sclv wrote: post #136

Earlier quoted context omitted.

> Parametricity is too good to give up. With the minor exception of reference cells (`IORef`, `STRef`, etc.), if two types are isomorphic, applying the same type constructor to them should yield isomorphic types. You know that's not what parametricity means, right? Like, at all? Here's a challenge. `foo :: forall a. a -> a` Now, by parametricity that should have only one inhabitant (upto iso). Use your claimed break…

> Now, by parametricity that should have only one inhabitant (upto iso). I can count at least three: `undefined`, `const undefined` and `id`. > Use your claimed break in parametricity from type families and provide me two distinct inhabitants. Does this count? Here Oleg constructs an inhabitant of False using just some means to case-analyze types (GADTs or type families): http://okmij.org/ftp/Haskell/impredicativity-…

Sounds like the problem there is that the Haskell typechecker assumes injectivity, not that it supports case-analysis.

Re: The Rust Platform

#158

Post by hsivonen »

pjmlp wrote: post #132
sitkack wrote: post #87

Earlier quoted context omitted.

The 'std lib is where libraries go to die' was invented by Python. The libs are shallow, don't break backwards compat and provide a substandard experience. Things that continue to improve provide an out of tree alternative package name. Python codebases that are resilient don't use much of "core", arrow for time, requests for http, simplejson, etc. Using core is an antipattern that will get you stuck on a version of…

I disagree. In the enterprise space it is quite common that we only get to use what it is in the computer and access to anything else is strictly controlled by IT. So if it isn't in the standard library or some internal library mirror, we don't get to use it, as simple as that.

I think it would be terrible for Rust design/evolution/policy be constrained with that kind of enterprise badness that basically bans crates.io, and crates.io is an awesomeaspect of the Rust ecosystem.

Re: The Rust Platform

#159

Post by catnaroek »

wyager wrote: post #157
catnaroek wrote: post #153

Earlier quoted context omitted.

> Now, by parametricity that should have only one inhabitant (upto iso). I can count at least three: `undefined`, `const undefined` and `id`. > Use your claimed break in parametricity from type families and provide me two distinct inhabitants. Does this count? Here Oleg constructs an inhabitant of False using just some means to case-analyze types (GADTs or type families): http://okmij.org/ftp/Haskell/impredicativity-…

Sounds like the problem there is that the Haskell typechecker assumes injectivity, not that it supports case-analysis.

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

Re: The Rust Platform

#160

Post by themihai »

sametmax wrote: post #148
hubert123 wrote: post #146

I mean really, why is this necessary? The reasons for adding this much bloat are tiny and irrelevant. You get a big download full of packages you dont all need, you dont know if you need and all for what? We all have Google, if I want an HTTP library for Rust I'll google whatever the best one is and make a judgement call myself.

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.

So if you don't know what to do the solution is to download all the possible packages?Is there a user story/use case solved this way? The documentation for each package is available online so wouldn't make sense to actually read it before to download a package?
Post reply on HN