Comment by 4bpp | Hacker News Reader

Comment by 4bpp | Hacker News Reader

Orthogonally to whether this is a good or bad idea, I really wish the PR and subsequent community management had been handled more carefully for something that was pretty much bound to be a very controversial change (tellingly, /r/rust even had a preemptive thread about it before it materialised: http://www.reddit.com/r/rust/comments/236plz/thoughts_on_rem... ). Although I perhaps am in a bad position to complain after having been caught up in the less savoury parts of the exchange myself, I can't help it but believe that the often outright hostile tone and the swift wagon-circling by the proponents (in response to what they probably felt was an unreasonable onslaught of repetitive criticism) will have left a very bad aftertaste with a lot of readers. Much of this could have been prevented by preparing a clean document explaining the motivation and ramifications of the change to a general audience in advance, and perhaps by having the moderators apply some gentle pressure on the loose guns on either side to pipe it down.

The OP is, in fact, that document. You'll notice this in a pull request to Rust's RFC repo. This change has been prominently brewing in the Rust community for a long time. The fact is that people have strong opinions about Rust and this is a critical time in its development - people are going to complain.

Yeah, I've read the document, and I would hope that most other people who proceeded to debate the topic did as well. I honestly don't think that it does a commensurate job of presenting the case for it (and after reading many of the comments by proponents, I certainly am under the impression that there is a strong case for it; I just still think the case against it is stronger). A lot of the comments also show widespread uncertainty about the silent assumptions; I, for my part, am still at a loss as to why something like Cons(1, ~Cons(2, ~...)) is not an interesting or common use case according to some proponents (not necessarily restricting the question to cons-cell lists - the invoked universal utility of sharing tails, for instance, seems far less universal across the practical use cases of many other data structures).

I can't quite tell from your last sentence if you realise this, but ~ doesn't provide sharing at all: ~T/Box<T> acts like a T in almost all ways, except it is guaranteed to be pointer sized (hence its use in recursive data structures, to allow them to exist without being infinite large). A pointer like Rc is required for sharing.

Do note that the Cons cell construction becomes `Cons(1, box Cons(2, box ...))` which doesn't seem particularly bad.

Thanks for the clarification; I do realise this. The context in which the question arose was that several of the "for" arguments seem to state something to the effect of ~ being rare in code due to only occurring in type definitions.

I believe that was just addressing the fact that the type `Box<T>` is more annoying than the type `~T`, since the `box expr` replacement for the `~expr` expression is relatively nice (admittedly I wasn't following the discussion in great detail).

I could have put some more thought into this response.

As Rust becomes more popular while we try to bring home the last few major changes, we've had this problem a few times, where the broader community is surprised and partially shocked and disappointed at a change that has been brewing for a while.

Certainly, more effort could be put into messaging and explaining how big changes are going to effect users. Figuring out how much, and what sort of, messaging is sufficient is not easy, and somebody is always going to find something objectionable about nearly everything. Additionally, Rust is still in an alpha state, in heavy development. The project is not in production mode yet.

We're always learning from mistakes and evolving the process.

Finally, Rust is in the home stretch. In some sense, we're at a stage where we need to hurry up and just get it done, at the expense of some community fallout along the way. If Rust is good, the ill will from the churn will be forgotten in time; if Rust is bad it will die. With the attention Rust is attracting, community momentum wants Rust to stop changing, but Rust must change a bit more. Rust needs to get to a point where the design can be justified and maintained for years to come, before its own popularity forces it to slow down.

Thanks for the detailed response. I understand that having to deal with this sort of situation instead of working on bringing the project closer to fruition must be very annoying from a core developer's perspective. Sorry for contributing my part to this being dragged out further.

To clarify, what has distraught me the most about this change is not even the change itself (although I do think that, however small or warranted on its own it may be, it may have long-term ramifications that need to be considered much more carefully), but the way the process seemed to diverge from the fairly open and inclusive discussion that seemed to regularly take place in the past. This change may well have been brewing somewhere for a while, but from the point of view of someone who is not in the "inner circle", what was perceivable of it essentially was the thread I linked above some 16 days ago (which was remarkably full of responses by apparent "insiders" that aimed to discourage people from discussing the topic at that point in time) and the thread announcing the RFC, in which even some of the most basic questions needed for a casual observer to understand the tradeoffs were unanswered when the proposal of the RFC was mainlined something like half a day later.

The end result is something that looks similar to what happened with GNOME 3 to someone who was in the opposing camp in both cases, where the "in-group" at some point decided that they had identified a development agenda of utmost importance to what has in fact been part of the central mission of the project all along, and increasingly came to send the message that they held disagreeing members of the "out-group" to be obsessive hecklers and people who should just get out already if they don't like it - although nothing says it has to end up like that, where this took the state of Linux desktop environments is easily observed nowadays.

When considering the overall lifecycle of a project, the number of remaining "difficult decisions" is a far more accurate metric of completion than code or concept. Frustratingly, it is pretty much bound to increase towards the full end of the scale of the latter when the development process is a highly public affair. People wouldn't argue this topic with such ferocity if it wasn't for their appreciation of your work so far and high expectations for this project; please don't let that go to waste by shortcutting the decision process when you have come this far.

Reply on news.ycombinator.com