17 ms·

The biggest threat to Rust's sustainability

171 points by hutrdvnj 6y ago

127 6y ago
What's wrong with just using Rust 2018?
- kzrdude 6y ago
  Rust 2018 is an edition, not a Rust version.
  - smolder 6y ago
    Yes and because editions are independent of versions, you can write Rust '18 for as long as you want.
    - kzrdude 6y ago
      And then you're not avoiding new features much at all. :)
- fnord123 6y ago
  You gotta read code; not just write it in your preferred version.
  - ivanbakel 6y ago
    I don't see any points in the OP that are relevant to reading code. It all just seems like issues that the author has writing their own code.
a_humean 6y ago
He is complaining about fast 6 week release cycles for rustc, but actually things are petty stable atm. Most releases are just "x is also const now" or "we figured out how to relax type checks to allow this safe program to compile that was previously failing to past muster with the borrow checker". There hasn't been a big feature since async/await, and the noise around that is now in library user space - as was to be expected. There is a rust 2021 edition coming up, but that is also looking to be very modest with very few breaking changes. Like adding `TryFrom` to the standard prelude, and deprecating missing `dyn` keyword for trait objects.
- kzrdude 6y ago
  Const generics (minimal version) is coming in the next release.
- eqvinox 6y ago
  I would agree this post is putting the wagon before the horse — the release cadence doesn't really mean anything, the real question is what frequency do new things break your code at.
  - cesaref 6y ago
    And how quickly do compiler/language bugs get fixed...
