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

171–180 of 256 posts

Re: The Rust Platform

#171

Post by themihai »

dikaiosune wrote: post #45
hueving wrote: post #44

Earlier quoted context omitted.

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

Wouldn't be enough to have list of curated libraries documented somewhere in the official rust documentation? It seems to me that a "platform" support would encourage monolitic designs(i.e packages that work only within a specific "platform")

Re: The Rust Platform

#172

Post by pjmlp »

hsivonen wrote: post #158
pjmlp wrote: post #132

Earlier quoted context omitted.

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.

I can tell it is lots of "fun" when you can only use a Maven mirror, with approved jars.

To get a jar into that mirror, a request needs to be sent to the legal team describing the license and business case use, after approval the IT team will add the said jar to the mirror.

The same applies to version upgrades of already approved jars.

This is a typical scenario I had already in a couple of projects.

Re: The Rust Platform

#173

Post by pjmlp »

lmm wrote: post #164
pjmlp wrote: post #132

Earlier quoted context omitted.

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.

Might be, however those bad policies are quite standard in big corporations.

Re: The Rust Platform

#174

Post by majewsky »

zanny wrote: post #29
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.

Qt / Boost / .net are C++ platforms. The difference is you can choose one or none, and the OP actually explicitly talks about how important it is not to have one absolute blessed platform like Java has.

When I was developing KDE applications, I refered to my programming language as "C++/Qt".

Re: The Rust Platform

#175

Post by majewsky »

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.

> And in the end, in 2016, you generally don't care if you download a few extra 100Mo.

I suggest a trip to anywhere outside the western world.

Re: The Rust Platform

#176

Post by Manishearth »

JoshTriplett wrote: post #128
pcwalton wrote: post #59

Earlier quoted context omitted.

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…

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

> The standard library also includes Path/PathBuf and OsStr/OsString.

Right. And you want people to explicitly convert between them.

Having to convert between string types isn't a problem. String encoding is hard, and you're going to have to pay that cost somehow.

Re: The Rust Platform

#177

Post by Manishearth »

hsivonen wrote: post #158
pjmlp wrote: post #132

Earlier quoted context omitted.

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.

It's not a constraint as much as it is a consideration imo.

Re: The Rust Platform

#178

Post by AsyncAwait »

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-party libs, (and thus by necessity stagnating to a certain degree), nor you're making authors of libraries that are not in the Platform feel essentially invisible.

Re: The Rust Platform

#179

Post by adrianN »

pjmlp wrote: post #172
hsivonen wrote: post #158

Earlier quoted context omitted.

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.

I can tell it is lots of "fun" when you can only use a Maven mirror, with approved jars. To get a jar into that mirror, a request needs to be sent to the legal team describing the license and business case use, after approval the IT team will add the said jar to the mirror. The same applies to version upgrades of already approved jars. This is a typical scenario I had already in a couple of projects.

I agree that this sucks, but not doing it that way is dangerous for the company because developers might not care enough about license compliance when they include some stuff into their project.

Re: The Rust Platform

#180

Post by Manishearth »

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.

This is all optional. You can just ... not add the one line to the cargo.toml and manually specify your favorite http library. Folks using many of these libraries or people new to the language can just specify rust-platform deps. This has the added benefit of bringing in versions that are known to work well together -- because of semver this isn't usually a problem, but people aren't perfect so sometimes things break. An added guarantee against that is nice to have.
Post reply on HN