Hacker News new | comments | ask | show | jobs | submit login
Rust 1.5 (rust-lang.org)
342 points by steveklabnik on Dec 10, 2015 | hide | past | web | favorite | 149 comments

Congrats to the team!

I recently wrote my first Rust [1] project. Great experience, IMO. I faced a lot of interesting challenges because my use case was a little outside of typical. But I tried to minimize 'unsafe' and I was still satisfied with the results so far.

I know I've only just scratched the surface of the language and I'm looking forward to learning more.

[1] https://github.com/androm3da/libfaultinj

Just a small remark. You might want to note in your readme why you'd want to use a fault-injection library. I wasn't familiar with the concept, and had to google why you'd want to do that (for testing unexpected errors and the application's handling of those errors).

This looks like a really cool utility! What other tools out there provide the same service, and how do they compare to this?

I don't think there are any that I know of. There's several tools that leverage LD_PRELOAD hooks though.

ElectricFence is similar but focusing on out-of-bounds memory accesses. Actually, that's not really fault injection, more like sanitizing bad behavior.

There's other fault injection stuff for linux, usually at different layers (I've seen some that use systemtap, e.g.).

I'm looking for something that simulates network errors (in particular: connect timeouts, read timeouts and sudden disconnects). Randomness would be good, too. Know anything for this that can be applied for individual processes?

Yeah, I am pretty sure this is doable but it's not covered by libfaultinj yet.

I opened an issue [1]. I'll get on it.

[1] https://github.com/androm3da/libfaultinj/issues/1


Congrats first of all!

I love Rust and am using it more and more. I'm very excited for 'cargo watch'. These tools built into the package manager will be so helpful with peoples' first time Rust experience. I think I'm going to say it, Rust has my favorite package management system of any language I've used.

Side Note: I'm also a fan of the 6 week release assembly line Rust has going on. I'm glad that it's staying consistent.

I was actually suggesting that the Rust devs delay the release until next week because all the release orchestrators are fully occupied with the bi-annual Mozilla workweek, but it seems that they've managed to pull it off without a hitch. :)

I've been excited to try Rust for some time now, but I've been holding off, only because I'm primarily developing web applications and I've heard from a few people that Rust is better suited for other tasks (based on the built-ins, packages, etc.?), despite there being at least a few frameworks out there.

What are your thoughts on this? Have things changed? Is the assumption just dead wrong, and Rust is in fact tremendous for web application development?

I've been toying with a web app[1][2] using hyper[3] as for http connections and ws[4] for web socket connections. This was my first project using anything lower level than Javascript. I had a fairly good experience, my problems stemmed more from not knowing the least bit about memory management rather than lack of libraries. In fact the libraries that are already there tend to be very well documented, with lots of examples and explanations.

1: http://theremins.club

2: https://github.com/runarberg/theremins

3: https://crates.io/crates/hyper

4: https://crates.io/crates/ws

For production ready, out of the gate, little config, extensive ecosystem, Rust isn't quite there. It will take much more to get many of the things that other languages/frameworks/libraries already provide that are well tested and stable. But the community is progressing surprisingly fast, so I don't think it'll be long before enough of the helper libraries are well tested and stable that building a web server wouldn't be much more difficult than other options. For just a web server, depending on what you're doing, the benefits of using Rust compared to say Node or Go are still, IMO, not a big list YET. One big thing for me is the Rust types system.

I'm working on a new project now where my web server will be Node, however much of my api and micro services/jobs will be in Rust. I expect it to go well, we'll see.

I have historically been skeptical of Rust as an application-tier language, but my experiments with it as of late have made me reconsider a bit. The largest weakness, imho, is the lack of libraries for various standards and formats: do you really want to implement OAuth yourself? (EDIT: Apparently we do have OAuth now. ha!) The maturity of the Rails ecosystem has spoiled me.

Here's a random fact that I've always found interesting: https://crates.io/ uses Rust on the server. It links to libgit, it does a lot of stuff. It uses about 30 megs of memory, resident, at all times. Coming from Rails, that's... shocking.

I have witnessed someone implementing OAuth2 themselves: https://crates.io/crates/inth-oauth2 I hope they solved the problem permanently, since this is the third crate attempting OAuth2 and the first two are abandoned/incomplete.

I don't even know what a "complete" OAuth2 library would be. One that not only deals with the quirks of existing services that use OAuth2, but anticipates all future ones?