- carlmr 6y ago
  This "moving target" complaint comes up again and again. It's the classic elevator issue in reverse. If you want to make an elevator faster, put up mirrors so people look at themselves instead of their watch. Rust appears to change fast, because the changelogs are so detailed, but actually it's stable. Maybe we need to hide the detailed changelog and replace the main one with "minor bugfixes and constness updates".
  - infogulch 6y ago
    No good deed goes unpunished. :(
  - pdimitar 6y ago
    Please, never listen to people who complain about big changelogs! The transparency is hugely appreciated by many. It's just that the approving voices are usually silent while the disapproving ones are always loud. Don't let that mislead you. You are doing great.
- foerbert 6y ago
  >"we figured out how to relax type checks to allow this safe program to compile that was previously failing to past muster with the borrow checker" While perhaps not a large change in practice, this seems like the sort of thing that incurs a large cost when it comes to updating your mental model of how the compiler works, what it can and cannot do, and what options you have when it comes to implementing something.
ChrisSD 6y ago
I don't find this article convincing. 1. Rust has very strong stability guarantees. If you want to you can continue coding like it's Rust 1.0 even on the latest compiler. 2. The rate of releases is independent of the rate features are added. Nightly is a playground for feature additions and whatever else. Many may not ever make it into stable, and many might hang around for many years before they are read to be stabilized. A consistent release schedule of every six weeks, whether there's much new or not, means there's no harm in delaying something for a release or three. This vastly reduces the pressure compared to a 3 year release cycle where missing the window means a very long wait. Rust's releases tend to be very small. Even the big async addition was only the async MVP, not the final product. I think this is probably the source of most complaints because it does introduce some genuine churn for async projects. But as always this is hard to discuss in the abstract. At least not without some idea of what features people think shouldn't have been stabilized or which they think were rushed. Btw, here's a good article that attempted to look in to this more objectively: https://steveklabnik.com/writing/how-often-does-rust-change https://steveklabnik.com/writing/how-often-does-rust-change
- kaushikt 6y ago
  Rate of features added being high could be directly proportional to our code going obsolete sooner than later. Wouldn't it? I also understand that Rust is quite backwards compatible which is good but a planned better version of releases would be easier for everyone to keep track, update codes, etc.
  - ChrisSD 6y ago
    Is the rate of features being added high? Things that wouldn't even be a footnote in a new C++ release announcement can be highlighted in a Rust release announcement which may give the impression of lots being added but it ultimately doesn't amount to much.
  - eecc 6y ago
    What does obsolete mean anyway? As long as the compiler remains backwards compatible nobody forces anyone to rewrite programs that deliver their requirements at the time they were developed. Major compatibility breaks occur on a very long time-frame and most certainly with a version bump prominent enough to draw anyone's attention. Personally, I expect builds to suddenly break on dependencies rather than anything else. It's a non-issue.
jayflux 6y ago
> the 6-week development cycles. It’s one of the causes of an unhealthy problem: features bloat. It’s also the cause, in my opinion, of another problem: the immaturity of the ecosystem. Not sure I have the same experience or agree with that. Sure, Rust has a 6 week release cycle, but most of the time the releases are bug fixes or moving library additions into stable. Take this release for example: the only change is ARM support on Linux and a small update to the test framework. I’d hardly describe that as bloat. https://blog.rust-lang.org/2020/12/31/Rust-1.49.0.html https://blog.rust-lang.org/2020/12/31/Rust-1.49.0.html > As a rust developer, I need to remain up to date with the latest developments in order not to produce code that is obsolete as soon as it’s released Clippy should help with that, it usually flags deprecated code or better/more up to date ways of doing something. I don’t think you need to keep on top of every RFC, just use what you need.
why_Mr_Anderson 6y ago
Not he horrible syntax that would make (former)Perl developers shed the tears of joy with how many symbols are used? Not to mention the weirdly shortened words, if I had to write in Rust, I'm sure I'd soon 'mut'(ilate) myself. If you want to save on typing, go the full way and embrace Perl (or APL ;), don't stop in the middle.
- smolder 6y ago
  Totally subjective, but for me Rusts symbols seem like a good trade-off, where the readability cost paid is worth the gained expressiveness. In comparison, Perl has a terse syntax that harms readability more than it helps in other ways. Again, that's subjective. Apart from that, Perl is not a substitute for Rust or vice versa, regardless of the amount of typing involved.
- tene 6y ago
  > shed the tears of joy with how many symbols are used It... doesn't, though? Rust's syntax is pretty aggressively conventional, from my perspective. Looking at the punctuation symbol tokens, almost all of this is common to many languages: https://doc.rust-lang.org/reference/tokens.html#punctuation https://doc.rust-lang.org/reference/tokens.html#punctuation The symbols that come to mind when I think about my experiences writing Rust are: - <> for generics - ? for early-return errors - Macro invocations require a ! - Match statements use => - ' for lifetimes - #[attrname] for attributes - |x,y| for closures - -> for return types All the other common symbols I use feel too conventional to seem worth mentioning, like {} for lexical scopes, = for assignment, +-/ for math, foo() for function calls, foo.bar() for method calls, (a,b,c) for tuples, [1,2,3,4] for arrays, <>!== for comparison, "quoted" 'strings', / comments */ and //comments, etc. I agree that might_fail()? and 'lifetime are different, but everything else I listed seems lightweight, and very common for languages to use symbols for. <> is common for generics from C++, but alternatives I've seen are [] and (), also symbols. Matches use =>, and C's switch cases use :, also a symbol. Using macro_rules to define macros is pretty symbol-heavy, I guess? Usually when I see complaints like this, they come down to complaints about the lifetime syntax, and not liking the use of ' for anything besides quoted strings. If you disagree, could you explain how I've missed or misunderstood your point? Can you show some examples of normal Rust code that uses way more symbols than normal Perl?
exacube 6y ago
I don't think the release cadenece (6 weeks) is the cause for how fast the language was changing. As a counter examples, Go release roughly every ~26 weeks and mostly has releases with minor updates. Chromium releases every 6 weeks but not every release has major updates; they are mostly bug fixes and minor improvements. Even Android is decoupling its system services into components which can be updated through the Play store at a much faster cadence than their yearly releases. I agree that Rust needs to now focus on polish over new features at this point, but I'm not sure that Rust should've done something differently, especially around its release cadence. I don't think it would've been a good contender for serious companies if they hadn't invested heavily in async, for example.
- paavohtl 6y ago
  Rust has a release every 6 weeks, but there haven't been any new major new features in stable since async await, which was in November 2019. The situation is not too different from Chromium.
Jonnax 6y ago
It's quite funny that this is a bunch of complaints that they can't keep up with rust development and that they should do things differently but ends with a plug for their book about their experience programming in rust. I was under the impression that rust is pretty stable? Like web browsers get updates on a fast cadence and it rarely breaks existing web pages.
- kaushikt 6y ago
  Rust is pretty stable. The point is that the work on Rust is happening so fast it's getting impossible to keep track of releases whilst making sure that your code doesn't go obsolete.
  - deleted 6y ago
    [deleted]
  - auggierose 6y ago
    I think people just have to learn that "not using the newest features of the language" is not a problem. I have no problem with obsolete code, where "obsolete" means just that. I have a problem with broken code. If it ain't broken, no need to fix it.
  - tene 6y ago
    Can you share some examples of Rust code "going obsolete"?
    - steveklabnik 6y ago
      One thing that makes these sorts of conversations tricky is that different people mean different things when they say stuff like "going obsolete." To some people, it means "this code literally doesn't work anymore," and to other people, it means "oh no the error handling library I use isn't in vogue anymore and I feel the need to re-write everything to use the latest library." There is not a lot of the former, but there is some of the latter, and even if it's self-imposed, some people do feel that pressure.
- 6y ago
tayo42 6y ago
Click bait article with minimal substance that pitches a book sale? Feels like spam? I guess the topic gives everyone yet another chance to air their hypothetical greviences with rust
chovybizzass 6y ago
Totally agree, this is what killed rails in 2.x time for me. Anytime I finished a feature half the packages were out of date and incompatible.
- paavohtl 6y ago
  Rust has a very strict backwards compatibility policy, and as a result has had ~0 breaking changes since 1.0, with the notable exception of opt-in Rust 2018 edition. Best practises might get out of date, but generally speaking nothing breaks between releases.
BurpyDave 6y ago
This is what I love about Hacker News. There is an article, and there are reasoned objections to it in the comments, which means I can make a bit more of an informed opinion myself. Thanks all!
withoutboats2 6y ago
As others have written, there's basically no connection between Rust's six week release cycle & the rate of actual change to Rust. If Rust switched to a 12 week release cycle, all that would change is that it would take twice as long for features to reach users on stable once they were decided to be released. Feature development is neither release driven nor release constrained. However, the ground truth is that the design of significant new language features basically stopped in 2018. The work now is shepherding through the language extensions the project already committed to in the first few years after 1.0. For example, const generics, which will have a stable MVP in the next release, was first begun in 2017. Generic associated types, which are still not near stable, in 2016. And my own view, these remaining features are a nearly "feature complete" Rust. Future extensions will be either more niche (a lot of attention in the last few years has been aimed at features to make writing unsafe code less error prone, which wouldn't visibly impact users who write only safe code) or less substantial (such as a syntactic sugar that would improve a lot of users lives, but not deeply change how they write code). And that's actually very good.
- nindalf 6y ago
  Imagine if Rust only did releases every 18 or 36 months like other popular languages, or every six months like OP wants. Features that haven't been fully baked would be pushed in to the current release because people wouldn't want to wait another 6 months to see their work come to fruition. When the next release is only six weeks away, the cost of saying "aight, let's take our time and make sure it's ready before sending it out" is so small. The MVP of Const generics has been delayed by 6 weeks, upsetting exactly 0 people. Regular releases of the compiler are awesome for the same reason continuous deployment of web apps is - each release only packs a small number of features. The chances of something breaking are much smaller than if it was a massive release of hundreds of features, all of which need to be tested in isolation and then with each other. The releases page (https://github.com/rust-lang/rust/blob/master/RELEASES.md https://github.com/rust-lang/rust/blob/master/RELEASES.md) shows how rare it is for a fix release to be made. Even when it is, it's something minor. Making the language easier to learn is a high priority. Many people are working on this actively right now - better documentation, better error messages, better IDE experience and so on. OP has misdiagnosed the root cause and blamed something that actually makes it easier to learn the language.
caconym_ 6y ago
I've actually found Rust to be extremely stable since I started using it 5-ish years ago. I haven't had as much time to keep up with new features recently, but all my old code still builds as easily as it always did and the way I used to write code still works fine. I don't imagine I'm missing anything huge and transformative, and I tend to find new-to-me features on an as-needed basis through docs and web search. It is kind of annoying when big libraries that are generally touted as the way to do X require nightly, but again that's my experience as of years ago. Nightly should be understood as a place where churn happens. For me, stable releases have never been anything but what it says on the tin.
pron 6y ago
I think Rust's biggest threat is that it's repeating the same mistakes C++ did, despite the hindsight. C++ tried to be everything for everyone -- a language elaborate enough to write applications in a style that appears high-level on the page, and yet not give up on the full control required for low-level programming. For a while, it worked. The problems only became apparent some years later, when large applications had to be maintained, and people realised that low-level languages, no matter how high-level-looking, all make a certain sacrifice: low abstraction. Clients of components are sensitive to implementation details of those components, and so the maintenance of applications costs as much as that of low-level code does. OTOH, the complexity of the language made portability hard (low-level code is often written for custom hardware) and also hard to analyse. C continued to dominate the embedded space, the application space went to true high-level languages, and C++ kept an intermediate, though important niche, of games and software platforms for capable-enough hardware, which it firmly holds on to. Rust is now doing the same. Few in the embedded space find it appealing, many of those who use C++ do (as it is certainly a cleaned-up C++, and a nice improvement in comparison), but too often not appealing enough to switch now, and some in the application space who don't know or don't remember the C++ lesson do adopt it now (sometimes out of sheer novelty) but will likely abandon it later for similar reasons C++ was largely abandoned in that space. So it is really competing for a pretty small and conservative niche -- albeit an important one -- and one with a strong incumbent. If it does very well, in 20 years we might find that 60% of the C++ space has switched over to Rust, and that's about it. What Rust needs is focus, but it won't have it because I think some of its designers still believe in what C++ believed. That you can have a language that is both high-level and low-level, with the benefits of both and the downsides of neither.So it's being pulled in multiple directions, all while showing poor performance in the market (C++, at least, wasn't just hyped but actually popular). It's not even going after C++'s market seriously, but after the nonexistent market C++ thought it could occupy; the only market it seems to be actually competing over and doing well in is HN-front-page real-estate, the space formerly occupied by Ruby and Haskell. When I was at University in the late '90s, everyone was talking about Haskell will be the language of the future. With almost constant levels of hype, more than twenty years later, it still is. It turns out that for various reasons, when it comes to programming languages, hype and market performance can be completely out of sync for decades. Rust's designers need to choose between adoration and actual popularity. The latter will require some tough decisions. If it's going after the C++ market, it should make itself extremely appealing, irresistibly so, to C++ programmers.
traceroute66 6y ago
For me the biggest problem with Rust is its so darn complex. I recently had to modernise a few ancient CLI tools and knew it was a case of Rust vs Go. I knew neither language, but try as I might I just could never get going with Rust. The syntax is obscure, the concepts are complex. There is also no real IDE for Rust. Meanwhile Go was much quicker to get working code with, and when combined with the excellent Jetbrains GoLand IDE, my initial spaghetti code was soon transformed into a cleaner and maintainable format. The Go community on Slack is also a great resource.
- tiddles 6y ago
  The official CLion plugin for Rust is phenomenal, and almost feels like a first class IDE nowadays. I appreciate Rust is more complex than other languages and much less easier to pick up and learn on the job though. It definitely takes a lot of practice to get to the point where traits/lifetimes/ownership etc feel like brilliant tools rather than needless complexity.
- deleted 6y ago
  [deleted]
- jhugo 6y ago
  This comment echoes a common sentiment of Rust and Go somehow being in the same category (maybe because of the "systems programming language" buzzphrase) but they're really not. Comparing a language with a fairly significant runtime and garbage collection to a language with basically no runtime and strict (albeit largely automated) compile-time memory management is comparing chalk and cheese. You might as well say "I tried C++ but ended up going with Python because it was quicker to code" -- of course it was!
  - davidkunz 6y ago
    I don't think we should dismiss these comments so eagerly. Take a look at Nim - it's fast, efficient and elegant without the huge syntax overhead of Rust.
    - 6y ago
kaushikt 6y ago
What is Rust's equivalent of https://node.green https://node.green?
- fasterthanlime 6y ago
  https://caniuse.rs/ https://caniuse.rs/ is very good.
tormeh 6y ago
This is just extremely entitled complaining, IMO. The edition system already deals with this.
rcxdude 6y ago
This is a blog post which could really do with examples. What kinds of changes and features are causing them anxiety about their code becoming 'obselete'? My experience is Rust is not changing very fast, maybe one of the release notes are of interest to me, and they are mostly 'oh, that's nice to have', not 'I must immediately rewrite all the code which could use this'.
jrimbault 6y ago
I vastly prefer a product which is automatically released often & regularly versus one which is released when the team "feels" like it's ready.
Luker88 6y ago
While I appreciate the fast moving pace, I have to admit that it is hurting two big things: * long term support * choice, in particular in building shared libraries. While a lot can be argued on the first point, the community seems to be actively against anyone who wants to use or build stuff with shared libraries. Shared libs are extremely useful in resource constrained environments like routers, and the debate on who should update things (distro maintainers vs project maintainers) is still very well out there. But breaking compatibility every compiler release is a huge pain the butt, and will force those who need shared libs for one reason or another to work with older, unmaintained compilers, with many projects being unable to compile there (the only "edition" is 2018, 4 years now which is starting to look like C++ standard levels of time). Because like Potter's projects, who the hell ever needed an LTS release? Can't/don't want to update everything every week? Your problem. Now try to choose a single compiler release for your distro. IMHO, either you have too many big features on each release, and therefore the "editions" should track that, or those are not that big of a deal, so no edition bump is needed and we can focus on binary compatibility, maybe? maybe have sub-editions, like 2018.3? So yeah, I love rust, and this is really the only bad thing I have to say about the project. Honestly, if there was an LTS release, maybe just one for rust "edition", maybe use editions better, I think everyone would be super happy and most problems would be resolved.
- pornel 6y ago
  Rust isn't against shared libraries per se, but it doesn't have a stable ABI. ABI for a language with generics is a very tricky problem, and there's no solution on the horizon yet. As for LTS, there is indeed a stand-off with Linux distros. Rust bets on Chrome's update model, where updates are small and backwards-compatible, so everyone is on the latest, and versions don't matter. Linux distros want Rust to have Internet Explorer update model where there are only updates every X months or years, and developers have to specifically test and work around to support multiple old versions. Note that Editions aren't language versions. They're like "use strict" in JS. They only toggle warnings and small parsing details, but there's only one Rust version. Every Rust edition can use any Rust feature, as long as it parses. For example, everything new added in 2020 is available in the Rust 2015 edition.
sylvain_kerkour 6y ago
Hi author here, Yes this is a piece of opinion, not a scientific measure of anything. This is just a report of the voices of the people I'm converting to Rust because they are never heard. The compound effect of small additions every 6 weeks is complexity. Yes there are editions. But from a newcomer's point of view they only add complexity. Feel free to disagree, but I'm convinced that short release cycle and feature bloat are related. I simply don't want Rust to become the new C++ (which is the feeling of a lot of people).
- vaylian 6y ago
  > This is just a report of the voices of the people I'm converting to Rust because they are never heard. That is something that is missing in the article. I think it is valuable to know about these opinions, so thanks for sharing them.
- chrismorgan 6y ago
  > I'm convinced that short release cycle and feature bloat are related Both here and /r/rust (https://old.reddit.com/r/rust/comments/m7seki/the_biggest_threat_to_rusts_sustainability/ https://old.reddit.com/r/rust/comments/m7seki/the_biggest_th...), this has been pretty thoroughly debunked. If you still hold your position after reading all the comments, I’d be interested in a rebuttal. As I said over in /r/rust, I think this claim of yours is still interesting because it’s a matter of perceptions. I’m certain that this perception is erroneous, but impressions still matter. If you want to succeed, it helps to manage public relations proactively.
  - sylvain_kerkour 6y ago
    Thank you for the heads-up! I missed Reddit's thread as I usually visit social networks only the weekends. I've bookmarked the page and will for sure read all the comments this weekend, they look very interesting (especially yours, that I've flew over)! That being said, I stand by my point: Short release cycles are an illustration of The Compound Effect. > A programming language is a platform. You can't build a thriving ecosystem on top of an unstable platform. We need, as a community, to find a solution to bring calm and focus to Rust, and then we will be able to stabilize and build a great ecosystem of libraries on top of that platform. > Short release cycles are suitable for products, as you can remove features or UI elements, and thus complexity can decrease over time. But for platforms, it means that you can only add things, as removing parts of a platform will break backward compatibility. Thus complexity may only increase over time. I would love to see almost "empty releases" in order not to add non-essential features and thus avoid feature bloat. But then, what is the point of short release cycles if it's not to add features? Wouldn't longer releases cycles make more sense?
fefe23 6y ago
The blog post resonates with me. From the outside (not actually writing Rust code yet) it looks like Rust saw C++ metastasize from an overcomplex big language into an even more overcomplex huge language, and then said HOLD MY BEER! Encouraging people to go async / event based looks like a huge mistake to me. Code becomes much harder to reason about and you get a ton of additional complexity to worry about. A much better way is to provide a layer that looks synchronous on top of asynchronous mechanisms. Like going for declarative programming, or make it look like "one thread per request" and have implicit timeout handling via exception you can catch or so. I think the compartment threading model is one of the main reasons why COM is so successful.
- pornel 6y ago
  This is a common outsider view, but it's based on wrong assumptions. You think Rust 1.0 was released as a complete language, and now they're just adding useless bells and whistles. While in fact Rust 1.0 was a bare-bones MVP, missing basic functionality, with an annoyingly inflexible implementation of the borrow checker. You couldn't print or copy an array larger than 32 elements! People still complain that the standard library can't generate random numbers and you need a 3rd party library to cast an integer to an enum (really!) Since 1.0, Rust has been mostly filling in holes, and removing gotchas. Apart from async, a lot of changes can be summed up as "this obvious code didn't compile before for weird technical reasons, but now it just compiles". Async started in 2015 with mio library, which was a thin wrapper over Linux epoll. People have recognized that it's tedious to use it, and proposed Futures in 2016, which made it easier. Multiple limitations of Future's APIs were became apparent, so in 2017-2019 there was a lot of work to remove known problems and annoyances. That's the async API: 4 years of real-world experience and simplification of async code. As someone who's used it during that time I can assure you that `async fn` today is easier and clearer than everything Rust had before it.
branko_d 6y ago
From the OP: > I’m a fan of the Pareto principle: 80% of consequences come from 20% of the causes. This reminds me of the claim that most users only use 20% of the features of a given application. What is often forgotten though, is that different users will often need different 20%.
de6u99er 6y ago
> Learning materials quickly become obsolet I can relate to that. It would be great if new language features that make it into the stable version would require a contribution to Rust's documentation in a way that is easily discoverable by interested developers. Which brings me to a more general issue. Blogs from eager developers, who want to land a job in Silicon Valley, which don't contain any direct nor indirect information which could help readers quickly determine if an article is outdated or not. How difficult can it be to add a date to an article or the version of the Language/framework in question? It always makes my blood boil when I have to find out by myself that a certain blog article, while it may be written well, isn't relevant any more. In regards of Rust's own documentation some form of diff system eould be great. Last time I looked intonusing Rust was more than a year ago. I would love if I could enter a date or version, and get displayed all changes to the documentation and language between then and now. It would also be helpful when developers have to take over maintenance of code from a former colleague who isn't available any more.
- carols10cents 6y ago
  You might enjoy the Edition Guide! https://doc.rust-lang.org/edition-guide/ https://doc.rust-lang.org/edition-guide/
varispeed 6y ago
Is there a company behind Rust? Do developers who contribute to the project receive at least market rate salary? I can't help but think that this kind of model where a group of volunteers creates something of huge value for big corporations for free and then corporation takes it and use in their multi-billion projects and mostly pay in exposure, is a con to weasel out of paying salaries, royalties, taxes by those big corporations. They promote open source so that they don't have to allocate budgets for R&D, because there is always going to be a group to fall for open source PR and will do the heavy lifting for free. Then once the project matures enough, some execs will feel guilty that they use something they didn't pay for and built another beach house and got another jet and they will announce they'll commit some of their company resources to "help", but in reality this is just another PR piece. A lot of people fall for that because they think if they have a great "open source" project in their resume, then somehow one of the big companies will hire them and maybe this will change their modest lives and they'll finally taste middle class living. But that rarely happens. I think developers should unionise and start demand that those big companies will pay royalties for using "open source" code.
- nicoburns 6y ago
  Its development was originally sponsored by Mozilla. But they recently laid off most the Rust team. However, Facebook, Microsoft and Amazon now all have Rust teams employing core developers.
  - varispeed 6y ago
    I think all contributors should be paid once a big company starts using the project. The current state of play in my view is unethical. Developers do the hard work in hope they will be hired some day in the future and that not always happens and they won't be reimbursed for their time spent prior to being hired. In many cases these projects are also developed by privileged developers who can afford to work without pay because they have wealthy parents and so on. This indirectly creates a disadvantage for people from poor backgrounds as in the open source world you are expected to work for free and people who cannot afford to do that are excluded.
acje 6y ago
I think this was a great article, but the focus on the release cycle was probably not hitting the target as that is not on the primary feedback loop for rust development. That said, it is natural that any successful product goes through the explore, expand, exploit phases (see Kent Beck). And this is perhaps a sign that Rust is approaching the exploit phase, where changes should be slower and focus shifted to reducing overhead. Perhaps a future Rust edition (next after 2018), will have a list of features removed as it's main selling point? Still I agree with (out) boats. Rust should complete it's main concepts first. Then we can tidy our room. Promise?
wealthyyy 6y ago
This guy wants to write an implant in Rust, but he forgets that Rust is like C, and its very easy RE. Oh, I do remember we had cool kidz writing implants in Go, C# What a failure! That's why the NSA and GRU selected Modern C++! He selected the wrong tool for the job. Take a look at Flawedgrace, it is written in modern C ++ and very complex to RE. It uses OOP heavily. Rust is a subset of modern C ++ The Rust people have mastered Alexander Stepanov's vision for C ++ Have a look at Alexander Stepanov's Elements of Programming. This post just a hidden marketing for his "Blackhat" book. C++ didn't make any mistakes. The language didn't but the developers did. It's pity that people portray C++ as dead and horrible lang. The ecosystem of programming languages has become more like the Ponzi Crypto industry, where every night you get shiny cryptocurrency and then charge for consultations and speaking.
chrismorgan 6y ago
There’s also been meaningful discussion of this on /r/rust in the last day, well worth reading: https://old.reddit.com/r/rust/comments/m7seki/the_biggest_threat_to_rusts_sustainability/ https://old.reddit.com/r/rust/comments/m7seki/the_biggest_th... General consensus both here and there is that the article is pretty roundly wrong, but that it’s probably still worth discussing a bit, largely to contemplate where this (mis)perception came from and what can be done to improve it.
bschwindHN 6y ago
This seems to be mostly hand wringing with a pitch for a book at the end. I've been using Rust for six years now and it's been rock solid for the projects I've used it for.
bitwize 6y ago
The last time a widely used language was built for safety (Ada), the first thing they did was to hammer out a spec for the language's semantics, even before implementation began. Today, hackers cavil about "design by committee", and Ada was probably the most widely mocked language to come along since COBOL, but its well-defined, slowly changing semantics (it can take a decade for a new standard to come out, and the new standards don't mess with the stuff that worked in the old standards) has been its salvation, and why entire industries of safety-critical software rely on it today. The Rust Evangelism Strike Force could take a few hints from the actual military about how to design a language to a spec. By all means, iterate with actual code first. But do not expect third party users to use the "whatever rustc does is the spec" releases for actual production work. Use those releases to hammer out the details, draw up a spec, then release the spec (under an open license of course) and let the implementations flourish.
- carols10cents 6y ago
  There is work being done towards a spec as we speak. C didn't have a spec until 10 years after it was created, Rust will get there in time :) It's perfectly fine to want to wait until that point to use Rust.
- dralley 6y ago
  > The Rust Evangelism Strike Force could take a few hints from the actual military about how to design a language to a spec. You can argue that Rust could do better, but using the military as an example of doing it "right" is kinda funny. 1) The military changes specifications all the time, which is a big reason why so many projects go over budget by 300%. Look at the B-1, B-2, F-22, F-35, Space Shuttle, etc. All boondoggles caused by making tons of last minute changes that blow up the entire project. 2) The military is moving away from Ada. The F-35 avionics code was all written in C++. Apparently they decided it was easier to hire existing C++ developers than to teach people Ada.
