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?

>>62
The same could be said about Rust. I don't see any verification or theorem prover mention in their shilling efforts.

The problem is fixable. Go through the Rust source. Prove that it is correct. Since you seem so concerned, why don't you do it >>64-kun?

>>61
>>62

bringing haskell into this

nice diversion tactics, shill

>>65
Thank you. My point is that having source allows a security audit to be performed if one is desired.

If what you really want is a formally verified language, all I can say is good luck with that. The process is simply too slow to practically replace existing languages like C or C++ that were never held to that standard. Merely eliminating a few of the foremost sources of bugs in those languages is a big enough win to justify Rust's existence.

a big enough win to justify Rust's existence.

But not big enough to switch. I'd check it at v2.0 to see how they fare against C++.

>>66
Kill yourself 「下さい」

People keep posting this shit to the Rust subreddit and it makes me laugh every time.

They'll never understand the meepings of /prog/lodytes, they can't even tell us apart from 4chan!

>>69
바보 일본어를 기쁘게 자신을 죽이고

KOREA WAS HERE, JAPAN IS LOSER

>>71,72
kekekekeke

There are a number of details that are important here. The first is that it's indented with four spaces, not tabs.

From: http://doc.rust-lang.org/1.0.0-beta/book/hello-world.html

Wait, does this mean Rust has FIOC?
Why does it matter if tabs are used instead of spaces?
And what kind of animal indents with spaces?

>>74
Tabs are inconsistent across platforms.

>>75
Yeah, for instance Windows uses 4 spaces for tabs while Linux uses 8.

Reason not to use Rust: There is no dubs checking function in standard library.

>>75
And?

>>74
I never understood what tabs are or what they're good for. I always use spaces.

Rust does not have the "C-style" for loop on purpose. Manually controlling each element of the loop is complicated and error prone, even for experienced C developers.

http://doc.rust-lang.org/1.0.0-beta/book/looping.html

Experienced programmers are too stupid to be trusted implementing for loops.
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.

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

Rust does not have the “C-style” for loop on purpose. Manually controlling each element of the loop is complicated and error prone, even for experienced C developers.

What is its analogue of the double type? Does it check any constraints on its use at run-time?

>>119
I fail to see the problem. As long as they don't pull a HASKAL and use UTF-32 strings, this is the correct way to handle characters.

std::f64::consts::PI

>>120
"zero cost abstraction" :^)

Rust doesn’t have method overloading, named arguments, or variable arguments. We employ the builder pattern instead.
builder pattern
pattern

ENTERPRISE-GRADE SCALABLE TURNKEY LANGUAGE

If you try to return a closure, you may run into an error
This gives us these long, related errors
So we’d write this:
But we get another error
Right. Because we have a reference, we need to give it a lifetime
But we get another error
So what to do? This almost works
There’s just one last problem
With one last fix, we can make this work:

fn factory() -> Box<Fn(i32) -> i32> {
let num = 5;

Box::new(move |x| x + num)
}
let f = factory();

let answer = f(1);
assert_eq!(6, answer);

>>127
For comparison, in Haskell this would be just:

factory :: Int -> Int
factory x = let num = 5 in x + num

answer = factory 1

Rust, with its focus on safety
transmute allows for arbitrary casting, and is one of the most dangerous features of Rust!

If Rust’s macro system can’t do what you need, you may want to write a compiler plugin instead. Compared to macro_rules! macros, this is significantly more work, the interfaces are much less stable, and bugs can be much harder to track down
Syntax extension plugins are sometimes called ‘procedural macros’ for this reason.

Hooray for no reader macros! Enjoy writing compiler plugins, everyone!

Does rust have branch or jump tables

a_slice.iter().zip(b_slice.iter())

No multimethods for you!

>>126,132
http://c2.com/cgi/wiki?BuilderPattern

Also it is not possible in stable Rust to destructure a Box in a match pattern
The unstable box keyword can be used to both create and destructure a Box

So not only safe vs. unsafe Rust, but also stable vs. unstable Rust?

>>133
Thanks for enlightening us in the ways of shitty bloated enterprise design patterns, c2-bot!

>>133
EPIC C2 MEME CODING BRO XDDDD

>>133

A Builder can be one of implementations of the AbstractFactory
Sounds like we should have more of a LaborerPattern
Isn't this "undo"-enabling behavior the focus of MementoPattern

Pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern ;attern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern pattern

