TBH it's getting a bit much at this point. The rust advocates here (not sure if they're paid or just fanboys) really need to tone it down. The hyperbole, and the constant "rust solves this unrelated problem, and has no flaws!" is beginning to grate.
I've coded in it a bit and it seems like cool language, they get a lot right and have some new and interesting ideas. But it's not a panacea (or indeed "salvation" as one recent blog post put it) for everything wrong in software. We don't need to all immediately re-write everything we do rust. Not everything new needs to be written in rust. And your re-writes of programs that have already been written in other languages and work well aren't that compelling.
If you like rust, then write some new, interesting and useful software in the language, where what language it's written in isn't the main selling point. For example, I love the look of this http://nickel.rs/.
TL;DR - the corrosive nature of rust advocates on HN is starting to eat away at my patience, and I am tired of having to galvanize against them and their absurd claims.
Like burntsushi I feel you're attacking a straw man here. Or, you're attacking specifically the "salvation" article which was a bit hyperbolic on purpose (in which case you're mostly off topic in this thread)
> the constant "rust solves this unrelated problem, and has no flaws!"
Where do you see that?
> But it's not a panacea for everything wrong in software
Nobody says that. Folks generally focus on the memory safety and thread safety bits. The salvation article did say that Rust can solve all of the problems in software caused by C, which was hyperbolic (I wasn't really fond of that part either), but that's the only instance in a blog post or comment that I can recall this being said recently. There doesn't seem to be a trend as you see.
> We don't need to all immediately re-write everything we do rust. Not everything new needs to be written in rust.
Nobody says that either. If anything, I've seen folks (especially in /r/rust) advocating caution when asked about porting software to Rust.
> If you like rust, then write some new, interesting and useful software in the language, where what language it's written in isn't the main selling point.
There's a lot of this all over the rust community. Redox has reasons for existing other than Rust (https://doc.redox-os.org/book/introduction/why_redox.html). Servo similarly has a wide variety of interesting bits -- some of which have been enabled by Rust but aren't interesting because of Rust. Webrender in particular is something that could have been done without Rust. Servo's layout and style systems are pretty revolutionary, because of the way they work. Ripgrep (http://blog.burntsushi.net/ripgrep/) probably could have been implemented in Go and perhaps still win on some of the benchmarks; it's interesting because of the tricks that burntsushi used. https://github.com/google/xi-editor is also interesting, though incomplete.
There certainly was a phase where many threads about basic software (curl-type stuff, init systems, ...) had comments that felt like endless repeats of "it is 2016, stop writing new C code and just use Rust", which I personally found annoying. I either tuned it out or it has gotten better recently, and I don't think it was a organized effort, just a common pattern.
Yeah, most posts in HN Frontpage with Rust/C/C++ seemd to have a "never Write c(or the baddest: C++!!) in 2k16!1! Its useless because of Rust!"-comment.
Its kinda annoying, but i can ignore them pretty good, so i dont have more like a feel Here.
It could be less in the last 1-2 Month(s).
Yes, we had a recent explosion of marketing materials that went a little over the top. That's OK. It happens.
I don't think anyone really believes Rust solves every problem, so I think you're attacking a straw man. There are plenty of trade offs at play. But the problems we believe it does solve makes it exciting for a lot of us (and for perspective users).
Hello, I posted this because it looked interesting. I'm not a Rust advocate (I prefer GC-languages personally), the WebAssembly angle and different languages using it as a compilation target was more interesting than Rust specifically.
Right, sorry to hijack the thread, or imply you were one of the people I was talking about.
What are your general thoughts on web assembly? I am really optimistic about it - improving client side performance with a fast IR format will really open up a lot of doors, and make the web a much more viable platform for applications. I do note that many similar attempts have been made in the past though.
More seriously, I'm not sure who you mean by the paid rust advocates here. There are some core developers who work for Mozilla, but I can't imagine that a Rust-using company or individual would spend salary on an HN advocate rather than paying someone to work on the compiler or ecosystem.
You'd be mistaken. steveklabnik is a hired Rust evangelist who also writes docs.
> Wherever there is discussion about Rust to be found, be it IRC, the RFCs repo, or Reddit/HackerNews, you can be sure to find a comment or two from Steve there, explaining and clarifying the situation.
To be clear, my job description is "doc writer". I've been posting a ton on HN for _years_, and advocating for Rust before I ever had a job working on it. At the time that post was written, I was a contractor, and it wasn't clear if I was ever going to stay on with Mozilla; historically, I've told everyone this was a short-term gig, though my feelings on that have been changing a bit.
Regardless of that, if you ever hear me saying Rust is a "panacea" or "immediately re-write everything [in Rust]", call me out on it. I don't agree with either of those positions. I want people to accurately understand what's going on, not mislead them.
(I _do_ want to see more people using Rust, because I love it, but not everyone will also love Rust, and that's totally fine.)
Having idled around the same tech watering holes as you have for years, I'd think they'd have to make a significant effort to keep you from talking about it. ;)
I am a pretty active observer of rust community as the language abilities and paradigms excite and suit me. Therefore I do see steveklabnik as well as several others frequent these avenues. In all my time reading Reddit/HN/etc. I've never seen steve or the others "advocate"; they're doing exactly what that description states which is explain and clarify. The tech community brings up rust as a discussion topic and they spend their own time (possibly some of Mozilla's) to make sure that the community understands the organization (not just Mozilla), drive, and tech behind rust.
There is a difference between "someone working for Mozilla on a project also comments about it in public" and "Mozilla pays people to advocate for rust in public forums", and I don't think anyone is surprised by the fact that the first happens (arguably, it is one of the good things in communities like HN, and it's not like they hide where they work). Trying to construct this as paid shills or something is, IMHO, not helpful.
And from what I've seen, the "Why is this not written in Rust?" and similar comments are not from core Rust people, to the contrary they also explain why Rust does not fit for something (and potentially what's done to change it).
By me, for one, and I have nothing to do with Mozilla. I just follow HN for years, and have read Steve's comments even before he was working for Mozilla. He is just passionate about Rust and posts about it on HN (as opposed on the Mozilla blogs) on his own time, as he did on his own blog back in the day. As do other people, whether they work for Mozilla or not.
They are downvoted for spreading misinformation. Steve is not a "hired Rust evangelist". Steve was hired to write docs, and that's what he does. He has always maintained a large online presence in the Rust community, before and after being hired; but this is not what he was hired for.
Disclaimer: I also work for Mozilla (on Servo). Not paid to do advocacy online.
The part quoted heavily implied that he was paid to evangelize. Yet he was heavily down-voted for saying something relatively innocuous. I thought it was noteworthy.
What makes you and thesmallestcat even more incorrect is that this blog post is about Steve Klabnik and Yehuda Katz joining the Rust core team. This is an unpaid position with the (informally organized) Rust project, not a paid position with Mozilla Research. Mozilla employs Steve (though I think it was just a part time contract in 2014), but doesn't employ Yehuda.
The "Rust Core Team" is not a Mozilla construct. Many of the folks on it are Mozilla employees, but the core team is not a paying job.
Mozilla hired Steve to work on docs.
Steve was invited to the Rust Core Team because of his online activities, among other things.
Neither wycats nor steve were being paid by Mozilla at the point that post was written IIRC. (I might be getting my timelines mixed up here. wycats has contracted for mozilla in the past for cargo and stuff, but I don't recall exactly when that happened)
To reply to both of you at once, I was near the end of my first contract with Mozilla to write docs full-time when I was added to the core team; I then got a second contract, and finally, a "real job."
(I had to look this up in my email to remember myself, frankly.)
As a counter, stuff is posted to new every minute, but 90% of it doesn't reach the front page. In order to reach the front, you often have to do make up silly titles such as the ones you mentioned, which cause an emotional response (good or bad, as long as it gets clicks).
HN also has a problem with brigading, which is why you see some utterly random articles make it to the top too. Sadly not much you can do about this, but you could try browsing /r/programming or elsewhere instead.
I don't know the language (yet), but I've been keeping my eye on it for a few years, and I think it's going to be fantastic once it stabilizes and gets improved tooling.
I especially welcome the possibility of using a safe language like rust for web development, instead of writing more dreadful javascript...
You have to explicitly opt in to unstable features. Provided you don't do that, Rust is stable.
There are bits of the standard library marked unstable, yes. This is true in almost any language/compiler -- there's always some new/experimental or otherwise nonstandard stuff that the compiler will let you do if you opt into it. Clang has its own nonstandard bits. So does GCC.
The fact that almost all crates in the Rust ecosystem work on stable is an indication that enough of the stdlib is stable for it to be useful.
The Rust stdlib will never be "finished"; there will always be new things being added. This is true for every language. Allowing folks to experiment with unstable features is not a bad thing.
TL;DR: stuff starts out being added, sits in unstable for a while, then makes it to stable. No software is ever finished. Stability is not the absence of change; stability is the absence of things breaking.
> I'm curious about what "stable" means to rust advocates
You should read the blog post in the parent comment, as it explains, at length.
Define "unfinished". You're being deliberately misleading with that word.
The Rust stdlib has everything most folks need. There are some things like simd which are currently being actively pushed that are "missing", but even C++ doesn't have "stable" simd, it has compiler extensions in some compilers. Most of the unstable APIs in the stdlib exist independently in the crates.io ecosystem anyway (or their functionality can be replicated with other stdlib apis).
The fact that the rust stdlib can still be improved does not make it unfinished (or, if it does, being "unfinished" is not a bad thing). By that argument every language that still pushes out new versions is unfinished.
Your definitions of "stable" and "finished" exclude almost all the languages/compilers out there, I highly doubt these are the definitions that 99% of programmers use.
> Changing the API of the standard library on minor release versions is stable now
No it's not. A release version of rust cannot access that API. It's just there in the docs. We could possibly remove it from the release docs, or make the messaging clearer (this is being discussed), but you can't use it on a release. That is stable.
In both those cases the default release compiler contains the ability to opt in. With Rust, even this isn't the case; you have to download a different compiler if you really really want those features, and even then you still have to explicitly opt in at a fine-grained level.
Adding to the API of the standard library, as SemVer specs. Backwards incompatible changes aren't made. (Except for soundness reasons, which happens in extremely rare circumstances, and are made with great care with regards to the upgrade path.)
Rust releases follow SemVer, which is not exactly an uncommon standard for those things. Code that works in released version 1.X.Y is supposed to work in all following versions. Are there languages that won't add backwards-compatible features?
> So the language is stable, but it ships with an unstable, unfinished standard library?
No, it does not. It ships with a stable standard library, but methods that are unstable are also shown in the docs, so you can see what's happening in upcoming releases. And it links to the issue where you can get involved to help bring the method to stable, if that's important to you.
> I see rust advocates being called out on this _all the time_
If we ignore the unnecessary heat of the comment for a moment, there's an interesting developer experience misunderstanding in there. It may even be enough to just change the wording -- instead of "unstable", "proposed"? (Might sound too tentative.)
Yeah, totally. This would make for a very interesting RFC.
(There's also always been a disconnect between naming in this regard; that is, you can only use "unstable" things on the "nightly" build of Rust. And while we try to produce a nightly every night, it doesn't always happen, as these last few weeks have shown. That is changing, at least. But "proposed Rust" sounds stranger than "nightly Rust", so this disconnect might persist even if we decided to change "unstable" to "proposed". Side note: Ember and IIRC Chrome call their nightly versions "canary"...)
> I especially welcome the possibility of using a safe language like rust for web development, instead of writing more dreadful javascript...
There are now a number of typed languages that have solid compile-to-js support. I've done it with OCaml (js_of_ocaml, Bucklescript), F# (Fable), and Elm. For dynamic languages, there's also Clojurescript, which is quite nice.
I've coded in it a bit and it seems like cool language, they get a lot right and have some new and interesting ideas. But it's not a panacea (or indeed "salvation" as one recent blog post put it) for everything wrong in software. We don't need to all immediately re-write everything we do rust. Not everything new needs to be written in rust. And your re-writes of programs that have already been written in other languages and work well aren't that compelling.
If you like rust, then write some new, interesting and useful software in the language, where what language it's written in isn't the main selling point. For example, I love the look of this http://nickel.rs/.
TL;DR - the corrosive nature of rust advocates on HN is starting to eat away at my patience, and I am tired of having to galvanize against them and their absurd claims.