I recently wrote my first Rust  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.
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 opened an issue . I'll get on it.
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.
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'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.
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 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 :)
Edit: According to Steve Klabnik in his comment below, it is not up-to-date.
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.
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).
I'm quite pleased by the current solution and am not such a big fan of "?".
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.
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.
Very happy to see the tooling improvements, though. Great work!
That doesn't mean the _discussion_ about how it works has to stop in the meantime, though...
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 ?
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?
On top of that they have the financial backing of 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.
So, the basic process of compiling is:
source -> AST -> LLVM IR -> asm
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
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?
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 email@example.com:rust-lang/crates.io.git 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:
diff --git a/Cargo.toml b/Cargo.toml
index cf99b60..02e54fb 100644
@@ -5,6 +5,7 @@ version = "0.1.0"
opt-level = 2
+codegen-units = 4
name = "cargo_registry"
$ time multirust run nightly cargo build --release
# Single threades (default Cargo.toml):
git clone https://github.com/servo/servo servo.git
./mach build --release
time ./mach build --release
Build completed in 791.07s
And finally, a smaller project:
git clone https://github.com/Aaronepower/tokei.git
cargo build --release
$ time cargo build --release
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++.
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.
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 ?
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.
$ 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/
Or is this it? https://hub.docker.com/r/jimmycuadra/rust/
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.
- 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.
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.
Packages are of course preferable if available and up-to-date.
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
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.
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.
This is not humour, this is aggressive.
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.
> 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.
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.
But lets be honest, there are some attitude somewhere in the original comment, and I admire him being open.
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.
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.
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.
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.
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.
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.)
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.
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.
I'm just trying to be practical, not trying to force PC-think down anyone's throat.
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.
> "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.
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 agree that changing man is a little silly as it's obviously short for manual)
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.
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.
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.
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?
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.
Honestly of all the engineers I've worked with, I think less than 5% have been female.
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?
In any case, with just 150 contributers it's hard to make any statistically significant statement.
- Require all contributors to specify their gender;
- Do not allow new contributions if they exceed gender quota for release.
And yet - epic fail.
What is the reason?
Or maybe the Rust community is doing its best and sometimes you don't see success even if you do.
Maybe men and women are different