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

21–30 of 256 posts

Re: The Rust Platform

#21

Post by Ericson2314 »

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 foo from bar.

Re: The Rust Platform

#22

Post by pcwalton »

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.8/qstring.html

[2]: http://doc.qt.io/qt-4.8/qshareddatapointer.html

Re: The Rust Platform

#23

Post by dikaiosune »

steveklabnik wrote: post #14
qwertyuiop924 wrote: post #13

Good work! The idea of dropping extern crate is worrying, however. Most of the ways that that would be done would add more irregularity, complexity, and implied environment to the language (Rust Platform is always there, whether or not you want it), all of which are opportunities for bugs to creep into code.

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

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.

Re: The Rust Platform

#24

Post by qwertyuiop924 »

steveklabnik wrote: post #14
qwertyuiop924 wrote: post #13

Good work! The idea of dropping extern crate is worrying, however. Most of the ways that that would be done would add more irregularity, complexity, and implied environment to the language (Rust Platform is always there, whether or not you want it), all of which are opportunities for bugs to creep into code.

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.

Re: The Rust Platform

#25

Post by burntsushi »

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…

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.

Re: The Rust Platform

#26

Post by steveklabnik »

dikaiosune wrote: post #23
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.

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.

Re: The Rust Platform

#27

Post by qwertyuiop924 »

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.

Ah. I was working under the assumption that extern crate acted as that, but file-embedded. If rust already needs --extern, I have no objections.

Re: The Rust Platform

#28

Post by seagreen »

coolsunglasses wrote: post #18
Ericson2314 wrote: post #15

Earlier quoted context omitted.

IMO the root problem is that the Haskell Platform is both a set of curated packages and a bandaid for the fact that so many things Haskell are hard to build/install for no-good reason. On the first front I guess it's alright (but stackage is better) and on the second front it's totally inadequate—maybe even harmful in that it probably made the problem just less painful enough to spur procrastination. I think most of…

>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 can always be easily examined, committed to Git, etc.

+ Easy NixOS integration which means I can also describe the non-haskell dependencies for a project, and enforce that _absolutely_ nothing else on my system gets used. This is amazing.

+ I like that it uses Stackage by default, and that I can pin projects to LTS Stackage releases. This means that many users of my projects will probably already have most dependencies installed -- especially cool for small things like tutorials where users won't have the patience for long build times.

+ It reuses the already existing `.cabal` file format so it's easy to make libraries compatible with cabal-install, the other package manager in the Haskell ecosystem.

Re: The Rust Platform

#29

Post by zanny »

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.

Re: The Rust Platform

#30

Post by viraptor »

steveklabnik wrote: post #12
coolsunglasses wrote: post #11

Earlier quoted context omitted.

I checked that other thread, I agree completely with jeremyjh's summary. The problem with Haskell Platform came down to a set of intersecting issues: - A culture of setting very strict & narrow version bounds. (Based on known-good rather than based on avoiding known-broken) - Tools (Cabal) that enforce dependency version bounds. If there's mutual/transitive incompatibiltiy in version bounds - the build fails, period.…

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.

Post reply on HN