You can certainly try it out for web applications. It has shortcomings, but I assume that by "try Rust" you don't mean "immediately develop something for production"? :)

I have a deamon running that does a specific reverse proxy thing. I wrote it in Rust, and that has been a very pleasant experience. For example, the excellent support for serialization and deserialization makes working with JSON a breeze :)

Rust is immature in general. It will probably make a perfectly good language for web, comparable to e.g. OCaml, though the manual memory management is always going to add a little bit of overhead. IMO the web is a lot like anything else, and the best web languages are just the best general-purpose programming languages.

I haven't written a lot of Rust, but what manual memory management are you referring to? As far as I can tell, the whole point of the language is that you don't have to worry about that if you listen to the compiler.

It's sort of the opposite, it's that the compiler won't permit you to neglect any aspect of memory management until it deems your work passable. You think about memory management even more than you would in most languages. The result is you get some guarantees about correctness.

You may have to think about it, but you certainly aren't doing the work of e.g. writing malloc and free statements.

You have to think about it. You don't have to worry about it.

This sounds like Rust propaganda! It's too slick...

it sounds slick, but for the first few hours you'll think that hell is a nicer place than here because the borrow checker won't be there. it takes a while for it to become slick again and only then you really start to appreciate the language. theory vs practive and all that.

It'll get there simply because the language is doing pretty well and lots of people write web servers but it's not there yet. Once someone figures out "the way" to do an internet-facing async http/http2/websocket server I think we'll see a lot more motion in the Rust web dev space.

There is this reference site [1], though I have no personal experience so I am not sure if it is up-to-date.

[1] http://arewewebyet.com/

Edit: According to Steve Klabnik in his comment below, it is not up-to-date.

If not for Rust, would you write your app in C++ or Python/Ruby/JS?

Python (currently using), or Go.

Add JS to that list as well, because I've done a little bit of work in Node, but that was before Coroutines (back in the days of yore when "callback hell" was a thing), so I wasn't nearly as excited at the time as I probably would be now.

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.

Actually Elixir and Erlang are totally interoperable with zero overhead. They both compile to BEAM virtual machine code. That "runs on Erlang" part is a selling point IMO.

So no, Rust is not a good option :)


That site has had open pull requests for almost a year, it is not accurate.

Maybe they aren't web.

I know this seems like a trivial issue, but I've been bothered by the try!() macro for a while. I keep hoping then will adopt the "?" postfix operator to mean the same thing, because it seems to increase readability a lot.

I'm open to other ideas too, but that seemed like the simplest way to get the error handling out of the way.

Ordinarily I try hard not to complain about syntax, but this seems to cause people to use .unwrap() where it's not safe (like a library).

There was major movement on the ? syntax last night, actually.

Huh, does that reflect in RFCS or something somewhere?

I'm quite pleased by the current solution and am not such a big fan of "?".

I'm curious what you do. Do you use try!() extensively, and fine it just fine? Or do you use something else, like .unwrap()?

Yep, I just use try!(), with the appropriate From implementations.

Great to hear! Thank you.

No problem. To be more specific, https://github.com/rust-lang/rfcs/pull/243#issuecomment-1633... and https://github.com/rust-lang/rfcs/pull/243#issuecomment-1633...

TL;DR: we're still adjusting process a bit, but the idea is that this is "good enough" to actually land, behind a feature gate, to start gaining experience. We still reserve the right to tweak it before it goes stable, but it's better to get it into people's hands, rather than continue to debate the last few minor points.

It seems really wasteful to be working on a specific macro rather than a general-purpose solution (i.e. an equivalent of do notation or scala's for/yield) that will work for things other than error handling.

If you want duck-typed do, there's https://crates.io/crates/mdo

If you want real do, and I do, then you need HKT, which is a massive upgrade to our type system that will take a very long time. If we can do something simpler in the meantime to ease some pain, then it's worth it.

Agreed, if you work with I/O, all the try!(try!(try!())) start making your eyes bleed. The ? suggestion is quite brilliant, been waiting for progress on that for a long time

There was just a burst of conversation on this and I think it will be accepted under a feature gate while they work some Type stuff out

How are compile times now? The one barrier I had to using Rust for anything large was the awful compile times.

Very happy to see the tooling improvements, though. Great work!

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.

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...

Well even a guesstimate would be nice :)

