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

31–40 of 256 posts

Re: The Rust Platform

#31

Post by hinkley »

pcwalton wrote: post #22
Animats wrote: post #17

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.

C++ has innumerable de facto "platforms" and "ecosystems". You have to choose one to get anything done, whether that be various Boost libraries, POSIX, Win32, Cocoa, Qt, GTK(mm), even stuff like XPCOM… Helpfully, many of these platforms reinvent basic things like strings [1] and reference counted smart pointers [2] in incompatible ways. Wouldn't it be better if there were just one platform? [1]: http://doc.qt.io/qt-4…

It is pointless to argue with C++ programmers. Just eat their lunch like everybody else has and go about your day.

Edit: I've been watching C++ developers tell everyone else for nearly 25 years how the world works and why their new language will never be useful. Enough. The cumulative weight of languages that found success by not copying C++ is staggering.

Re: The Rust Platform

#32

Post by steveklabnik »

viraptor wrote: post #30
steveklabnik wrote: post #12

Earlier quoted context omitted.

Cargo will do its best to unify separate versions, but if it can't, then it will just include both. So it sounds like this would be a non-issue here.

https://github.com/rust-lang/cargo/issues/2064 From my perspective: one of the biggest issues in cargo right now. I know it's not the same as the HP problem, but current cargo is definitely not good at solving this.

Yes, this has been a big thing we've been discussing a lot. Something will probably happen, but design work is still being done.

Re: The Rust Platform

#33

Post by Animats »

eridius wrote: post #20
Animats wrote: post #17

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.

I get the feeling that you didn't really read the post. Nothing in the platform is required to use Rust, and you can trivially write Rust packages that don't use the platform. The point of the platform is for convenience. In most cases it will make sense to use it because it provides a convenient set of libraries that are known to work well together, but you could also choose to just ignore the Rust platform entirely…

"In general, rustup is intended to be the primary mechanism for distribution; it’s expected that it will soon replace the guts of our official installers, becoming the primary way to acquire the Rust Platform and all that comes with it."

Then, of course, the other installers will gradually break and be abandoned. The effect is that users must run the "Rust Platform", unless they have the resources to build their own distro.

Is there a monetization scheme behind this? Does someone aspire to be the Canonical of the Rust ecosystem?

Re: The Rust Platform

#34

Post by gpm »

steveklabnik wrote: post #26
dikaiosune wrote: post #23

Earlier quoted context omitted.

Would it still work correctly when invoking rustc on its own or from another tool? I've seen a couple of people on IRC asking about driving rustc from a non-Cargo tool.

rustc already requires passing an --extern flag for each 'extern crate' in the source, so in some sense, yes. You'd be passing that stuff along. You already have to know where those deps are on disk; the difference is that you wouldn't have a list of which deps in the source code. But if you did, it would work.

> rustc already requires passing an --extern flag for each 'extern crate' in the source

Only if it can't find the crate otherwise. Generally it just searches your library path and any directories you specify with -L, e.g. most cargo executables can be recompiled (the first compilation via cargo used to compile the dependencies) via `rustc src/main.rs -L target/debug/deps`

Re: The Rust Platform

#35

Post by Ericson2314 »

burntsushi wrote: post #25
Ericson2314 wrote: post #21

Earlier quoted context omitted.

The one thing stack does do nicely that this proposal doesn't is allow curated comparable versions without forcing course dependencies. In plainer English, stack can pick the versions while you still opt in pack by package. I beleive that this is crucial to not slow down the evolution of the ecosystem. In Cargo jargon, a solutuon would be for metapackages could double as sources: `foo = { metapackage = bar }` to use…

If I'm understanding your concern correctly, that's totally a part of the proposal: But we can do even better. In practice, while code will continue working with an old metapackage version, people are going to want to upgrade. We can smooth that process by allowing metapackage dependencies to be overridden if they appear explicitly in the Cargo.toml file.

Nah that's different. This is about avoiding unused dependencies, especially when they constrain portability.

Re: The Rust Platform

#36

Post by saysjonathan »

pcwalton wrote: post #22
Animats wrote: post #17

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.

C++ has innumerable de facto "platforms" and "ecosystems". You have to choose one to get anything done, whether that be various Boost libraries, POSIX, Win32, Cocoa, Qt, GTK(mm), even stuff like XPCOM… Helpfully, many of these platforms reinvent basic things like strings [1] and reference counted smart pointers [2] in incompatible ways. Wouldn't it be better if there were just one platform? [1]: http://doc.qt.io/qt-4…

Some languages have also seen great success with having a standard platform but still allowing users to replace it as needed. The many Haskell Preludes and Jane Street's ocaml core are two such examples.

I think the ability to opt out of the rust-platform metapackage is a great feature.

Re: The Rust Platform

#37

Post by cocktailpeanuts »

Can someone summarize what's going on here for lay people? I know this "Rust" thing is pretty popular on HN nowadays but not sure what the difference is between a language and a platform. I was trying to read the article, but I don't have enough knowledge about rust itself to understand what it's talking about...

Re: The Rust Platform

#38

Post by dikaiosune »

Animats wrote: post #33
eridius wrote: post #20

Earlier quoted context omitted.

I get the feeling that you didn't really read the post. Nothing in the platform is required to use Rust, and you can trivially write Rust packages that don't use the platform. The point of the platform is for convenience. In most cases it will make sense to use it because it provides a convenient set of libraries that are known to work well together, but you could also choose to just ignore the Rust platform entirely…

"In general, rustup is intended to be the primary mechanism for distribution; it’s expected that it will soon replace the guts of our official installers, becoming the primary way to acquire the Rust Platform and all that comes with it." Then, of course, the other installers will gradually break and be abandoned. The effect is that users must run the "Rust Platform", unless they have the resources to build their own…

I don't see anything in this proposal which indicates that rustup would by default install any of this, and it's already the primary target of development efforts, Rust Platform or not.

What other installers are you referring to, exactly? The old rustup.sh which couldn't support multiple toolchains installed alongside each other? multirust which didn't work on Windows? rustup is a massive improvement over both, IMO.

Re: The Rust Platform

#39

Post by tibbe »

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 friction as types, traits (type classes), etc are hard to coordinate across maintainers and separate package release cycles. We ended up with lots of uncomfortable conversions at API boundaries.

Here's a number of examples of problems we currently have:

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

- Standard library cannot use containers, other than lists, for the same reason.

- No standard traits for containers, like maps and sets, as those are defined outside the standard library. Result is that code is written against one concrete implementation.

- Newtype wrapping to avoid orphan instances. Having traits defined in packages other than the standard library makes it harder to write non-orphan instances.

- It's too difficult to make larger changes as we cannot atomically update all the packages at once. Thus such changes don't happen.

Empirically, languages that have large standard libraries (e.g. Java, Python, Go) seem to do better than their competitors.

Re: The Rust Platform

#40

Post by saysjonathan »

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…

You're clearly very into Stack. If you're interested though, cabal-install 1.24 introduced nix-style local builds.
Post reply on HN