Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust 1.5

blog.rust-lang.org

Post reply on HN
Print view View original

121–130 of 159 posts

Re: Rust 1.5

#121

Post by kbenson »

DasIch wrote: post #102
kbenson wrote: post #98

Earlier quoted context omitted.

I don't know, to me master/slave embodies teh relationship of the devices better than leader/follower, and also has less alternate meanings when viewed as a verb to confuse what is going on. Is the leader "out front"? Is the leader "first"? Is the follower doing the same thing, but delayed in some manner (which doesn't fit standby situations very well). A master controls. A slave is controlled. Additionally, I think…

You do realize that slavery is a current problem, right? Slavery is a multi-billion dollar industry and there are tens of millions of people enslaved today in the entire world.

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 we would still need to do something about it.

But that's irrelevant. This is about terminology and wording. Do you really think anyone that's an actual subject of slavery cares if master and slave are used in some esoteric context to describe the relationship between inanimate objects and processes? Do you think they would prefer people spend their time arguing over this instead of actually doing something about the problem? The last thing we need is to cleanse our vocabulary of these terms. If we actually want to make a change, hiding is not the correct thing to do.

Armchair terminology censoring isn't actually doing anything to help the problem, it's just providing a way to make people feel like they are helping without actually addressing any part of the real problem. Ultimately it's not just ineffective, but since it fulfills people's desire to feel like they are making a difference it's actual harmful in that it prevents some people from actually getting to the point they would do something.

To make my point absolutely clear, using master/slave as a terminology to describe non-sentient processes is in no way condoning slavery, does not affect slavery, and does not harm anyone. Artificially linking the this concept with actual human slavery and the slave trade for the purpose of denouncing it is selfish, dishonest, and harmful. That said, I don't think most people are necessarily conscious of what they are doing when doing so, but that still leaves us with harmful.

1: http://www.worldometers.info/

2: http://www.globalslaveryindex.org/

Re: Rust 1.5

#122

Post by e12e »

clessg wrote: post #7
steveklabnik wrote: post #5

Earlier quoted context omitted.

Well, "now" is relative. When did you last try? They've been steadily dropping each release, though this latest one isn't as large as the last few.

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/init-local-index.sh 
  multirust run nightly cargo build --release
  multirust run nightly cargo clean
  # 4 threads, ~100% CPU up to compiling the final cargo.io bit,
  # which takes the longest:
  git diff
  diff --git a/Cargo.toml b/Cargo.toml
  index cf99b60..02e54fb 100644
  --- a/Cargo.toml
  +++ b/Cargo.toml
  @@ -5,6 +5,7 @@ version = "0.1.0"
     
  [profile.release]
  opt-level = 2
  +codegen-units = 4
     
  [lib]
  name = "cargo_registry"

  $ time multirust run nightly cargo build --release
  real    1m29.082s
  user    4m47.276s
  sys     0m6.196s

  # Single threades (default Cargo.toml):
  real    1m41.210s
  user    4m0.376s
  sys     0m5.120s
Servo:

  git clone https://github.com/servo/servo servo.git
  cd servo.git/
  ./mach build --release
(Servo also pulls down lots of dependencies, including a full rust toolchain...)

  ./mach clean
  time ./mach build --release
  Build completed in 791.07s
  real    13m11.874s
  user    40m21.468s
  sys     0m51.304s
At approximately 100% cpu for the first part, either the servo build script makes sure things are parallelized, or the Cargo.toml-settings are set for parallell builds (haven't checked).

And finally, a smaller project:

  git clone https://github.com/Aaronepower/tokei.git
  cd tokei/
  cargo build --release
  cargo clean
  
  $ time cargo build --release
  real    0m30.354s
  user    0m32.708s
  sys     0m0.444s
According to tokei (which is a blazingly fast cloc tool), there's ~100k cloc of rust in servo, ~7500 cloc of Rust in crates.io (but that doesn't include all the dependencies...).