agentultra 6y ago
> *We don't want Rust to become the new C++ do we? Isn't that what the article is arguing for? C++ has a standard that goes through the ISO process (horrible as it is) to be vetted and finalized and implementors need time to catch up. They're moving faster than they used to but it's still 3 years between new releases of the specification and a little more than that for implementations to catch up and become stable.
- pjmlp 6y ago
  And still many shops are only now slowly adopting C++14, with the most adventurous going for C++17.
pdimitar 6y ago
This is a bit corollary to the article so my apologies for that. What I find most unproductive in Rust is the idioms that don't find their place in the official docs. Steve Klabnik wrote an excellent comment here in HN 4-5 months ago about how to use a thread pool which illustrated my gripes with Rust PERFECTLY: https://news.ycombinator.com/item?id=24992747 https://news.ycombinator.com/item?id=24992747 I understand this is not part of the stdlib. I do. But the officially blessed way without 3rd party crates is indeed quite hard to get right or to even write in one go. Another thing that severely disappointed me is the lack of serious plans for Rust 2021 Edition. I really was looking forward to a terser syntax for a bunch of idioms (sadly in the meantime they flew out of my head and now I can't remember them). The 6-week cycle is IMO not a problem. The changes have been fairly small -- but some of them very impactful, like the constant (pun intended) moving of functions from normal ones to `const` ones.