I've been following Rust from sidelines before 1.0 and from my perspective there are advantages but I can also see a lot of pain in porting stuff and moving over and I right now the benefits don't outweigh the risk and cost for me - but having a fast build system (which implies incremental recompilation) along with a default package manager (which it already has) would be enough for me to start working with it seriously.

It's kind of sad that building code is such an instrumental part of developing C++ when it's just about dealing with technical issues of the compiler/language/tools and not the problems I'm trying to solve - anything that gets me away from that while leaving me with similar level of memory control and portability is a big win for me.

So when should I be looking back at it ? 6 months ?

There's two components to this. I just asked the relevant people, they said "Six months is a safe guess, we hope sooner, we have ambitious plans, we'll see."

However, there's also something mentioned in this announcement: cargo-check. In terms of the "I'm building a project and I don't want my builds to be slow," I think that cargo-check might even be more important. cargo-check relies on an important insight: many times, when you're compiling, you don't actually care about producing a binary, you care that your code passes typechecking and other passes. cargo-check basically runs those things, and doesn't produce the final binary. Makes sense?

Is this something which the editor plugins can make use of? (as a quick lint/feedback about the code). My guess is that the plugins actually use naked rustc call rather than cargo build.

Currently, it basically runs `rust -Zverbose -Zno-trans`, so yes. If it gets more advanced, we'll see.

What would make you choose swift vs rust at this point? The compile speeds have been getting pretty close to objective-c levels, there is 1st and 3rd party package management and its been recently open sourced and is actually being developed in the open.

On top of that they have the financial backing of apple.

Does Swift run on Windows ? Emscripten ? Android ? Portability is also a big question that Rust has a lot better incentives to solve than Apple.

I got the impression that Linux support is more of a "here iOS/OSX develoeprs - we're aware you don't actually run OSX on your servers so you can share code between client and server now". I was not aware Apple wants to push Swift as a cross platform language.

If it was and their commitment looked credible (ie. they start porting tools like integrating debuggers and stuff on other platforms as well) I would definitely consider it.

If you want a guess, I guess "in 2016".

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?

It does make sense, and thank you very much for taking the time to explain! :)

What does HIR/MIR mean ?

Apologies, I should have mentioned that. It's been about 9 months.

I measured ~40% improvement from 2015-05-10 to 2015-10-30. That is, it takes 0.6x time to compile. 2015-05-10 was chosen because Rust 1.0 was released 2015-05-15.


Since then Rust 1.2 had a big focus on performance: http://blog.rust-lang.org/2015/08/06/Rust-1.2.html

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/
  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"
  opt-level = 2
  +codegen-units = 4
  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

  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++.

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?).

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 people who like to do TDD or need to do a lot of run-time verification.

For a big project you'd probably need to split it up into multiple crates to "emulate" incremental compilation, at least until it is supported by the build system.

That exact property is why cargo check works.

You would definitely split that project up into multiple crates at the moment. 100KLOC would take an eternity to compile. My guess would be 15 to 45 minutes for a release build, depending on things like how much you were using generics.

I have a small question : I have installed 1.4 through rustup.sh.

What is the clean way to upgrade to 1.5 ? I don't think there is some kind of 'rustup.sh upgrade' Delete 1.4 & reinstall ? Or downloading rustup 1.5 will apply a clean install on the existing one ?

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: (...)

   rustc 1.5.0 (3d7cd77e4 2015-12-04)
   cargo 0.6.0-nightly (e1ed995 2015-10-22)

   $ multirust list-toolchains

   $ du -hs ~/.multirust/
   996M    /home/e12e/.multirust/

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.


The intention is to unify this, multirust, and rustup.sh. It will probably just be branded "rustup."

Thank you so much for posting this. I was expecting something like this to pop but never tried searching.

It's also easy to have multiple versions installed using nix.

Any plans to offer official Rust Docker images?

Or is this it? https://hub.docker.com/r/jimmycuadra/rust/

What benefit would Docker images have over the existing upstream distribution or distro packaging? The Rust compiler doesn't have any particularly complicated dependencies, either installing the binaries directly from rust-lang.org or installing packages from your distro (if your distro has packages yet) should work fine.

Container images are great for daemons with possibly complicated dependency sets that might have conflicting version requirements with other packages and can benefit from isolation from other packages that containerization gives, but seem like a pretty heavyweight solution for just installing a compiler.