After doing a clean install of rust stable with multirust, the combined cloc of stuff under ~/.multirust...cargo/src and tokei is ~11.5k cloc of rust, along with ~ 1400 cloc of c++.

Re: Rust 1.5

#123

Post by kbenson »

issaria wrote: post #92
kbenson wrote: post #85

Earlier quoted context omitted.

You seem to think he is implying something about go. I'm pretty sure whatever you think is being communicated in the original comment was not the intention. Try asking for clarification rather than stating your interpretation of what someone said as fact. Try giving people the benefit of a doubt. To my eyes, the only one being aggressive here is you, when others are just trying to correct what appears to be your misi…

Well, for being someone from Go community and commenting in a Rust thread, your feeling that I misinterpreted the statement is legit. But lets be honest, there are some attitude somewhere in the original comment, and I admire him being open.

> But lets be honest, there are some attitude somewhere in the original comment

I really don't think there was. I think he was trying to communicate how serious they are in hitting their 6 week release timeline, and that marketing a release by matching some other current event (such as a Go release with a specific version) is not important to them when compared to this. The only attitude I think should be inferred from this is that they really want to hit their release schedule.

> and I admire him being open

I think his apology was for being unclear, not for disparaging another language. I think this is just some of the left over feeling you have from the original perceived sentiment of the comment. It can be hard to shake the feeling of an initial reaction, even if you've logically processed away much of the original reason for that feeling. It probably doesn't help that there's been some anti-Go sentiment going around HN lately, but that doesn't mean that was his intention.

Re: Rust 1.5

#124

Post by untothebreach »

rhodysurf wrote: post #114
untothebreach wrote: post #71

Earlier quoted context omitted.

Except that people's experience of words doesn't come from the dictionary. Words aren't experienced in a vacuum, people assign different meanings to words based on their own experiences. To some of us, "master/slave" is just a phrase to describe an architecture. To others of us, it has historical connotations that makes it inappropriate.

Okay but that doesn't mean the word stops existing. My point is that master and slave are general terms, not specific to one group of people. This is a slippery slope to go down.

Sure it's a slippery slope, but let's think about this from the perspective of an open-source project (where I most see this issue debated).

If a goal of yours is to attract as many people to contribute to your project as possible, then it only makes sense to avoid using terms that might discourage others by making them uncomfortable, at least in the context of the project (issue trackers, documentation, etc). Saying, "well those words are defined as ___ in the dictionary" doesn't change the fact that you are losing potential contributors. Especially when there are other terms that work just as well, it only makes sense to avoid potentially problematic ones.

I'm not going to say you (as an individual) should stop using those words. That is your business, not mine, and if you run into any consequences of using specific words, that is also your business.

Re: Rust 1.5

#125

Post by dvdplm »

steveklabnik wrote: post #26
moonchrome wrote: post #22

Earlier quoted context omitted.

I'm particularly interested in incremental recompilation. From what I can see it hasn't landed yet (?) - but I can't seem to find any ETA on when it will.

There isn't a strong ETA, no. Everything about internals is basically waiting until after the HIR/MIR work lands, as it would end up changing a lot anyway, so that's where the focus is at the moment. That doesn't mean the _discussion_ about how it works has to stop in the meantime, though...

For the ignorant among us, do you have a link explaining what HIR/MIR is (and how it relates to Rust)?

Re: Rust 1.5

#126

Post by steveklabnik »

jmquigs wrote: post #116
pjc50 wrote: post #44

Earlier quoted context omitted.

How long is "long"? What sort of time would we be talking about for 100KLOC projects?

I don't know about 100K, but for my 5667 line project, a recent nightly build takes 8 seconds to build on my 2012 macbook pro (4 core 2.3G i7). That is with up-to-date external crates that aren't being rebuilt. Typecheck happens early, with borrow-checking following soon after, so you get feedback on errors fast, and thus only end up waiting when the compiler is happy with your code. Still, it may be an issue for peo…

