Re: [rust-dev] Deprecating rustpkg

2014-02-02 Thread Vladimir Lushnikov
A general observation (not particularly replying to your post, Thomas). For both python and haskell (just to name two languages), distribution (where things end up on the filesystem ready to be used) can be done by both the built-in tools (cabal-install, pip) and the distribution-specific tools.

Re: [rust-dev] Deprecating rustpkg

2014-02-01 Thread Vladimir Lushnikov
There are some great points here (that should probably go into some sort of 'best practices' doc for rust package authors). However there is a fundamental flaw IMO - we are talking about open-source code, where the author is not obligated to do *any* of this. Most open-source licenses explicitly

Re: [rust-dev] Deprecating rustpkg

2014-02-01 Thread Vladimir Lushnikov
Portage has a very similar syntax/way of specifying runtime vs. build-time dependencies: http://devmanual.gentoo.org/general-concepts/dependencies/. Apt doesn't have support for slots and USE flags (code that is included/excluded at compile time for optional features). On Sat, Feb 1, 2014 at

Re: [rust-dev] Deprecating rustpkg

2014-02-01 Thread Vladimir Lushnikov
specification so that others can know to say - I use the json library but with built-in URI support. On Sat, Feb 1, 2014 at 3:45 PM, Lee Braiden leebr...@gmail.com wrote: On 01/02/14 14:49, Vladimir Lushnikov wrote: Portage has a very similar syntax/way of specifying runtime vs. build-time

Re: [rust-dev] Proposal: Change Parametric Polymorphism Declaration Syntax

2014-02-01 Thread Vladimir Lushnikov
Placing type bounds before the name of the thing you are trying to declare feels unnatural to me. And the generic block is far too much boilerplate! How about supporting type aliases as Scala does? So you write: type MyT = Clone + Eq fn fooMyT, U(t: T, u: U) - … and the 'type' is just an

Re: [rust-dev] Deprecating rustpkg

2014-01-31 Thread Vladimir Lushnikov
Looking briefly over the semantic versioning page, doesn't it just mandate a particular version format for when you break API compatibility? This is in theory the same thing I was talking about with slots, just encoded in the version number. It can get ridiculous as well though - see for example

Re: [rust-dev] Deprecating rustpkg

2014-01-31 Thread Vladimir Lushnikov
Is this not exactly what was being discussed? Maven doesn't support this (but pip does for example Baz=2.0, 3.0). Portage certainly supports it as well. On Sat, Feb 1, 2014 at 12:15 AM, Tony Arcieri basc...@gmail.com wrote: On Fri, Jan 31, 2014 at 4:15 PM, Vladimir Lushnikov vladi...@slate

Re: [rust-dev] Why focus on single-consumer message passing?

2014-01-26 Thread Vladimir Lushnikov
Here are a couple of observations/comments from a rust lurker: * +1 for message-passing as a core paradigm for inter-thread communication. It is significantly easier to reason about than shared memory. It is not a silver bullet for all cases of course (but that is why you have unsafe code): **

Re: [rust-dev] Function definition syntax

2013-08-02 Thread Vladimir Lushnikov
+1 for keeping the syntax as is i.e. the - as part of the return signature. It's more readable and it does not mislead people into the fact that there is no partial function application in rust (which IMHO is one of the main reasons to keep the syntax the same between argument and return types).