I thus asked about providing a Docker image - the person that handles the builds and the SDKs says that nightly builds are on the way: https://github.com/kripken/emscripten/issues/4682#issuecomme...
This is a great example of docker-for-dev. Don't bother setting up the specific versions of compilers and then worry about clean-up afterward.
The guide should be 2 lines: docker pull, then docker run.
Also I forked it to use handlebars: https://github.com/sunng87/rust-todomvc
Using asmjs, the compiled js file is about 20MB and can be slow in browser. While wasm32 one is just ~500KB.
I did this over the holidays just to see it in action. It was a pain to get the emscripten sdk installed (especially on a slow connection) but it's quite cool to see it in action.
There's also a asm.js target which you can add like this:
$ rustup target add asmjs-unknown-emscripten
I'm not sure about browser support for asm.js but recent versions of node support it.
What all does the Emscripten SDK provide?
I've read the overhead of Rust's standard library is about 100kB. Not sure if putting it through the Emscripten toolchain changes that significantly.
For this specifically, I made some numbers when it first landed: https://www.reddit.com/r/rust/comments/575pp6/compiling_to_t...
Regardless, this is in a "oh my god it works" state, not a super serious best-we-can-do state. My understanding is that it's larger than it has to be at the moment. We'll get there.
It's looking pretty good already. Thanks for the reply.
I guess compiling a language like Rust to WebAssembly solves these issues for a part?
But this would have to be a rather cut-down version of the JVM, I think, so probably not that viable.
There was a flurry of Rust posts about "why Rust" near the end of the year, which was somewhat "coordinated". In the sense that Steve wrote a post and this triggered a chain reaction where all kinds of folks wrote about related topics. Completely unintentional, just happened. Most of those posts did not make it to HN.
No marketing plan involved, and nobody coordinates these posts.
"A Go compiler, written in Rust."
Granted, it would require writing a garbage collector in Rust...
Why would that be a problem? There are compilers written in C that implement garbage collectors.
Now, writing a garbage collector for Rust, that's another problem entirely
> Now, writing a garbage collector for Rust,
(mostly a toy GC, but some folks are using it)
In the future we may have http://manishearth.github.io/blog/2016/08/18/gc-support-in-r...
> In the future we may have http://manishearth.github.io/blog/2016/08/18/gc-support-in-r...
I read that back when you first posted it, which is exactly what came to mind when I was writing my comment. At least to my naive understanding, implementing a garbage collector for Rust is several orders of magnitude more difficult than merely implementing one in Rust.
We've had problems with closures before in Servo, I know that pain :)
> implementing a garbage collector for Rust is several orders of magnitude more difficult than merely implementing one in Rust.
Well, I mean it depends on what you're aiming for. Making a safe optional GC in Rust isn't too hard; rust-gc exists and is not very complicated. Making the compiler support arbitrary pluggable GCs is trickier. GC algorithms themselves can get so complicated that the state of the art research probably eclipses whatever has been done with rust-gc and similar "GCs for rust" so far. If you want a GC for Rust that contains a world-class collection algorithm the complexity is additive but the source of most of the complexity isn't the "for Rust" part, it's the "in Rust" part (A GC for rust will also typically be in Rust).
But also "optional" GCs like those that would be useful in Rust haven't been explored much either, so world class algorithms may not even make sense in this case.
It's ... an interesting set of problems, and very hard to make judgement about what is difficult :)
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.
> 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.
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).
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).
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.
> 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.
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.)
Nobody is paid to evangelize on message boards.
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).
Disclaimer: I also work for Mozilla (on Servo). Not paid to do advocacy online.
Sibling comments to yours corrected this point prior to you making this comment, which makes it harder to assume good faith about your actions here.
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)
(I had to look this up in my email to remember myself, frankly.)
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.
More than once as an employee I've been asked to upvote a company post. Obviously I immediately flagged said posts.
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.
After 1.0 the Rust releases have been stable, with the stability checked against the entire ecosystem on crates.io. https://blog.rust-lang.org/2014/10/30/Stability.html
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.
If you run that example on stable Rust, you'll see
error[E0554]: #[feature] may not be used on the stable release channel
I wrote about this here: https://news.ycombinator.com/item?id=13277438
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.
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.
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.
I mean, you have the same situation with https://gcc.gnu.org/projects/cxx-status.html#cxx1z . They, too, explicitly say that opting in to this may break backwards compatibility (i.e. it's unstable). http://clang.llvm.org/cxx_status.html says something similar.
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.)
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_
Called out on what, specifically?
(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"...)
1. Use nightly Rust.
2. Explicitly enable the `io` feature with a special directive in your source code.
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.