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

161–170 of 256 posts

Re: The Rust Platform

#161

Post by Ericson2314 »

seagreen wrote: post #28
coolsunglasses wrote: post #18

Earlier quoted context omitted.

>so many things Haskell are hard to build/install for no-good reason. Were. Were hard. It's quite fine now with Stack. I know users of all kinds of languages that all miss Stack when they're working on their non-Haskell projects.

Not sure why you're being downvoted. Haskell tooling definitely started turning around with Stack. I've used a fair amount of package managers (including cutting edge stuff like Nixpkgs) and Stack is by far my favorite. EDIT: To elaborate on why I like Stack: + Fully declarative. I don't run commands to edit my Stack environment, instead I modify the relevant stack.yml file. This means that the current environment ca…

Stack fixes some things, but as am additional layer of abstraction leaves lots of problems in place.

Re: The Rust Platform

#162

Post by wyager »

catnaroek wrote: post #155
wyager wrote: post #138

Earlier quoted context omitted.

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

>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 some type that indicates a particular ordering among "a"s. Then, "Set"s are parametrized over both "f" and "a", and one cannot accidentally mix up Sets that use a different Ord instance.

Here's a quick example:

https://gist.github.com/wyager/a021f7e5d9f23643bc90a9866b5c0...

Re: The Rust Platform

#163

Post by sitkack »

steveklabnik wrote: post #79
sitkack wrote: post #76

Earlier quoted context omitted.

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

Rust will already allow you to have multiple versions of transitive dependencies.

This needs to be screamed from the hill tops!

Re: The Rust Platform

#164

Post by lmm »

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.

So maybe there's value in shipping a "standard bundle" that includes popular libraries or some such. But it's not worth distorting the whole language design to accommodate bad policies.

Re: The Rust Platform

#165

Post by catnaroek »

wyager wrote: post #162
catnaroek wrote: post #155

Earlier quoted context omitted.

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

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

Re: The Rust Platform

#166

Post by lmm »

goodplay wrote: post #85
sitkack wrote: post #76

Earlier quoted context omitted.

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

If you can, could you elaborate more on python's stdlib holding it back? I think batteries-included experience is one of the reasons why so many people (including myself) use python. It's also one of the features I sorely miss when using Rust. Luckily, Rust's stdlib is starting to tend towards being more practical with recent additions like system time.

Many libraries in the stdlib have much better alternatives, because libraries with their own release cycle can evolve much quicker. But people get stuck on the "standard" version because it's what's in the stdlib. Worse, people write for compatibility with whatever was in stdlib 2.4 because that's what RHEL6 ships.

Re: The Rust Platform

#167

Post by lmm »

bitmadness wrote: post #97
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…

This is exactly the main problem with Haskell. A stunning language with a lousy standard library. In my opinion, Haskell should offer arrays and maps as built-ins (like Go) and ship with crypto, networking, and serialization in the standard library (I know serialization is already there, but everyone seems to prefer Cereal, so...)

> (I know serialization is already there, but everyone seems to prefer Cereal, so...)

This is precisely why shipping things in the standard library is a bad idea. It ends up full of cruft that no-one uses because there are better alternatives.

Re: The Rust Platform

#168

Post by lmm »

skybrian wrote: post #46
saysjonathan wrote: post #43

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's too early to draw conclusions about Go's standard library. Python's standard library seemed like a good idea at the time too. Come back in 15 years and let's see how good it looks then.

Re: The Rust Platform

#169

Post by themihai »

qwertyuiop924 wrote: post #24
steveklabnik wrote: post #14

Earlier quoted context omitted.

What worries you about dropping extern crate? A lot of people feel like it's duplicating what's in your Cargo.toml anyway.

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.

You have modules, use, extern, cargo.toml, cargo.lock. It looks quite verbose and redundant to me. I expected it to simplify but moving more to config files seems a backwards step. I may be biases but I find the Go import/packing vastly superior in terms of usuability(i.e using a single import statement you make the import explicit and ready to use). I think the trick is to build the tools on top of the source code not on top of config files(i.e ala C/C++).

Re: The Rust Platform

#170

Post by rkangel »

vvanders wrote: post #82
rcthompson wrote: post #73

Earlier quoted context omitted.

> These cannot be stripped out of the platform because they're "blessed" and now everyone will forever have a bad time. I suggest we don't do that for Rust. It sounds like the proposal in the OP avoids this problem by having versioned platforms that are independent of the Rust version. So if something turns out to be a bad idea, it can be stripped out of later platform versions and replaced with something better with…

Yeah, I really liked how DirectX did versioning in that respect. Lets you improve the API while preserving backwards API and signature. If you can give Microsoft something it's that they do backwards compatibility well. I don't see why that couldn't be worked into this idea.

> If you can give Microsoft something it's that they do backwards compatibility well.

Completely agree. Don't underestimate the amount of effort it costs them though.

Post reply on HN