TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

The Rust split: stable vs. nightly

37 点作者 bretthoerner超过 8 年前

12 条评论

echelon超过 8 年前
This is incorrect and seems inflammatory. Please don&#x27;t turn this into Python 2 vs 3 debate, because this is nothing of the sort.<p>Nightly isn&#x27;t stable because we don&#x27;t want features to land prematurely. Rust is a great language precisely because it it well thought out. Don&#x27;t rush things into stable and leave us with legacy cruft for the rest of time. That&#x27;s dangerous and hurts everyone.<p>Anyone developing their library as nightly-only should expect to see little adoption. I only develop against stable and I&#x27;m quite productive with the tooling. Iron and Hyper are excellent web frameworks, and rustc_serialize gets the job done.<p>I can&#x27;t wait to see Steve or another core contributor weigh in on this piece.
评论 #13252036 未加载
评论 #13251955 未加载
评论 #13251926 未加载
ekidd超过 8 年前
I maintain a dozen or two Rust libraries and programs, and close to half of them are real-world production code.<p>Exactly <i>one</i> of them requires nightly Rust, and that&#x27;s because it uses a feature (Macros 1.1) scheduled to show up in stable in just under 6 weeks.<p>There are two reasons not to use nightly:<p>1. Stuff breaks. I remember the bad old days before Rust 1.0 and its iron-clad stability guarantees. I spent my time fixing a endless stream of GitHub issues reports across a half dozen projects. Modern nightly isn&#x27;t so bad, but I&#x27;m still guiltily sitting on a PR about nightly breakage (as usual). But something that works in stable Rust just keeps working.<p>2. Stuff <i>goes away</i>. Nightly only features do get removed, and then you&#x27;re stuck only building with an ancient nightly build.
kibwen超过 8 年前
There&#x27;s so much incorrect information in this post that I almost know where to begin to refute it. An RFC to stabilize extensions was accepted literally last week. The vast majority of code that is only on nightly is because of unstable deriving, which will be stable in less than six weeks. The community is emphatically not embracing nightly, exactly the opposite. A Python scenario is impossible because stable is a strict subset of nightly, and even using unstable features on nightly requires explicit opt-in. And so on.
llamp超过 8 年前
This seems like mostly hyperbole. Rust 1.15, which is a bit over a month or so away, is slated to have macros 1.1 which covers much of the need for compiler plugins. As I understand it macros 1.1 was in part prioritised by the Rust team so that users wouldn&#x27;t have to use nightlies.
ben0x539超过 8 年前
If no one develops serious bleeding edge bullshit against rust nightly, the features that are only in rust nightly aren&#x27;t gonna get any real-world experience that can inform whether they should go into rust stable, so it sounds like the dichotomy is working as designed to me.
hiimnate超过 8 年前
I do agree that there is a problem with the nightly&#x2F;stable split in Rust, but I think a big part of this problem will be solved by macros 1.1: <a href="https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rfcs&#x2F;blob&#x2F;master&#x2F;text&#x2F;1681-macros-1.1.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rfcs&#x2F;blob&#x2F;master&#x2F;text&#x2F;1681-macr...</a>
gpm超过 8 年前
The comments on &#x2F;r&#x2F;rust are worth reading<p><a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;rust&#x2F;comments&#x2F;5k4sep&#x2F;a_tale_of_two_rusts&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;rust&#x2F;comments&#x2F;5k4sep&#x2F;a_tale_of_two_...</a>
crzwdjk超过 8 年前
One real issue with the nightly&#x2F;stable split is that it hasn&#x27;t been entirely clear when things will actually be making it into stable. I understand that software development is full of uncertainties and sometimes you just don&#x27;t know how long an implementation will take until you actually build it. But right now, to someone not involved in developing Rust itself, it&#x27;s hard to get an idea of what the nightly-only features are, where they are in the stabilization process, and when they might be expected to appear in stable. For a concrete example, I only found out that custom derive will be out in 1.15 because I happened to read Hacker News. And there doesn&#x27;t seem to be any index of RFCs or where they are in the process at all, or at least not anywhere that I could easily find. In the core team&#x27;s defense, they&#x27;re eyeballs deep in this stuff all day every day, so they have a pretty good idea about what is where and how far along things are. But us users who only glance at what&#x27;s in each new release and only upgrade every 6 months would really like to know whether to bother to bother installing nightly for the shiny new feature or just wait for the next release that will have it and be actually stable.
评论 #13253450 未加载
kzrdude超过 8 年前
There&#x27;s another distinction that is not made here!<p>I recommend the nightly toolchain for development, but to target the stable Rust platform. This is possible because Rust is that good and unbuggy. Use nightly to get the best development tools, stable for the best platform (that doesn&#x27;t break builds randomly).
computerphage超过 8 年前
&gt; at least one feature that won’t get stabilized ever: &gt; #![feature(plugin)]<p>&gt; This is how they are utilized by Diesel, for example, a popular ORM and SQL query interface; or Serde, a serialization framework.<p>Diesel and Serde are going to be fully available on Rust 1.15, which is &lt; 6 weeks away. This is actually an example of the complete opposite: the Rust project is working hard to get important projects to work on stable Rust so that people <i>don&#x27;t</i> need nightlies.
brson超过 8 年前
Dependence on the nightly channel has been one of the biggest risks in Rust. The problem is not solved yet, but it will be. The Rust stable &#x2F; nightly split is disimilar to the Python 2 &#x2F; 3 transition in important ways. The notion that &#x27;nightly Rust is the only Rust&#x27; is premature, and Rustaceans should be cautious about encouraging that notion.<p>It&#x27;s undeniable that there is a significant amount of Rust software still reliant on unstable features, but I have not seen any numbers that would put it in perspective. Having consistent measurements of nightly vs stable adoption would help a lot, inform any conversation, and efforts to move off nightly.<p>So I think it&#x27;s premature to say that &#x27;nightly Rust is the only Rust&#x27;, The article suggests that people are using nightly as the de-facto recommended toolchain, without evidence (though I&#x27;m sure somebody has recommended nightly be default). I&#x27;d encourage people not to recommend nightly and for Rust library developers to aim for their crates to be compatible with stable. I personally don&#x27;t have the same sense as the author that Rust application or library developers are using nightly more than they have in the past. Rather I know that developers of key nightly-only libraries are actively involved in ecosystem migration off of nightly.<p>One of the biggest difference between the 2 &#x2F; 3 split is that stable is generally compatible with nightly, and is intended to catch up with nightly, whereas Python 2 is not such a strict subset of Python 3 and its development is done. That is, nightly is intended to be a staging ground for stable; Python 3 does not have that same relationship to Python 2.<p>(Edit: I stated this awkwardly. In this comparison nightly=Python 2, stable=Python 3. The point stands that the relationships between the two branches are different between the two languages. Nightly development feeds into Stable, Python 2 doesn&#x27;t feed into Python 3, it is not under active development.)<p>Because of this relationship there&#x27;s still reason to have confidence this dependency on nightly will shrink over time. But not disappear. We would always expect some people to depend on nightly. That is its intended purpose - as a breeding ground for future features.<p>Some of the biggest features keeping people off stable Rust are coming, and their biggest users are actively migrating. In the near future there will be fewer reasons to use nightly, not more. And beyond that the reasons to stick to nightly will evolve as Rust evolves. The next demographic of users who will be stuck on nightly will be embedded developers, and that contingent will increase over time. But even as that group increases, the group that is freed up to use stable Rust will grow also. And slowly the stable ecosystem will coalesce for all classes of users and all types of code.<p>Though I don&#x27;t believe it&#x27;s happening to the extent the author does, I&#x27;d rather not see Rustaceans who care about Rust&#x27;s future to adopt a nighly-first mindset. More things will get more stable, faster, by working together. But regardless of people&#x27;s dispositions to the stable &#x2F; nightly split, more of the ecosystem is going to work on stable over time - that is how the Rust feature pipeline works - and eventually stable Rust will be the only Rust.<p>I still expect it to all work out ok.
bronz超过 8 年前
i often encounter xion in the rust irc and he is always a great help. cheers.
评论 #13251943 未加载