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

41–50 of 256 posts

Re: The Rust Platform

#41

Post by steveklabnik »

gpm wrote: post #34
steveklabnik wrote: post #26

Earlier quoted context omitted.

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`

Ah thanks; Cargo always passes the flag for each, I guess it's just being extra-explicit.

(And that doesn't change the main point, which is that you could still be explicit about what deps you're including)

Re: The Rust Platform

#42

Post by btown »

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…

And notably, C++11 actually moves in this direction, standardizing things like smart pointers [0][1]. It's a very smart move for Rust. Core or near-core library wars in the early days of adoption of a language leads to duplication of effort, and for those invested in seeing Rust gain a set of libraries to rival other languages, this is a great thing.

[0] https://en.wikipedia.org/wiki/C%2B%2B11#C.2B.2B_standard_lib...

[1] https://en.wikipedia.org/wiki/Smart_pointer#unique_ptr

Re: The Rust Platform

#43

Post by saysjonathan »

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…

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?

Re: The Rust Platform

#44

Post by hueving »

cocktailpeanuts wrote: post #37

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

Rust is the language itself. The platform in this context is the standard libraries you use for things like string manipulation, network connections, etc.

Re: The Rust Platform

#45

Post by dikaiosune »

hueving wrote: post #44
cocktailpeanuts wrote: post #37

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

Rust is the language itself. The platform in this context is the standard libraries you use for things like string manipulation, network connections, etc.

Pedantically, the standard library (strings, basic networking, containers/collections, etc.) is already well defined and quite small. The Rust Platform idea seems more aimed at providing access to curated, stabilized versions of community-developed librares for common higher-level tasks (async I/O, serialization/deserialization, etc.).

Personally, I think that letting users (especially beginners) opt in to a larger set of starting libraries could be very beneficial for adoption.

Re: The Rust Platform

#46

Post by skybrian »

saysjonathan wrote: post #43
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…

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.

Re: The Rust Platform

#47

Post by quodlibetor »

Ericson2314 wrote: post #21
coolsunglasses wrote: post #2

Haskell Platform is the last thing you should take inspiration from. Many of us have been doing our best to kill it off. Maybe the downsides involved wouldn't affect Rust in the same ways. My suggestion, look at how Stack (the tool) and Stackage (the platform) work: https://docs.haskellstack.org/en/stable/README/ https://github.com/commercialhaskell/stack https://www.stackage.org/

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…

To make this more concrete, you're suggesting something like

   [dependencies]
   hyper = { metapackage = { rust-platform = "2.7" } }
I like the general theme of having the platform be just a set of known-compatible versions, but on the other hand this feels like it loses out on many of the ease-of-use advantages of just specifying a platform version and knowing that you have all the crates inside of it.

Re: The Rust Platform

#48

Post by eridius »

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…

Rustup being the mechanism to install the Rust Platform does not mean that installing the Rust Platform is required to use Rustup. Rustup is an existing tool that installs Rust for you, and it's highly likely that you'll be able to use it in the future to install just Rust or to install the whole Rust Platform at your discretion.

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

This seems like a complete non-sequitur. I have no idea what you're trying to suggest here.

Re: The Rust Platform

#49

Post by steveklabnik »

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.

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

Re: The Rust Platform

#50

Post by jsmthrowaway »

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.

The counterpoint being Python simplejson vs json. Most working Python developers I know try simplejson first (when they are not controlling dependencies in the environment) and fall back to stdlib json because simplejson got much faster as it evolved outside of the standard library[0]. Most who don't know this go the other way[1].

There are a number of counterpoints in Python, in fact, which epitomizes the "standard library is where code goes to die" thing. Adding modules to the standard library in Python is, more often than not, overall a bad thing for the module. Python has not historically been awesome with standard library quality, either; see Java-style logging and unittest (I mean naming, not "Java idiomatic," which I think is fine for both).

This comes down to release cycles for the language, mostly. So I think API stability is a bit of a red herring when discussing Python, at least.

I tend to appreciate languages where I can remove the entire standard library and "start over," like C. (Yes, you can.) This can be good for a number of things: porting, embedding, frameworks, and so on.

[0]: http://artem.krylysov.com/blog/2015/09/29/benchmark-python-j...

[1]: https://github.com/search?q=simplejson+ImportError&type=Code...

Post reply on HN