- 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-08 12:50
I don't care about this or any hipsterlang until they become stable and won't break backward compatibility. You can evangelize it all you want, it won't matter. C++ is not going away. A programmer doesn't see Rust as something valuable because of a single overhyped feature(only autists think a single "superior feature" is enough). Its a whole complex of features and libs available in Rust that will determine its future. When you talk to people as "retards who don't understand X" you probably lack the ability to articulate the advantages of X or overestimate the value of X. Try reading: http://c2.com/cgi/wiki?HowToSellGoldenHammers
Name:
Anonymous2015-04-08 13:39
You have to pretty strong to lift a golden hammer.
Name:
Anonymous2015-04-08 14:01
>>3 4th paragraph Don't Patronize - Don't be arrogant or talk down to people, such as "pearls before swine" or "real programmers get it" (even if you believe it true). Arrogance, even pride merely perceived as such, doesn't work. It puts them into a defensive battle mode instead of focusing on potentially helpful tools. They are no longer thinking in terms of tools but in terms of personal turf wars, and start using a different part of their brain.
Name:
Anonymous2015-04-08 14:06
- You like your security claims to be backed by something
Name:
Anonymous2015-04-08 14:54
Why not use a better language then? Ada comes to mind.
Name:
Anonymous2015-04-08 15:08
One word. The Forced Collection of the Garbage. Thread over.
>>15 I read it as "lol @ rustfags shilling and falling hard", now I feel embarrassed by it.
Name:
Anonymous2015-04-10 20:53
I always get a boner when I'm shilling.
Name:
Anonymous2015-04-11 9:21
I always get a boner when I'm shitting.
Name:
Anonymous2015-04-11 9:55
One of the coolest features of Rust is how it automatically manages resources for you, while still guaranteeing both safety (no segfaults) and high performance.
Because Rust is a different kind of programming language, it might be difficult to understand what I mean, so let me be perfectly clear:
In Rust, as in garbage collected languages, you never explicitly free memory In Rust, unlike in garbage collected languages, you never1 explicitly close or release resources like files, sockets and locks Rust achieves both of these features without runtime costs (garbage collection or reference counting), and without sacrificing safety.
>>21 Who cares about validation? Claims of security should always remain unchecked, unlike these sweet dubs.
Name:
Anonymous2015-04-11 23:55
>>21 Most popular programming languages have no such specification. The few that do did not have them from the outset. Standardization is most effective at codifying existing practice, not at trying to anticipate it.
Most popular programming languages have no such specification
everyone else is shit so it's ok that rust is too
no
Standardization is most effective at codifying existing practice
the purpose of a language specification is so that you can understand what programs are valid and what they mean. Without this we have to go by intuition, extrapolating from other languages and tutorials, running the code to 'try it and see' etc. This is beyond ridiculous for a "systems programming language" especially one that is probably going to become the go-to language for security critical software - by defending the lack of spec. and worse proofs of the safety properties that they claim.. then you're asking for rust to collapse in on itself and become the next PHP rather than something better and it has potential.
Name:
Anonymous2015-04-12 2:58
>>25 The Rust implementation is open source. Because of this it is absolutely possible to know what a piece of code does without relying on human interpretation.
No one has ever produced a widely useful language in the way you are proposing.
>>26 The GCC implementation is open source. Because of this it is absolutely possible to know what a piece of code does without relying on human interpretation.
>>29 The 28th Post implementation is open source. Because of this it is absolutely possible to know what a piece of text does without relying on human interpretation.
>>30 This doesn't make any sense. Do you think you're being clever. You aren't.
Name:
Anonymous2015-04-12 7:27
>>31 The failure is the opensource==safe+obvious reasoning The (Rust,C,C++,Brainfuck,Unlambda,Malbolge) implementation is open source. Because of this it is absolutely possible to know what a piece of code does without relying on human interpretation.
Name:
Anonymous2015-04-12 7:39
Stop piping your posts through a one way function!
Name:
Anonymous2015-04-12 7:50
>>33 The reasoning X is A doesn't lead to X is B, because A doesn't lead to B.
>>36 Ok. Now how is this statement related to >>26?
Name:
Anonymous2015-04-12 8:37
>>37 Its a condensed form of >>26 The Rust implementation is open source. Because of this it is absolutely possible to know what a piece of code does without relying on human interpretation.
Name:
Anonymous2015-04-12 9:17
>>38 But the implementation can change arbitrarily and without warning, obviously. The NSA can always sneak a couple of backdoors in if they feel the language threatens their power.
Name:
Anonymous2015-04-12 9:32
>>39 If security means "lack of obvious backdoors" you're terribly misguided. Security means the code is proven secure(e.g. CompCert , Ada Spark). Have "open-source" C code that "sorta does what it claims to do" is not a form of security. Open source doesn't make the code secure.
Name:
Anonymous2015-04-12 9:57
>>40 It is you who is misguided. Security does mean lack of backdoors. What you are talking about, on the other hand, is correctness, or, more precisely, the formal verification of correctness.
Name:
Anonymous2015-04-12 10:04
>>41 "Security does mean lack of backdoors." Software with exploits, buffer overflows, data corruption and crashes every time it get a bad packet is now secure. (/prog/ security experts , 2015)
Name:
Anonymous2015-04-12 10:06
>>42 With exploits? No. Otherwise, yeah, it would be secure. In fact, most of the software considered secure today is chock-full of data corruption, crashes, glitches etc, exactly because people care more about security than they care about correctness.
Application security (short: AppSec) encompasses measures taken throughout the code's life-cycle to prevent gaps in the security policy of an application or the underlying system (vulnerabilities) through flaws in the design, development, deployment, upgrade, or maintenance of the application.
Name:
Anonymous2015-04-12 10:39
>>45 So? Flaws in the design== incorrect design==insecure app
flaws in the design, development, deployment, upgrade, or maintenance of the application.
Name:
Anonymous2015-04-12 10:50
Also don't forget physical security: if key developers aren't anonymous and don't use tor/i2p they could be easily assassinated by CIA(C Implementation Agency) and the programmers will switch back to C.
Name:
Anonymous2015-04-12 10:50
Also don't forget physical security: if key developers aren't anonymous and don't use tor/i2p they could be easily assassinated by CIA(C Implementation Agency) and the programmers will switch back to C.
Name:
Anonymous2015-04-12 10:55
>>46 Not all design flaws are a threat to security. Your == signs are ill-placed.
>>47 Why murder the devs when you can force them to plant backdoors into the implementation and then exploit those backdoors to your great profit?
Name:
Anonymous2015-04-12 11:06
Rust leverages core developer skillsets and world-class team synergy through Github to provide programmers worldwide with robust, scalable, modern turnkey implementations of flexible, memory-safe, cutting edge ownership-based compile-time systems programming stack of algorithmic architectures that accelerate response to theoretic and real-world security demands and reliably adapt to evolving software needs, seamlessly and efficiently integrating and synchronizing with their existing legacy codebases, enhancing the debugging capabilities of their code production environments across the enterprise while giving them a critical competitive advantage and taking them to the next level.
Name:
Anonymous2015-04-12 11:14
>>49 1. They are a threat to quality. Saying its "its open source"=="its secure" is actually "if its broken, fix it yourself". 2.backdoors can be noticed by outsiders.
Name:
Anonymous2015-04-12 11:20
>>51 1. Quality has no relation to security. You can have a totally secure program with no quality, e.g. any "hello world" program.
2. Like in OpenSSL, right?
Name:
Anonymous2015-04-12 11:26
>>52 Hello World is a quality program in theory: it does what it designed to do, doesn't crash or leak memory, doesn't connect to random servers in china every day and is inherently stable due no external dependencies...wait a moment... if libc is compromised, this isn't the case. Printf/Puts could be sending your bank data to russian botnets right now. Unless you control the entire stack "Hello world" is as secure as trojan.exe.
Name:
Anonymous2015-04-12 11:38
The only way to safety is to create a proven hypervisor program, inside which a proven secure OS(without any access to hypervisor) running a proven secure Virtual Machine(which has zero access to the OS) inside another Virtual Machine with different proven secure codebase(which has restricted access to the OS). Load this from a USB stick and save data into another USB stick(encrypted of course). Now you can claim security of the entire stack...and then your Intel CPU receives a specific Wifi signal...
Name:
copy pasted blogshit2015-04-12 13:19
>>54 this offers nothing but an illusion of security theatre, that is, until the formal prover that you use has been formally proven to be correct (on a formally proved secure OS). Therefore by godels theorem all software is not only insecure but impossible to prove secure. The conclusion is that we should give up and use rust even though it has no specification and no is able to prove things like memory safety that keeps being claimed about it.
Name:
Anonymous2015-04-12 13:20
>>55 The conclusion is that we should give up and use PHP even though it has no specification and is not able to prove things like memory safety which it nevertheless has.
Name:
Anonymous2015-04-12 13:39
>>55 Rust claimed "safety" is bullshit, but thats not a reason NOT to use it, its just unstable hipster lang which could mutate in a week.
Name:
Anonymous2015-04-12 13:39
>>55 Rust claimed "safety" is bullshit, but thats not a reason NOT to use it, its just unstable hipster lang which could mutate in a week.
>>60 Oh. You're an idiot, then. Haskell has no formal specification either, which doesn't prevent it from being one of the most secure and safe languages.
Name:
Anonymous2015-04-12 14:40
>>61 Have you read the sources of your 'Haskell'? Its runtime is bunch of horrible, cludgy C that hasn't even been audited or seen any "verification" in years.
>>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.
Name:
Anonymous2015-04-12 20:16
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++.
>>74 I never understood what tabs are or what they're good for. I always use spaces.
Name:
Anonymous2015-04-15 10:36
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.
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.
Name:
Anonymous2015-04-15 10:52
Smash imperative loop patriarchy, use functional composition.
Name:
Anonymous2015-04-15 10:52
>>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.
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.
Name:
Anonymous2015-04-15 16:50
>>83 If you were truely smart, you'd hire taller stockboys.
>>84 Holy shit that's a good idea. I go fire all my current stockboys and hire new ones. Thanks!
Name:
Anonymous2015-04-15 17:56
>>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.
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.
>>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 like using programming languages that actually make working on the BSDs a priority.
Name:
Anonymous2015-04-20 4:03
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 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.
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:
(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.
Name:
Anonymous2015-04-20 7:46
I don't care if the syntax is ruined. It's still the most promising language out there.
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
Name:
Anonymous2015-04-20 14:08
>>109 I wouldn't go that far but it is the most promising/important new language in the industrial space.
Name:
Anonymous2015-04-20 14:08
420 blaze it
Name:
Anonymous2015-04-20 14:24
>>26-46 Golden discussion. I hereby grant it a place in the hall of fame.
Unlike some other languages, this means that Rust’s char is not a single byte, but four.
Name:
Anonymous2015-04-24 18:08
The N is a compile-time constant, for the length of the array. array access is bounds-checked at run-time
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.
