- 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?
Name:
Anonymous2015-04-24 18:11
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.
Name:
Anonymous2015-04-24 18:25
What is its analogue of the double type? Does it check any constraints on its use at run-time?
Name:
Anonymous2015-04-24 18:27
>>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.
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
Name:
Anonymous2015-04-24 18:49
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);
Name:
Anonymous2015-04-24 18:52
>>127 For comparison, in Haskell this would be just:
factory :: Int -> Int factory x = let num = 5 in x + num
answer = factory 1
Name:
Anonymous2015-04-24 18:57
Rust, with its focus on safety transmute allows for arbitrary casting, and is one of the most dangerous features of Rust!
Name:
Anonymous2015-04-24 19:05
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!
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?
Name:
Anonymous2015-04-24 19:17
>>133 Thanks for enlightening us in the ways of shitty bloated enterprise design patterns, c2-bot!
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
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.
>>145 That's a GreatIdea and I think we should do this.
Name:
Anonymous2015-08-09 4:33
Top reason not to use Rust: It's maintained by communist SJWs. It even has a CoC.
Name:
Anonymous2015-08-10 4:55
- 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
Name:
Anonymous2015-08-10 7:01
- You don't like the stupid name
Name:
Anonymous2015-08-11 5:45
rust my anus
Name:
Anonymous2015-08-11 6:17
- 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
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
Name:
Anonymous2015-08-13 18:15
>>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.
Name:
Anonymous2015-08-13 18:29
>>156 But an integer can be any size, so why limit your program by placing a range restriction on it?
Name:
Anonymous2015-08-13 20:30
>>157 For that, you need a separate big-int type, not a "default int type". You don't need arbitrary precision by default.
Name:
Anonymous2015-08-13 21:56
>>158 And how is it that you're such an expert on what I need?
Name:
Anonymous2015-08-14 0:19
>>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.