Homebrew's Rust receipt is still at 1.4 :( https://github.com/Homebrew/homebrew/blob/master/Library/For...
Homebrew receipt has been updated to 1.5 just a few hours later!
https://github.com/Homebrew/homebrew/commit/dee292132fb73820...
Rust 1.5
151–159 of 159 posts
Re: Rust 1.5
#152Earlier quoted context omitted.
Yes, but I also believe it's less as a proportion of population than it's ever been in the history of the world. There are approximately 7.3 billion people in the world[1], and there are over 35.8 million people in slavery[2]. That's less than half of one percent. But that doesn't matter, because slavery is bad, so any slavery, regardless of the amount is bad. So it could be 100 people in the world are enslaved, and…
You question a change to a status quo but ignore that the status quo deserves to be questioned just the same. The terms are clearly, obviously and unquestionably inspired by actual human slavery. That's in bad taste at best. Using the master/slave terminology so casually further weakens their original meaning. Not using the terms master/slave in a technology concept in no way erases awareness of the problem. Frankly…
> The terms are clearly, obviously and unquestionably inspired by actual human slavery.
I did not say they weren't I just said they were accurate in many aspects of what they were describing.
> Not using the terms master/slave in a technology concept in no way erases awareness of the problem.
I did not say removing them erases awareness, I said (in summary) that it provides a placebo effect that keeps people from doing something that actually matters. I agree removing them will not affect awareness of the problem, because they have no relation to the problem.
> Frankly to defend usage of these terms by suggesting using them in anyway promotes awareness and helps the victims of slavery, is disgusting.
Then it's a good thing I didn't do that then.
> You question a change to a status quo but ignore that the status quo deserves to be questioned just the same.
Anyone wanting to change the status quo should not focus on this specific case to the detriment of similar ones, if they really care about it. Why stop at master/slave, when there's also captive as in captive portal, or for that matter serve, since one original meaning in the root latin was "slave",and all we care about is the original meaning, not how it evolved over time to mean additional things (such as how slave as a verb can mean to work hard), right?
Re: Rust 1.5
#153Earlier quoted context omitted.
For the ignorant among us, do you have a link explaining what HIR/MIR is (and how it relates to Rust)?
I should blog about it, because I keep writing comments. :) So, the basic process of compiling is: source -> AST -> LLVM IR -> asm At each step, you can do transforms too, so like, LLVM will take in LLVM IR, but before compiling, will simplify/transform it into other IR. There's a few issues with this. The first is that any processing we want to do, like optimizations, safety checks, etc, has to work on the AST. This…
It does make sense, and thank you very much for taking the time to explain! :)
Re: Rust 1.5
#154Earlier quoted context omitted.
One benefit: one could install latest version of Rust on any distribution. Debian stable for instance usually lags behind (with good reason, but still...). I imagine it is mostly useful for checking out Rust though, not for normal use.
The installer from https://www.rust-lang.org works fine on Debian stable. Right now, you can just use the upstream rustup.sh script for platforms that don't yet have it packaged (like Debian stable), or install from your distro for those that do (or use rustup.sh on those as well if you like). What I'm not seeing is the value of a Docker image. Rust doesn't have much in the way of runtime dependencies, which is where…
So you think running some script on my machine is preferable to running a container? If I don't like having Rust around, with containers I can just remove it. With script - yeah, maybe, with some digging for correct parameters and assuming it cleans up after itself properly (which is far from trivial).
Packages are of course preferable if available and up-to-date.
Re: Rust 1.5
#155Earlier quoted context omitted.
The installer from https://www.rust-lang.org works fine on Debian stable. Right now, you can just use the upstream rustup.sh script for platforms that don't yet have it packaged (like Debian stable), or install from your distro for those that do (or use rustup.sh on those as well if you like). What I'm not seeing is the value of a Docker image. Rust doesn't have much in the way of runtime dependencies, which is where…
So you think running some script on my machine is preferable to running a container? If I don't like having Rust around, with containers I can just remove it. With script - yeah, maybe, with some digging for correct parameters and assuming it cleans up after itself properly (which is far from trivial). Packages are of course preferable if available and up-to-date.
rustup.sh has an --uninstall flag that should remove everything cleanly.
Re: Rust 1.5
#156Earlier quoted context omitted.
Try Elixir ( https://elixir-lang.org ). Phoenix framework is awesome and working with it is a pleasure.
Thanks. Elixir looks interesting. I'm apprehensive about the "runs on Erlang" part though (wary of compiles-to or runs-on languages, unless the "to" or "on" is C).
You should become skeptical of languages that compile to C. I can't get into the details because I don't know them very well, but take a look a pcwalton's comment history for a fairly technical discussion of why it makes a poor compilation target.
Re: Rust 1.5
#157Earlier quoted context omitted.
Apologies, I should have mentioned that. It's been about 9 months.
I'm not sure what's considered slow or fast, but I just tried a couple of larger-ish rust projects. All data on a midrange SSD, i7 ~4.4Ghz. Warm disk-cache, so pratcically everything in RAM. crates.io backend service: # Note the thing pulls down lots of dependencies doing # install, so this is after a "cargo build;cargo clean": git clone git@github.com:rust-lang/crates.io.git crates.io.git cd crates.io.git/ ./script/…
You should note that "cargo clean" causes dependencies to be rebuilt next build as well; a regular "cargo build" would only re-compile your module and re-link with already-built dependencies, and so should be a fair bit faster.
Re: Rust 1.5
#158Earlier quoted context omitted.
I'm not sure what's considered slow or fast, but I just tried a couple of larger-ish rust projects. All data on a midrange SSD, i7 ~4.4Ghz. Warm disk-cache, so pratcically everything in RAM. crates.io backend service: # Note the thing pulls down lots of dependencies doing # install, so this is after a "cargo build;cargo clean": git clone git@github.com:rust-lang/crates.io.git crates.io.git cd crates.io.git/ ./script/…
You should note that "cargo clean" causes dependencies to be rebuilt next build as well; a regular "cargo build" would only re-compile your module and re-link with already-built dependencies, and so should be a fair bit faster.
Good point. I did that on purpose in order to do a full rebuild -- but I suppose for the purposes of "is rustc fast", it's actually more interesting to just do a build without clean (although one would have to manually remove the built binary and/or change the code in order to force a rebuild?).
Re: Rust 1.5
#159Earlier quoted context omitted.
So you think running some script on my machine is preferable to running a container? If I don't like having Rust around, with containers I can just remove it. With script - yeah, maybe, with some digging for correct parameters and assuming it cleans up after itself properly (which is far from trivial). Packages are of course preferable if available and up-to-date.
rustup.sh has an --uninstall flag that should remove everything cleanly.
Should. It wouldn't be the first script to have a bug.