171 points by hutrdvnj 6y ago

127 6y ago

What's wrong with just using Rust 2018?

kzrdude 6y ago
Rust 2018 is an edition, not a Rust version.
- smolder 6y ago
  Yes and because editions are independent of versions, you can write Rust '18 for as long as you want.
  - kzrdude 6y ago
    And then you're not avoiding new features much at all. :)
fnord123 6y ago
You gotta read code; not just write it in your preferred version.
- ivanbakel 6y ago
  I don't see any points in the OP that are relevant to reading code. It all just seems like issues that the author has writing their own code.

a_humean 6y ago

He is complaining about fast 6 week release cycles for rustc, but actually things are petty stable atm. Most releases are just "x is also const now" or "we figured out how to relax type checks to allow this safe program to compile that was previously failing to past muster with the borrow checker". There hasn't been a big feature since async/await, and the noise around that is now in library user space - as was to be expected. There is a rust 2021 edition coming up, but that is also looking to be very modest with very few breaking changes. Like adding `TryFrom` to the standard prelude, and deprecating missing `dyn` keyword for trait objects.

kzrdude 6y ago
Const generics (minimal version) is coming in the next release.
eqvinox 6y ago
I would agree this post is putting the wagon before the horse — the release cadence doesn't really mean anything, the real question is what frequency do new things break your code at.
- cesaref 6y ago
  And how quickly do compiler/language bugs get fixed...