A few reasons:

- It is common for languages to have official Docker images (Java, Ruby, Python, Go, Erlang, Haskell, Julia, etc)

- In August the install process didn't work on my Debian system, eventually got guidance for workarounds from IRC

- Our build farm is docker based, application deployment environment is docker based

- Ensures development environments are identical

- Solves the multiple compiler issue

As much as I use Docker, it'd be tough for me to call it heavyweight. In terms of resource consumption Docker is just a neat wrapper over some functionality that is built in to the kernel, there is no "vm" of any sort, which is a common misconception.

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 the value of a container generally comes in. I don't know of a platform where Docker image would work but rustup.sh would not.

I'd attribute it to IMO bad devops habits encouraged by Docker. It's too easy in Docker to depend on someone's unofficial image ("FROM rustxyz" vs. "FROM debian + download deps + install rust"). Having official images would at least reduce the number of people building their infrastructure on unverified/unofficial images.

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.

There aren't any plans at the moment, no.

rustup.sh is really freaking awesome. I was shocked at how insane it is to set up Go when I peeped at my friend installing it.

Never heard of programming but you still want to compile a project?

Step 1: run rustup.sh (curl -sSf https://static.rust-lang.org/rustup.sh | sh)

Step 2: clone the repo of the project or your regional equivalent

Step 3: cargo build --release (or now with the new cargo install feature, cargo install)

Step 4: Enjoy

I've been writing small libraries in Rust and calling them from Python. Fantastic pair! Congrats to the Rust team.

cargo install is by far the most interesting one in terms of usability. I was wondering how to write deployment instructions for my binary program written in Rust; it's kinda clunky to say "here, open target/release/my_program or copy it to /usr/share/bin"

Homebrew's Rust receipt is still at 1.4 :(


Homebrew receipt has been updated to 1.5 just a few hours later!


This doesn't look like 1.4 but _1.0.0-beta.4_, so much older.

I've just updated the link.

It is 1.4 as I've brewed rust few minutes ago.

And you get the point, don't need to picky on the specifics.

Is this coincident with Go 1.5 release?

No. We release every six weeks, period. Any resemblance to other releases, living or dead, is purely coincidental.

FYI, Go releases roughly every six months.

From http://blog.golang.org/go12, "This new release comes nearly seven months after the release of Go 1.1 in May. We anticipate a comparable interval between future major releases." Go 1.3 and 1.4 took six months, 1.5 eight months.


I think he was going for funny. It's a common preamble to TV shows to say "Any resemblance to real people, living or dead, is just a coincidence." It keeps them from getting sued by people.

It is called humour.

> . Period.

This is not humour, this is aggressive.

I apologize, I was going for humor. No aggression was intended. Humor is hard in text.

What I meant with the "period" is that our schedule isn't tied to features, if a feature isn't ready, it just misses the release and goes into the next one. I can say, unless there's some kind of catastrophe, that Rust 1.6 will be released on the 21st of January.

> > . Period.

> This is not humour, this is aggressive.

In US English, at least, following a statement with "period" (I think UK's "full stop" is used similarly) indicates that the preceding statement is concrete and has few exceptions. It's not typically used to indicate aggression, unless spoken out loud with an aggressive tone.

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 misinterpretation of the original statement.

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.


Sadly, this isn't even unusual. Open source developers as a whole are 90% male or more; some older surveys found the number higher than 98%. http://readwrite.com/2013/12/11/open-source-diversity

As a long-time member of the Rust community I am seeing this changing over time, but much more slowly than I'd like. Rust is a very friendly community; we have an actively-enforced code of conduct (which has been in place since the project started >5 years ago); and some people in the community have recently put resources into things like sponsoring women and minorities to go to the first http://rustcamp.com/ conference. The RustCamp CFP had a blind review process to help avoid bias. The Servo team is currently sponsoring an Outreachy intern. And we are definitely looking for more ways to be as welcoming as possible to everyone.

I think this is just a reflection of the proportion of the female contributors in overall open source communities. There's really no reason for the Rust project to do anything "anti-female". Actually I think it is a bit too concerned with diversity.

Then the problem now becomes why there aren't that many female contributors out there. This is just a theory, but I think it is because males' nature make them do free labor to obtain fame. I admit this is purely my experience, but females are more likely to refrain from such labor that does not pay off.

As a long time member of the Rust community (since the beginning of 2013), I don't see much improvement, if at all. I wonder why we have different perception of the issue.

I definitely know more women involved in Rust than I did a year ago [EDIT: in percentage terms, as well as absolute numbers], but this might just reflect my own awareness rather than any greater trend. I don't have any non-anecdotal evidence. Actual surveys of Rust developers/users would be useful.

Also, most of the people I know in the Rust community now are now "users" of the language, rather than people working on the compiler/platform itself. (This wasn't true for me a couple of years ago.) My impression is that the Rust community as a whole is growing and changing much faster than the compiler/internal developer population.

Oh, I agree there are more women involved, but I attribute that to greater popularity of Rust. What I don't see is change in relative number, not absolute number.

curious: do you see change in other OSS communities?

I hope you are trolling.

Would more women in tech be good? Of course! However there is some crazy SJW stuff going on at the moment in a lot of projects. People pushing for things like Master/Slave to be renamed to Leader/Follower. Wanting things like man (as in the man command on Linux) renamed to something non-gender-based. I mean fucking come on.

I am all for a more inclusive environment but some things are just stupid and it is getting a little crazy in place.

Looking at their comment history, "trolling" is a safe bet.

And I would assume anybody accusing the man(ual) command of being gendered is being disingenuous until proven otherwise.

(That said, growing up in the American South, I've seen enough disgusting attitudes still persisting that preserving established replicated systems terminology is not a hill I'm in the mood to die on.)

All of those things sound like isolated incidents rather than actual trends. Just using the term "SJW" communicates that you're in a constant state of readiness to be outraged about that stuff. Just treat it like the occasional silly overreaching that it is and be done with it, otherwise it creates an environment where there's no room for "community culture" discussions, ever.

Any time a community increases in diversity, there's a chance for friction. Maybe it's from old-timers with poor social skills who don't realize they've been in a bubble. Maybe it's from new people with their own problems, trying to blame the old culture for their own difficulties fitting in. You know what it's not? A conspiracy or a trend. The only constructive, grown-up thing to do is to try to understand and have empathy for both groups, while pointedly not belonging to either one.

In my experience, any time there's a kerfluffle about someone wanting to rename man(1) or <kerfluffle of your choice>, it's a very small group or an individual getting outraged over something silly, and an equally small group getting outraged over the first group's outrage. It's pointless and meaningless to the vast majority of the group, who just want to move on with their lives and get something done.

If these things seem like they're more common now in open source than they were 10-20 years ago, (a) you'd be mistaken, and (b) if anything, that's just a sign of more people becoming involved, which is a good thing. Let 100 more people in, and chances are one of them will be a little crazy. That doesn't mean they all are, it just goes with the territory.

Yeah the master/slave thing pisses me off. They are words in the dictionary used to describe something and that is all.

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.

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.

Right, but in this case master slave often describes the relationship between computer devices better than anything else. The slave device has no choice of what to do other than what a master device sends it. Leader and follower doest quite capture that as well in my mind.

> has no choice of what to do

Tell that to the MySQL cluster I inherited at my last job ;-).

In all seriousness, I have to disagree with you, in that I think leader/follower captures the relationship fine. But at this point, I think "whether the word captures the relationship" is very subjective.

Concepts don't stop existing merely because you ban the words used to refer to them. Masters and slaves have always existed in human history and will probably always exist. When we use the terms in software, we draw a metaphor from this experience. There's nothing wrong with that.

I don't see where anyone has proposed we "ban" any words at all. What I see are people who suggest that we use a different set of words, that accomplish the same ends as "master/slave," except with words that aren't associated with slavery.

> "Masters and slaves have always existed in human history and will probably always exist"

I don't understand this argument. I'm not saying your statement is wrong, but I fail to see how this is a justification for using the words in a technical context.

I don't accept that we can't use words that accurately describe a concept merely because some people find that concept unpleasant.


> The enslavement of an entire race of people goes quite a ways beyond "unpleasant."

Absolutely. But what we're talking about isn't racial. The last time I worked on a master/slave setup (I forget whether we used those terms), the "master" and "slave" were of the same race. In fact, the slave could become the master, and the master could become the slave.

You may tell me that we're talking about the words, and I suppose that's true. But the words are also used for same-race slavery, so the words are not inherently about a racially-charged situation either.

I would certainly welcome changing master/slave to leader/follower. It's no less clear, and it doesn't associate my software with something I'm deeply against. People might have different reactions to this thing so what's a stupid change to you might be a crucial change to someone else.

(I agree that changing man is a little silly as it's obviously short for manual)

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 it's worth looking at the issue with a wider perspective. Slavery is bad, but really what most people in the west think of when thinking of slavery is racial slavery, which is a more recent issue (at least at scale), and is a much more pernicious problem,since it's not really slavery that was the base problem, but extreme racism. Historically slaves could be anyone, and as such it was much more acceptable to have people into and out of the ranks of slavery. Historical slavery is more akin to indentured servitude.

That said, I imagine with a few hundred years experience, assuming we can drastically reduce the still present racism we have in our societies, we might have an different response to the words master and slave, one more in line with historical context, and not the short but all to horrible period where it meant something worse. That's not to say it's good, just that we often use words that aren't pleasant in reality without thinking twice, such as steal, clobber, etc.

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/

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 to defend usage of these terms by suggesting using them in anyway promotes awareness and helps the victims of slavery, is disgusting. That's clearly not the case and not the goal of those defending the usage of these terms.

> 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?

How about kill(2)? Why does the POSIX committee endorse murder?

"kill" as a term for the forcible cessation of life carries no baggage tying it to historical atrocities.

It can and is used to refer to deaths of stars, bacteria, plants, abstract concepts, and humans, without any connotation that these deaths carry equivalent moral weight.

genocide(2), on the other hand, would be in very poor taste.

Having few female contributors isn't a sign that Rust is anti female. It could just be that females aren't that interested in Rust, or perhaps more likely that there just aren't as many female developers.

Honestly of all the engineers I've worked with, I think less than 5% have been female.

It is unfortunate, and it is a good question to ask why Rust is attracting so few female contributors.

To assume when asking that question that the project is misogynist is a bit of a stretch, however. It's worth checking the project's policies and behaviors, to make sure it isn't doing anything that provides some kind of bias, but simply starting out by claiming that Rust is "anti-female" goes a bit far.

A few things that I can think of off the top of my head:

Some of the prominent contributions from women don't show up in the list of contributors because they are not directly to the compiler and standard library which are what are tracked in this contributor list, but rather to the broader ecosystem. Julia Evans has written some good blog posts on writing an OS in Rust, that have inspired other people in this space: http://jvns.ca/blog/2014/03/12/the-rust-os-story/. Emily Dunham does some excellent work on Rust infrastructure: http://edunham.net/2015/05/20/open_infrastructure.html There are of course many more that I'm not listing here, but the point is that the Rust community, and even the upstream project, consist of more than just the compiler and standard library, though those contributors are the ones that get credited in a release since that is what is being released.

Rust is still a nascent language; while it is starting to gain traction in the industry, it is not yet broadly adopted, and thus investing a lot of time and energy in joining the project is still a bit of a risk. People who have more social capital and more free time can afford to spend more of that on projects like Rust with a lot of potential but a higher amount of risk. Unfortunately, in our society men tend to have both more social capital, and more free time as domestic labor and child rearing is still seen as primarily women's work.

There are probably a large number of other factors at play. The Rust community that I have seen has been very supportive of women contributing, and has been doing a better job recently of outreach, but there is still probably more that can be done.

Can you provide any suggestions; any place you see the project structure, or contributors, being "anti-female", or any positive action that could be done to increase outreach or increase participation?

10% of the contributers are only known by username. It's not unreasonable to assume that those are disproportionally woman. The real gender ratio could be the same as the gender ratio of the industry overall.

In any case, with just 150 contributers it's hard to make any statistically significant statement.

I disagree. 152 is a large sample, enough to make statistically significant statements. "small" sample usually means less than 30.

If you are more gender-inclusive than me, I suggest you create a new open source project with these rules:

- Require all contributors to specify their gender; - Do not allow new contributions if they exceed gender quota for release.

Good luck.

I find it shocking that you assume gender based on name.

Not everything is a conspiracy.


"Rust goes out of its way to be modern and gender-inclusive."

And yet - epic fail.

What is the reason?

We've banned this account for trolling and breaking the site guidelines repeatedly.

There aren't enough brave people such as yourself to show the rest of the community The Path.

Or maybe the Rust community is doing its best and sometimes you don't see success even if you do.

> What is the reason?

Maybe men and women are different

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact