Reasons not to use Rust

- You think programming languages should be closed and proprietary
- You like random pauses caused by forced collection of the garbage
- You think program start-up should take minutes so you use stupid VM-languages instead
- You like broken features and memory corruption
- You sell hardware and want to deploy inefficient scripting languages only to sell more
- You only do pure programs that don't interact with the world
- You are a retard who doesn't understand the concept of ownership

Anything else?

Smash imperative loop patriarchy, use functional composition.

>>80
By the end of it what's left to implement? Also I don't understand how they expect any work to be done when the tools keep getting more and more complex.

>>80

Experienced programmers are too stupid to be trusted implementing for loops.

that is so fucking dumb...

imagine you're stacking shelves do you

a) stack them correctly with a step ladder that makes it easy
b) just do it in a really stupid dangerous way e.g. standing on a swivel chair that might fall

you seem to think (b) is "cooler" or more macho - that's just fucking retarded. You need to do every single thing you possibly can to try to make your programming less buggy.

>>83
If you were truely smart, you'd hire taller stockboys.

>>84
Holy shit are you one dumb fucking nigger

>>84
Holy shit that's a good idea. I go fire all my current stockboys and hire new ones. Thanks!

>>80
Rust is just codifying what C programmers already do in practice. Approximately 95% of the loops people write are idiomatic ones that sweep the induction variable with a constant step over a fixed range with no dependencies between iteration steps. The other 5% have bugs. Every time I read a loop that doesn't match the idiom it is a big red flag.

If you are really doing something tricky in Rust you will be clever enough to use a while loop instead. And, since tricky cases are the only cases to prefer a while loop in Rust, anyone who reads code that uses one will immediately see that there is funny business at work.

>>85
make yourself taller

>>88
that joke was already made

>>89
But if you were taller you could reach without a chair, ammirite?

>>87
But there's no difference to non-sweeping for loops created using while, except that actual for loops are neater and easier to read.

>>91
And by "non-sweeping" I'm including simple ones like

for(i = 1; i < 1000; i += 2){
//loop body
}

Which expands out to a nasty

i = 1;
while(i < 1000){
//loop body
i += 2;
}

>>80

And here I thought Python's ``developers are too stupid to format their code or press ctrl-shift-f in their IDE to clean up messy code'' mentality was the worst.

This isn't a problem. There are ~infinity ways to represent what you want to loop over in Rust and you can plug most of them into for.

If you want to complain about not trusting the users, just look for evidence of their policy against implementing anything that was a good idea in Haskell. The core devs seem to hate the fact that, yes, actually, you do need to have monads in Rust (Result, Option.)

But even with their thought-policing, the Rust project comes nowhere near Python's self-sabotage for the sake of meaningless dogma.

>>92
U MENA range_step

Oh they renamed it because people are fucking idiots: http://doc.rust-lang.org/std/?search=range_step

>>93,http://doc.rust-lang.org/std/?search=range_step

handles overflow by stopping

Fucking seriously?

>>94
You want it to keep yielding numbers forever if it never yields the stop value?

My bad, they actually check for numeric overflow:

match self.state.checked_add(self.step) {
Some(x) => self.state = x,
None => self.done = true
}

My question still stands though.

>>95
No, I want it to elide the check totally if the ranges are known at compile time and bail out without doing anything at run time if they aren't.

Branch is the most beautiful and elegant way to make loops, say no to goto shamers.

self.state.checked_add(self.dubs)

💯

>>94
Whom are you quoting?

💉💊💉💊💉💊💉💊💉💊💉

- Bceause there's no formal model of the type system and no proof that its sound

* https://github.com/rust-lang/rust/issues/24292

>>97
Assuming the optimizer doesn't already do that, it's just not going to happen unless you can write the optimization pass in the type system and get your PR accepted.

You could do it in a macro though.

>>1

You like using programming languages that actually make working on the BSDs a priority.

fn main() {
let mut x = 5;
let y = &mut x;
x = 1;
}
This causes an error.
For some bizarre reason they won't allow you to have two ways to access one variable, even if both are marked mutable.
Since you created a pointer to the variable you're only allowed to access the variable through that pointer from now on.
What the fuck were the devs snorting?

>>106 "Safety"

>>106
It's to prevent aliasing, but unlike restrict it actually works: it's safe, amenable to optimization and won't trigger UB. And it's there all the time.

fn main() {
let mut x = 5;
{ let y = &mut x; }
x = 1;
}
_{http://is.gd/4aPFlB}

The above is legal. y doesn't alias x during the final assignment because its borrow ends with the parent block.

fn whatever() {
let mut x = 5;
let y = &mut x;
send_to_another_thread(y); // give away y
do_something_with(x); // <- wrong
}

The above code is incorrect in any language if both functions use their argument and either might write to their argument.

The ergonomics aren't even that bad. If you fork-join, you can still get back the pointer you gave away without it getting verbose:

fn sum_tree(tree: &Tree) -> uint {
let mut left_sum = 0;
let mut right_sum = 0;

parallel::execute([
|| left_sum = sum_opt_tree(&tree.left),
|| right_sum = sum_opt_tree(&tree.right),
]);

left_sum + right_sum + tree.val
}
_{http://smallcultfollowing.com/babysteps/blog/2013/06/11/data-parallelism-in-rust/}

See that? left_sum and right_sum were moved out of the current thread but we got them back implicitly without having to ask for them. We didn't have to write types in the closure, nor even lifetimes.

This is why Rust was made for, and it's good at it. It throws raw pointers at threads and gets them back when it needs them. But it never stomps on them. As a result, Servo is the only layout engine to successfully parallelize layout anywhere near as well as it does:

http://i.imgur.com/23Snav3.png
https://cloud.githubusercontent.com/assets/28357/6275199/7bd6e788-b83a-11e4-89cb-a74f360272f2.png

(Different colors = different threads. The first one is newer.)

They weren't willing to try this in C++ because they felt they needed to throw raw pointers around for speed, but aliasing was too dangerous (and likely) in C++. So Graydon dreamed up Rust and they quickly set to ruining its syntax just prior to bootstrapping it so they can court the C++ users.

I don't care if the syntax is ruined. It's still the most promising language out there.

>>106
the language is loosely based on the idea of regions as developed by http://cyclone.thelanguage.org/

except with the difference that
* there is no mathematical model for it, they're just riding by the seats of their pants hoping its all going to be "safe" despite memory safety bugs constantly occuring
* they market the fuck out of it so even though it's inferior to what cyclone did decades ago it's GOING to become the standard that everyone uses

>>109
I wouldn't go that far but it is the most promising/important new language in the industrial space.

420 blaze it

>>26-46
Golden discussion. I hereby grant it a place in the hall of fame.

114 posts already, wow

>>111
Nice trips.

>>115
Thank you for noticing, the 111st post is the 11st dubs and the 1st trips. They are nice trips indeed!

>>116

Veeeery nice.

I have found another reason not to use Rust:

let y = "Hello".to_string();

"Hello".to_string()
"Hello"
.to_string()

http://doc.rust-lang.org/nightly/book/trait-objects.html

Unlike some other languages, this means that Rust’s char is not a single byte, but four.

The N is a compile-time constant, for the length of the array.
array access is bounds-checked at run-time