That exact property is why cargo check works.

Re: Rust 1.5

#127

Post by rhodysurf »

untothebreach wrote: post #124
rhodysurf wrote: post #114

Earlier quoted context omitted.

Okay but that doesn't mean the word stops existing. My point is that master and slave are general terms, not specific to one group of people. This is a slippery slope to go down.

Sure it's a slippery slope, but let's think about this from the perspective of an open-source project (where I most see this issue debated). If a goal of yours is to attract as many people to contribute to your project as possible, then it only makes sense to avoid using terms that might discourage others by making them uncomfortable, at least in the context of the project (issue trackers, documentation, etc). Saying…

By this thinking any word without context can cause outrage.

Re: Rust 1.5

#128

Post by untothebreach »

rhodysurf wrote: post #127
untothebreach wrote: post #124

Earlier quoted context omitted.

Sure it's a slippery slope, but let's think about this from the perspective of an open-source project (where I most see this issue debated). If a goal of yours is to attract as many people to contribute to your project as possible, then it only makes sense to avoid using terms that might discourage others by making them uncomfortable, at least in the context of the project (issue trackers, documentation, etc). Saying…

By this thinking any word without context can cause outrage.

All I'm saying, is if you recognize that a word is potentially costing you contributors, why wouldn't you change it if there is another word that is just as good?

I'm just trying to be practical, not trying to force PC-think down anyone's throat.

Re: Rust 1.5

#129

Post by eoi »

e12e wrote: post #109
steveklabnik wrote: post #3

Earlier quoted context omitted.

Run rustup.sh again, and it will Just Work. (If not, that's a bug.) If you want to have multiple versions installed at the same time, https://github.com/brson/multirust is super cool. Generally speaking, installation is something we're working on: working with Linux package maintainers, rolling rustup and multirust together and making them work well cross-platform, etc.

Strongly recommend multirust. It can eat a bit of space if you end up with both stable, beta and nightly installed (but that can still be a good idea -- obviously lots of new projects will experiment with some new features). But multirust takes a lot of cues from other similar tools for sandboxing. I just did: $ multirust update $ multirust show-default multirust: default toolchain: stable multirust: default location…

Also worth noting is multirust-rs, a reimplementation of multirust in Rust, which notably adds Windows support. I haven't tried anything fancy with it yet but so far it just works.

https://github.com/Diggsey/multirust-rs

Re: Rust 1.5

#130

Post by steveklabnik »

dvdplm wrote: post #125
steveklabnik wrote: post #26

Earlier quoted context omitted.

There isn't a strong ETA, no. Everything about internals is basically waiting until after the HIR/MIR work lands, as it would end up changing a lot anyway, so that's where the focus is at the moment. That doesn't mean the _discussion_ about how it works has to stop in the meantime, though...

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 means that when the AST changes, these features need to change. This is why compiler plugins aren't stable, we're not ready to stabilize the AST yet. Doing so would mean things like "we can never add a new keyword", or at least, makes that process harder.

The final process for Rust will look like

  source -> AST -> HIR -> MIR -> LLVM IR -> asm
HIR is "higher IR" and MIR is "mid IR". In this sense, LLVM IR is a "low IR". There's two important aspects here: the first is that this decouples the AST from things like plugins, which can operate on the HIR, which we will stabilize. The second is that at each step, things get simpler. Here's an example. We have both regular old if statements, and match, which can do more powerful, structural things. Both are fundamentally jump statements, though, and so we can transform the more complex match into the more primitive if. This means that by writing safety checks, optimizations, and other things against MIR, they're both easier to write, as well as more maintainable.

There's one other minor benefit: Someone who wants to write an alternate compiler could theoretically write MIR -> ASM, and eliminate LLVM entirely. While we have less than zero percent chance of doing that ourselves, it might be nice if you want to support some sort of esoteric platform LLVM doesn't, for example.

Does that all make sense?

Post reply on HN