Expert programmers are so good they don't even need to think. They just apply one of a fixed set of design patterns that they've been programmed to know.

In any situation, an Expert Programmer needs only to choose the appropriate pattern.

Truly Expert.

Ironically http://c2.com/cgi/wiki?OldCodeRusts in Rust

>>138
The http://c2.com/cgi/wiki?BestPractice
of http://c2.com/cgi/wiki?SoftwareManagementPrinciples
for enterprise http://c2.com/cgi/wiki?SoftwareProcess
are http://c2.com/cgi/wiki?IntentionNotAlgorithm
and not http://c2.com/cgi/wiki?ExtremeHacking
First we apply world-class http://c2.com/cgi/wiki?BusinessObjectNotation to http://c2.com/cgi/wiki?BusinessLogicDefinition
to derive optimal http://c2.com/cgi/wiki?ArchitecturalPattern
to select http://c2.com/cgi/wiki?DesignPatterns
which would leverage http://c2.com/cgi/wiki?ArmyOfProgrammers
assigned to http://c2.com/cgi/wiki?CodeGeneration with http://c2.com/cgi/wiki?CodeOwnership
relying on http://c2.com/cgi/wiki?AgileArchitecture
which combines http://c2.com/cgi/wiki?KnowledgeAndSkill
to create http://c2.com/cgi/wiki?FlexibleAndExtensible
http://c2.com/cgi/wiki?DistributionOfComponents
which would allow for each http://c2.com/cgi/wiki?GruntProgrammer
http://c2.com/cgi/wiki?ComingUpToSpeed
with the relevant http://c2.com/cgi/wiki?SoftwareFramework
to http://c2.com/cgi/wiki?DiscoverDefectsEarly
since http://c2.com/cgi/wiki?PrinciplesOfSoftwareEngineeringManagement
remind us that http://c2.com/cgi/wiki?QualityAssuranceIsNotQualityControl
with http://c2.com/cgi/wiki?RelentlessTesting
striving towards http://c2.com/cgi/wiki?BugFreeSoftware
enabling a http://c2.com/cgi/wiki?CriticalSuccessFactor
in http://c2.com/cgi/wiki?SystemsDevelopmentLifeCycle

>>139,140
Please ban this spamming memelord.

>>141
You mean reduce the board population by 50%?

I'm a memelord. I'm a lord of memes.

dubs

What if ProgRider adopted the CamelCase LinkingConvention from CeeTwo?

>>140
Ahhhhhh!
Ahhhhhhhhh!
Ahhhh!

looks like it's... rusted shut :)

>>145
That's a GreatIdea and I think we should do this.

Top reason not to use Rust: It's maintained by communist SJWs. It even has a CoC.

- HKTs and/or inheritance.
- Built-in FFI support for C and C++. Bindings don't count.
- Commercially successful and robust operating system.
- Tools for devs. (Also, cargo has potential, but crates.io is terrible. Global package names and dependency hell.)
- Lose the rainbow docs with the dispropriate font sizes and awkward line spacing
- Custom allocators
- Improved semantics for writing _Abstract_ Data Types

- You don't like the stupid name

rust my anus

- No default int type
- No default string type (ie. confusion about &str vs String)
- No inheritance, which the Servo devs themselves have said is a major problem
- Immutability by default is both nonsensical and overly verbose for low-level code
- The language is overly opinionated about how memory management should work
- The language is overly opinionated about how you should name your variables
- Type inference quickly collapses into chaos in functions where a lot of bindings are introduced
- It's 2015 and we haven't figured out how to get rid of the :: syntax

>>153
Good list.

no one has mentioned the fact that there is no formal model? they're just hacking and hoping the type system is valid without any proofs

>>153
What the hell is a "default int type"? A type whose size could be anything from 1 to 128 bit and you can't be sure of anything? You are an idiot.

No inheritance, which the Servo devs themselves have said is a major problem

Well, they were wrong. No inheritance is a big plus.

>>156
But an integer can be any size, so why limit your program by placing a range restriction on it?

>>157
For that, you need a separate big-int type, not a "default int type". You don't need arbitrary precision by default.

>>158
And how is it that you're such an expert on what I need?

>>159
He probably means the generic, plural, you. The type will be bound by the multiples of byte anyways so choosing the correct multiple, or better yet, specifying a range for what you need and letting the compiler assign the best storage, are much more performant solutions than having base types of dynamic size.

>>160
We are not generic!

>>161
Shalom, Hymie!

test test