carlmr 6y ago
This "moving target" complaint comes up again and again. It's the classic elevator issue in reverse. If you want to make an elevator faster, put up mirrors so people look at themselves instead of their watch. Rust appears to change fast, because the changelogs are so detailed, but actually it's stable. Maybe we need to hide the detailed changelog and replace the main one with "minor bugfixes and constness updates".
- infogulch 6y ago
  No good deed goes unpunished. :(
- pdimitar 6y ago
  Please, never listen to people who complain about big changelogs! The transparency is hugely appreciated by many. It's just that the approving voices are usually silent while the disapproving ones are always loud. Don't let that mislead you. You are doing great.
foerbert 6y ago
>"we figured out how to relax type checks to allow this safe program to compile that was previously failing to past muster with the borrow checker" While perhaps not a large change in practice, this seems like the sort of thing that incurs a large cost when it comes to updating your mental model of how the compiler works, what it can and cannot do, and what options you have when it comes to implementing something.

ChrisSD 6y ago

I don't find this article convincing. 1. Rust has very strong stability guarantees. If you want to you can continue coding like it's Rust 1.0 even on the latest compiler. 2. The rate of releases is independent of the rate features are added. Nightly is a playground for feature additions and whatever else. Many may not ever make it into stable, and many might hang around for many years before they are read to be stabilized. A consistent release schedule of every six weeks, whether there's much new or not, means there's no harm in delaying something for a release or three. This vastly reduces the pressure compared to a 3 year release cycle where missing the window means a very long wait. Rust's releases tend to be very small. Even the big async addition was only the async MVP, not the final product. I think this is probably the source of most complaints because it does introduce some genuine churn for async projects. But as always this is hard to discuss in the abstract. At least not without some idea of what features people think shouldn't have been stabilized or which they think were rushed. Btw, here's a good article that attempted to look in to this more objectively: https://steveklabnik.com/writing/how-often-does-rust-change https://steveklabnik.com/writing/how-often-does-rust-change

kaushikt 6y ago
Rate of features added being high could be directly proportional to our code going obsolete sooner than later. Wouldn't it? I also understand that Rust is quite backwards compatible which is good but a planned better version of releases would be easier for everyone to keep track, update codes, etc.
- ChrisSD 6y ago
  Is the rate of features being added high? Things that wouldn't even be a footnote in a new C++ release announcement can be highlighted in a Rust release announcement which may give the impression of lots being added but it ultimately doesn't amount to much.
- eecc 6y ago
  What does obsolete mean anyway? As long as the compiler remains backwards compatible nobody forces anyone to rewrite programs that deliver their requirements at the time they were developed. Major compatibility breaks occur on a very long time-frame and most certainly with a version bump prominent enough to draw anyone's attention. Personally, I expect builds to suddenly break on dependencies rather than anything else. It's a non-issue.

jayflux 6y ago

> the 6-week development cycles. It’s one of the causes of an unhealthy problem: features bloat. It’s also the cause, in my opinion, of another problem: the immaturity of the ecosystem. Not sure I have the same experience or agree with that. Sure, Rust has a 6 week release cycle, but most of the time the releases are bug fixes or moving library additions into stable. Take this release for example: the only change is ARM support on Linux and a small update to the test framework. I’d hardly describe that as bloat. https://blog.rust-lang.org/2020/12/31/Rust-1.49.0.html https://blog.rust-lang.org/2020/12/31/Rust-1.49.0.html > As a rust developer, I need to remain up to date with the latest developments in order not to produce code that is obsolete as soon as it’s released Clippy should help with that, it usually flags deprecated code or better/more up to date ways of doing something. I don’t think you need to keep on top of every RFC, just use what you need.

why_Mr_Anderson 6y ago

Not he horrible syntax that would make (former)Perl developers shed the tears of joy with how many symbols are used? Not to mention the weirdly shortened words, if I had to write in Rust, I'm sure I'd soon 'mut'(ilate) myself. If you want to save on typing, go the full way and embrace Perl (or APL ;), don't stop in the middle.

smolder 6y ago
Totally subjective, but for me Rusts symbols seem like a good trade-off, where the readability cost paid is worth the gained expressiveness. In comparison, Perl has a terse syntax that harms readability more than it helps in other ways. Again, that's subjective. Apart from that, Perl is not a substitute for Rust or vice versa, regardless of the amount of typing involved.
tene 6y ago
> shed the tears of joy with how many symbols are used It... doesn't, though? Rust's syntax is pretty aggressively conventional, from my perspective. Looking at the punctuation symbol tokens, almost all of this is common to many languages: https://doc.rust-lang.org/reference/tokens.html#punctuation https://doc.rust-lang.org/reference/tokens.html#punctuation The symbols that come to mind when I think about my experiences writing Rust are: - <> for generics - ? for early-return errors - Macro invocations require a ! - Match statements use => - ' for lifetimes - #[attrname] for attributes - |x,y| for closures - -> for return types All the other common symbols I use feel too conventional to seem worth mentioning, like {} for lexical scopes, = for assignment, +-/ for math, foo() for function calls, foo.bar() for method calls, (a,b,c) for tuples, [1,2,3,4] for arrays, <>!== for comparison, "quoted" 'strings', / comments */ and //comments, etc. I agree that might_fail()? and 'lifetime are different, but everything else I listed seems lightweight, and very common for languages to use symbols for. <> is common for generics from C++, but alternatives I've seen are [] and (), also symbols. Matches use =>, and C's switch cases use :, also a symbol. Using macro_rules to define macros is pretty symbol-heavy, I guess? Usually when I see complaints like this, they come down to complaints about the lifetime syntax, and not liking the use of ' for anything besides quoted strings. If you disagree, could you explain how I've missed or misunderstood your point? Can you show some examples of normal Rust code that uses way more symbols than normal Perl?

exacube 6y ago

I don't think the release cadenece (6 weeks) is the cause for how fast the language was changing. As a counter examples, Go release roughly every ~26 weeks and mostly has releases with minor updates. Chromium releases every 6 weeks but not every release has major updates; they are mostly bug fixes and minor improvements. Even Android is decoupling its system services into components which can be updated through the Play store at a much faster cadence than their yearly releases. I agree that Rust needs to now focus on polish over new features at this point, but I'm not sure that Rust should've done something differently, especially around its release cadence. I don't think it would've been a good contender for serious companies if they hadn't invested heavily in async, for example.

paavohtl 6y ago
Rust has a release every 6 weeks, but there haven't been any new major new features in stable since async await, which was in November 2019. The situation is not too different from Chromium.

Jonnax 6y ago

It's quite funny that this is a bunch of complaints that they can't keep up with rust development and that they should do things differently but ends with a plug for their book about their experience programming in rust. I was under the impression that rust is pretty stable? Like web browsers get updates on a fast cadence and it rarely breaks existing web pages.

kaushikt 6y ago
Rust is pretty stable. The point is that the work on Rust is happening so fast it's getting impossible to keep track of releases whilst making sure that your code doesn't go obsolete.
- deleted 6y ago
  [deleted]
- auggierose 6y ago
  I think people just have to learn that "not using the newest features of the language" is not a problem. I have no problem with obsolete code, where "obsolete" means just that. I have a problem with broken code. If it ain't broken, no need to fix it.
- tene 6y ago
  Can you share some examples of Rust code "going obsolete"?
  - steveklabnik 6y ago
    One thing that makes these sorts of conversations tricky is that different people mean different things when they say stuff like "going obsolete." To some people, it means "this code literally doesn't work anymore," and to other people, it means "oh no the error handling library I use isn't in vogue anymore and I feel the need to re-write everything to use the latest library." There is not a lot of the former, but there is some of the latter, and even if it's self-imposed, some people do feel that pressure.
6y ago

tayo42 6y ago

Click bait article with minimal substance that pitches a book sale? Feels like spam? I guess the topic gives everyone yet another chance to air their hypothetical greviences with rust

chovybizzass 6y ago

Totally agree, this is what killed rails in 2.x time for me. Anytime I finished a feature half the packages were out of date and incompatible.

paavohtl 6y ago
Rust has a very strict backwards compatibility policy, and as a result has had ~0 breaking changes since 1.0, with the notable exception of opt-in Rust 2018 edition. Best practises might get out of date, but generally speaking nothing breaks between releases.

BurpyDave 6y ago

This is what I love about Hacker News. There is an article, and there are reasoned objections to it in the comments, which means I can make a bit more of an informed opinion myself. Thanks all!

withoutboats2 6y ago

As others have written, there's basically no connection between Rust's six week release cycle & the rate of actual change to Rust. If Rust switched to a 12 week release cycle, all that would change is that it would take twice as long for features to reach users on stable once they were decided to be released. Feature development is neither release driven nor release constrained. However, the ground truth is that the design of significant new language features basically stopped in 2018. The work now is shepherding through the language extensions the project already committed to in the first few years after 1.0. For example, const generics, which will have a stable MVP in the next release, was first begun in 2017. Generic associated types, which are still not near stable, in 2016. And my own view, these remaining features are a nearly "feature complete" Rust. Future extensions will be either more niche (a lot of attention in the last few years has been aimed at features to make writing unsafe code less error prone, which wouldn't visibly impact users who write only safe code) or less substantial (such as a syntactic sugar that would improve a lot of users lives, but not deeply change how they write code). And that's actually very good.

nindalf 6y ago
Imagine if Rust only did releases every 18 or 36 months like other popular languages, or every six months like OP wants. Features that haven't been fully baked would be pushed in to the current release because people wouldn't want to wait another 6 months to see their work come to fruition. When the next release is only six weeks away, the cost of saying "aight, let's take our time and make sure it's ready before sending it out" is so small. The MVP of Const generics has been delayed by 6 weeks, upsetting exactly 0 people. Regular releases of the compiler are awesome for the same reason continuous deployment of web apps is - each release only packs a small number of features. The chances of something breaking are much smaller than if it was a massive release of hundreds of features, all of which need to be tested in isolation and then with each other. The releases page (https://github.com/rust-lang/rust/blob/master/RELEASES.md https://github.com/rust-lang/rust/blob/master/RELEASES.md) shows how rare it is for a fix release to be made. Even when it is, it's something minor. Making the language easier to learn is a high priority. Many people are working on this actively right now - better documentation, better error messages, better IDE experience and so on. OP has misdiagnosed the root cause and blamed something that actually makes it easier to learn the language.

caconym_ 6y ago

I've actually found Rust to be extremely stable since I started using it 5-ish years ago. I haven't had as much time to keep up with new features recently, but all my old code still builds as easily as it always did and the way I used to write code still works fine. I don't imagine I'm missing anything huge and transformative, and I tend to find new-to-me features on an as-needed basis through docs and web search. It is kind of annoying when big libraries that are generally touted as the way to do X require nightly, but again that's my experience as of years ago. Nightly should be understood as a place where churn happens. For me, stable releases have never been anything but what it says on the tin.

pron 6y ago

I think Rust's biggest threat is that it's repeating the same mistakes C++ did, despite the hindsight. C++ tried to be everything for everyone -- a language elaborate enough to write applications in a style that appears high-level on the page, and yet not give up on the full control required for low-level programming. For a while, it worked. The problems only became apparent some years later, when large applications had to be maintained, and people realised that low-level languages, no matter how high-level-looking, all make a certain sacrifice: low abstraction. Clients of components are sensitive to implementation details of those components, and so the maintenance of applications costs as much as that of low-level code does. OTOH, the complexity of the language made portability hard (low-level code is often written for custom hardware) and also hard to analyse. C continued to dominate the embedded space, the application space went to true high-level languages, and C++ kept an intermediate, though important niche, of games and software platforms for capable-enough hardware, which it firmly holds on to. Rust is now doing the same. Few in the embedded space find it appealing, many of those who use C++ do (as it is certainly a cleaned-up C++, and a nice improvement in comparison), but too often not appealing enough to switch now, and some in the application space who don't know or don't remember the C++ lesson do adopt it now (sometimes out of sheer novelty) but will likely abandon it later for similar reasons C++ was largely abandoned in that space. So it is really competing for a pretty small and conservative niche -- albeit an important one -- and one with a strong incumbent. If it does very well, in 20 years we might find that 60% of the C++ space has switched over to Rust, and that's about it. What Rust needs is focus, but it won't have it because I think some of its designers still believe in what C++ believed. That you can have a language that is both high-level and low-level, with the benefits of both and the downsides of neither.So it's being pulled in multiple directions, all while showing poor performance in the market (C++, at least, wasn't just hyped but actually popular). It's not even going after C++'s market seriously, but after the nonexistent market C++ thought it could occupy; the only market it seems to be actually competing over and doing well in is HN-front-page real-estate, the space formerly occupied by Ruby and Haskell. When I was at University in the late '90s, everyone was talking about Haskell will be the language of the future. With almost constant levels of hype, more than twenty years later, it still is. It turns out that for various reasons, when it comes to programming languages, hype and market performance can be completely out of sync for decades. Rust's designers need to choose between adoration and actual popularity. The latter will require some tough decisions. If it's going after the C++ market, it should make itself extremely appealing, irresistibly so, to C++ programmers.

traceroute66 6y ago

For me the biggest problem with Rust is its so darn complex. I recently had to modernise a few ancient CLI tools and knew it was a case of Rust vs Go. I knew neither language, but try as I might I just could never get going with Rust. The syntax is obscure, the concepts are complex. There is also no real IDE for Rust. Meanwhile Go was much quicker to get working code with, and when combined with the excellent Jetbrains GoLand IDE, my initial spaghetti code was soon transformed into a cleaner and maintainable format. The Go community on Slack is also a great resource.

tiddles 6y ago
The official CLion plugin for Rust is phenomenal, and almost feels like a first class IDE nowadays. I appreciate Rust is more complex than other languages and much less easier to pick up and learn on the job though. It definitely takes a lot of practice to get to the point where traits/lifetimes/ownership etc feel like brilliant tools rather than needless complexity.
deleted 6y ago
[deleted]
jhugo 6y ago
This comment echoes a common sentiment of Rust and Go somehow being in the same category (maybe because of the "systems programming language" buzzphrase) but they're really not. Comparing a language with a fairly significant runtime and garbage collection to a language with basically no runtime and strict (albeit largely automated) compile-time memory management is comparing chalk and cheese. You might as well say "I tried C++ but ended up going with Python because it was quicker to code" -- of course it was!
- davidkunz 6y ago
  I don't think we should dismiss these comments so eagerly. Take a look at Nim - it's fast, efficient and elegant without the huge syntax overhead of Rust.
  - 6y ago

kaushikt 6y ago

What is Rust's equivalent of https://node.green https://node.green?

fasterthanlime 6y ago
https://caniuse.rs/ https://caniuse.rs/ is very good.

tormeh 6y ago

This is just extremely entitled complaining, IMO. The edition system already deals with this.

rcxdude 6y ago

This is a blog post which could really do with examples. What kinds of changes and features are causing them anxiety about their code becoming 'obselete'? My experience is Rust is not changing very fast, maybe one of the release notes are of interest to me, and they are mostly 'oh, that's nice to have', not 'I must immediately rewrite all the code which could use this'.

jrimbault 6y ago

I vastly prefer a product which is automatically released often & regularly versus one which is released when the team "feels" like it's ready.

Luker88 6y ago

While I appreciate the fast moving pace, I have to admit that it is hurting two big things: * long term support * choice, in particular in building shared libraries. While a lot can be argued on the first point, the community seems to be actively against anyone who wants to use or build stuff with shared libraries. Shared libs are extremely useful in resource constrained environments like routers, and the debate on who should update things (distro maintainers vs project maintainers) is still very well out there. But breaking compatibility every compiler release is a huge pain the butt, and will force those who need shared libs for one reason or another to work with older, unmaintained compilers, with many projects being unable to compile there (the only "edition" is 2018, 4 years now which is starting to look like C++ standard levels of time). Because like Potter's projects, who the hell ever needed an LTS release? Can't/don't want to update everything every week? Your problem. Now try to choose a single compiler release for your distro. IMHO, either you have too many big features on each release, and therefore the "editions" should track that, or those are not that big of a deal, so no edition bump is needed and we can focus on binary compatibility, maybe? maybe have sub-editions, like 2018.3? So yeah, I love rust, and this is really the only bad thing I have to say about the project. Honestly, if there was an LTS release, maybe just one for rust "edition", maybe use editions better, I think everyone would be super happy and most problems would be resolved.

pornel 6y ago
Rust isn't against shared libraries per se, but it doesn't have a stable ABI. ABI for a language with generics is a very tricky problem, and there's no solution on the horizon yet. As for LTS, there is indeed a stand-off with Linux distros. Rust bets on Chrome's update model, where updates are small and backwards-compatible, so everyone is on the latest, and versions don't matter. Linux distros want Rust to have Internet Explorer update model where there are only updates every X months or years, and developers have to specifically test and work around to support multiple old versions. Note that Editions aren't language versions. They're like "use strict" in JS. They only toggle warnings and small parsing details, but there's only one Rust version. Every Rust edition can use any Rust feature, as long as it parses. For example, everything new added in 2020 is available in the Rust 2015 edition.

sylvain_kerkour 6y ago

Hi author here, Yes this is a piece of opinion, not a scientific measure of anything. This is just a report of the voices of the people I'm converting to Rust because they are never heard. The compound effect of small additions every 6 weeks is complexity. Yes there are editions. But from a newcomer's point of view they only add complexity. Feel free to disagree, but I'm convinced that short release cycle and feature bloat are related. I simply don't want Rust to become the new C++ (which is the feeling of a lot of people).

vaylian 6y ago
> This is just a report of the voices of the people I'm converting to Rust because they are never heard. That is something that is missing in the article. I think it is valuable to know about these opinions, so thanks for sharing them.
chrismorgan 6y ago
> I'm convinced that short release cycle and feature bloat are related Both here and /r/rust (https://old.reddit.com/r/rust/comments/m7seki/the_biggest_threat_to_rusts_sustainability/ https://old.reddit.com/r/rust/comments/m7seki/the_biggest_th...), this has been pretty thoroughly debunked. If you still hold your position after reading all the comments, I’d be interested in a rebuttal. As I said over in /r/rust, I think this claim of yours is still interesting because it’s a matter of perceptions. I’m certain that this perception is erroneous, but impressions still matter. If you want to succeed, it helps to manage public relations proactively.
- sylvain_kerkour 6y ago
  Thank you for the heads-up! I missed Reddit's thread as I usually visit social networks only the weekends. I've bookmarked the page and will for sure read all the comments this weekend, they look very interesting (especially yours, that I've flew over)! That being said, I stand by my point: Short release cycles are an illustration of The Compound Effect. > A programming language is a platform. You can't build a thriving ecosystem on top of an unstable platform. We need, as a community, to find a solution to bring calm and focus to Rust, and then we will be able to stabilize and build a great ecosystem of libraries on top of that platform. > Short release cycles are suitable for products, as you can remove features or UI elements, and thus complexity can decrease over time. But for platforms, it means that you can only add things, as removing parts of a platform will break backward compatibility. Thus complexity may only increase over time. I would love to see almost "empty releases" in order not to add non-essential features and thus avoid feature bloat. But then, what is the point of short release cycles if it's not to add features? Wouldn't longer releases cycles make more sense?

fefe23 6y ago

The blog post resonates with me. From the outside (not actually writing Rust code yet) it looks like Rust saw C++ metastasize from an overcomplex big language into an even more overcomplex huge language, and then said HOLD MY BEER! Encouraging people to go async / event based looks like a huge mistake to me. Code becomes much harder to reason about and you get a ton of additional complexity to worry about. A much better way is to provide a layer that looks synchronous on top of asynchronous mechanisms. Like going for declarative programming, or make it look like "one thread per request" and have implicit timeout handling via exception you can catch or so. I think the compartment threading model is one of the main reasons why COM is so successful.

pornel 6y ago
This is a common outsider view, but it's based on wrong assumptions. You think Rust 1.0 was released as a complete language, and now they're just adding useless bells and whistles. While in fact Rust 1.0 was a bare-bones MVP, missing basic functionality, with an annoyingly inflexible implementation of the borrow checker. You couldn't print or copy an array larger than 32 elements! People still complain that the standard library can't generate random numbers and you need a 3rd party library to cast an integer to an enum (really!) Since 1.0, Rust has been mostly filling in holes, and removing gotchas. Apart from async, a lot of changes can be summed up as "this obvious code didn't compile before for weird technical reasons, but now it just compiles". Async started in 2015 with mio library, which was a thin wrapper over Linux epoll. People have recognized that it's tedious to use it, and proposed Futures in 2016, which made it easier. Multiple limitations of Future's APIs were became apparent, so in 2017-2019 there was a lot of work to remove known problems and annoyances. That's the async API: 4 years of real-world experience and simplification of async code. As someone who's used it during that time I can assure you that `async fn` today is easier and clearer than everything Rust had before it.

branko_d 6y ago

From the OP: > I’m a fan of the Pareto principle: 80% of consequences come from 20% of the causes. This reminds me of the claim that most users only use 20% of the features of a given application. What is often forgotten though, is that different users will often need different 20%.

de6u99er 6y ago

> Learning materials quickly become obsolet I can relate to that. It would be great if new language features that make it into the stable version would require a contribution to Rust's documentation in a way that is easily discoverable by interested developers. Which brings me to a more general issue. Blogs from eager developers, who want to land a job in Silicon Valley, which don't contain any direct nor indirect information which could help readers quickly determine if an article is outdated or not. How difficult can it be to add a date to an article or the version of the Language/framework in question? It always makes my blood boil when I have to find out by myself that a certain blog article, while it may be written well, isn't relevant any more. In regards of Rust's own documentation some form of diff system eould be great. Last time I looked intonusing Rust was more than a year ago. I would love if I could enter a date or version, and get displayed all changes to the documentation and language between then and now. It would also be helpful when developers have to take over maintenance of code from a former colleague who isn't available any more.

carols10cents 6y ago
You might enjoy the Edition Guide! https://doc.rust-lang.org/edition-guide/ https://doc.rust-lang.org/edition-guide/

varispeed 6y ago

Is there a company behind Rust? Do developers who contribute to the project receive at least market rate salary? I can't help but think that this kind of model where a group of volunteers creates something of huge value for big corporations for free and then corporation takes it and use in their multi-billion projects and mostly pay in exposure, is a con to weasel out of paying salaries, royalties, taxes by those big corporations. They promote open source so that they don't have to allocate budgets for R&D, because there is always going to be a group to fall for open source PR and will do the heavy lifting for free. Then once the project matures enough, some execs will feel guilty that they use something they didn't pay for and built another beach house and got another jet and they will announce they'll commit some of their company resources to "help", but in reality this is just another PR piece. A lot of people fall for that because they think if they have a great "open source" project in their resume, then somehow one of the big companies will hire them and maybe this will change their modest lives and they'll finally taste middle class living. But that rarely happens. I think developers should unionise and start demand that those big companies will pay royalties for using "open source" code.

nicoburns 6y ago
Its development was originally sponsored by Mozilla. But they recently laid off most the Rust team. However, Facebook, Microsoft and Amazon now all have Rust teams employing core developers.
- varispeed 6y ago
  I think all contributors should be paid once a big company starts using the project. The current state of play in my view is unethical. Developers do the hard work in hope they will be hired some day in the future and that not always happens and they won't be reimbursed for their time spent prior to being hired. In many cases these projects are also developed by privileged developers who can afford to work without pay because they have wealthy parents and so on. This indirectly creates a disadvantage for people from poor backgrounds as in the open source world you are expected to work for free and people who cannot afford to do that are excluded.

acje 6y ago

I think this was a great article, but the focus on the release cycle was probably not hitting the target as that is not on the primary feedback loop for rust development. That said, it is natural that any successful product goes through the explore, expand, exploit phases (see Kent Beck). And this is perhaps a sign that Rust is approaching the exploit phase, where changes should be slower and focus shifted to reducing overhead. Perhaps a future Rust edition (next after 2018), will have a list of features removed as it's main selling point? Still I agree with (out) boats. Rust should complete it's main concepts first. Then we can tidy our room. Promise?

wealthyyy 6y ago

This guy wants to write an implant in Rust, but he forgets that Rust is like C, and its very easy RE. Oh, I do remember we had cool kidz writing implants in Go, C# What a failure! That's why the NSA and GRU selected Modern C++! He selected the wrong tool for the job. Take a look at Flawedgrace, it is written in modern C ++ and very complex to RE. It uses OOP heavily. Rust is a subset of modern C ++ The Rust people have mastered Alexander Stepanov's vision for C ++ Have a look at Alexander Stepanov's Elements of Programming. This post just a hidden marketing for his "Blackhat" book. C++ didn't make any mistakes. The language didn't but the developers did. It's pity that people portray C++ as dead and horrible lang. The ecosystem of programming languages has become more like the Ponzi Crypto industry, where every night you get shiny cryptocurrency and then charge for consultations and speaking.

chrismorgan 6y ago

There’s also been meaningful discussion of this on /r/rust in the last day, well worth reading: https://old.reddit.com/r/rust/comments/m7seki/the_biggest_threat_to_rusts_sustainability/ https://old.reddit.com/r/rust/comments/m7seki/the_biggest_th... General consensus both here and there is that the article is pretty roundly wrong, but that it’s probably still worth discussing a bit, largely to contemplate where this (mis)perception came from and what can be done to improve it.

bschwindHN 6y ago

This seems to be mostly hand wringing with a pitch for a book at the end. I've been using Rust for six years now and it's been rock solid for the projects I've used it for.

bitwize 6y ago

The last time a widely used language was built for safety (Ada), the first thing they did was to hammer out a spec for the language's semantics, even before implementation began. Today, hackers cavil about "design by committee", and Ada was probably the most widely mocked language to come along since COBOL, but its well-defined, slowly changing semantics (it can take a decade for a new standard to come out, and the new standards don't mess with the stuff that worked in the old standards) has been its salvation, and why entire industries of safety-critical software rely on it today. The Rust Evangelism Strike Force could take a few hints from the actual military about how to design a language to a spec. By all means, iterate with actual code first. But do not expect third party users to use the "whatever rustc does is the spec" releases for actual production work. Use those releases to hammer out the details, draw up a spec, then release the spec (under an open license of course) and let the implementations flourish.

carols10cents 6y ago
There is work being done towards a spec as we speak. C didn't have a spec until 10 years after it was created, Rust will get there in time :) It's perfectly fine to want to wait until that point to use Rust.
dralley 6y ago
> The Rust Evangelism Strike Force could take a few hints from the actual military about how to design a language to a spec. You can argue that Rust could do better, but using the military as an example of doing it "right" is kinda funny. 1) The military changes specifications all the time, which is a big reason why so many projects go over budget by 300%. Look at the B-1, B-2, F-22, F-35, Space Shuttle, etc. All boondoggles caused by making tons of last minute changes that blow up the entire project. 2) The military is moving away from Ada. The F-35 avionics code was all written in C++. Apparently they decided it was easier to hire existing C++ developers than to teach people Ada.

agentultra 6y ago

> *We don't want Rust to become the new C++ do we? Isn't that what the article is arguing for? C++ has a standard that goes through the ISO process (horrible as it is) to be vetted and finalized and implementors need time to catch up. They're moving faster than they used to but it's still 3 years between new releases of the specification and a little more than that for implementations to catch up and become stable.

pjmlp 6y ago
And still many shops are only now slowly adopting C++14, with the most adventurous going for C++17.

pdimitar 6y ago

This is a bit corollary to the article so my apologies for that. What I find most unproductive in Rust is the idioms that don't find their place in the official docs. Steve Klabnik wrote an excellent comment here in HN 4-5 months ago about how to use a thread pool which illustrated my gripes with Rust PERFECTLY: https://news.ycombinator.com/item?id=24992747 https://news.ycombinator.com/item?id=24992747 I understand this is not part of the stdlib. I do. But the officially blessed way without 3rd party crates is indeed quite hard to get right or to even write in one go. Another thing that severely disappointed me is the lack of serious plans for Rust 2021 Edition. I really was looking forward to a terser syntax for a bunch of idioms (sadly in the meantime they flew out of my head and now I can't remember them). The 6-week cycle is IMO not a problem. The changes have been fairly small -- but some of them very impactful, like the constant (pun intended) moving of functions from normal ones to `const` ones.