This is the language of the future, r-r-rite (atleast for system programming)?

Because they lack the discipline or brainpower to manage lifetimes, boxes, traits and affine typing properly, or to seriously think about how software should be architected so that playing pointer hot potato can be avoided, and deep down, they know it.

inb4 "b-b-but muh linter is just as good as having a type system that proves semantic properties syntactically that are undecidable in my language!"

Are you mentally challenged? Did you not understand the part where I stated that there is a tool that statically checks for unsafe C code?

lol

linux vulnerability #929942 disagrees

Slightly better syntax for sum types (vs tagged unions), and arguably better macros/compile time abstractions.

Retard

>linux vulnerability #929942
Come back with a real one.

firefox vulnerability #102491925

Not trying to whiteknight the Rust meme, but I can't believe you seriously typed this.

kek literally 53 seconds after I inb4'd:
This challenge is spurious. Your C linter will never be sound (catch all errors) because unless your type system is designed to match syntactic and semantic behavior (as is the case w/ Rust), the safety properties aren't decidable.

From a minute of Googling your Splint tool's white paper:
cs.virginia.edu/~evans/pubs/ieeesoftware.pdf
>Detecting likely vulnerabilities in real pro-
grams depends on making compromises that
increase the class of properties that can be
checked while sacrificing soundness and
completeness. This means that our checker
will sometimes generate false warnings and
sometimes miss real problems, but our goal
is to create a tool that produces useful results
for real programs with a reasonable effort.

So its creators agree with me. The only way to actually make C as safe as Rust is to write proofs in a separation logic like Frama-C, which is a fuckload more work than just using Rust, and I already know none of the C-tards ITT will ever do it.

Also sorry for the shit spacing on the whitepaper quote, but I think I made my point.

I just have to say, you are making it painfully obvious that you don't know what decidability is, or how it relates to the discussion at hand. Pro tip: memory safety is just as undecidable in (safe) Rust as it is in C.

> Pro tip: memory safety is just as undecidable in (safe) Rust as it is in C.
Kek. No, it fucking is not. You missed the whole point.

There is a procedure to decide memory safety for (safe) Rust. It's implemented in the compiler. Therefore (safe) Rust has decidable memory safety (namely, if it compile's, it's safe). It's a sound overapproximation of all memory-correct (unsafe) Rust programs, which like memory-correct C programs is not a decidable set.

>procedure to decide
>overapproximation
If it overapproximates then it's not a decision procedure. Please learn what words mean before opening your mouth.

Yes

Jesus Christ. Look.

Freedom from bad pointer dereferences is not decidable in any language with pointer arithmetic. The proof is really standard. Suppose some program P decides this. The program C will be a counterexample. Run P on an encoding of C. If it returns true (is memory safe), then C dereferences a null pointer (the zero value); otherwise, C just returns (and introduces no bad pointer dereferences).

With me so far? If you don't believe me, notice bad dereference freedom is a non-trivial semantic property and the result follows from Rice's Theorem. This is true in ANY language with pointer arithmetic and arbitrary dereferences.

Now note that memory SAFETY (of Rust's kind) is a sound overapproximation of memory CORRECTNESS. Every Safe Rust program is free of memory problems, as are a few unsafe ones. Moreover, membership of a program in the language of Safe Rust IS decidable (the decision procedure is the compiler finishing compilation without errors). Safe Rust programs are a strict subset of correct Unsafe Rust programs (proof: just wrap every safe Rust program with unsafe blocks). This must be the case; otherwise we could decide memory correctness. The only thing that remains to be shown is every Safe Rust program is memory correct. The gist is you prove a progress and preservation theorem (of the kind given in Robert Harper's Practical Foundations of Programming Languages) for Rust's sub-structural type system. Because Rust is complex, a full proof is a big undertaking, but this is essentially what RustBelt amounts to (with some logical relations over syntactic forms and standard theorems about affine types).

I cannot be clearer than I have, but maybe this is a lost cause. I can't believe a Dunning-Kruger case got me to write a few proof sketches.

C is a simple lang- #define ICE_P(x) (sizeof(int) == sizeof(*(1 ? ((void*)((x) * 0l)) : (int*)1)))

>memory SAFETY vs memory CORRECTNESS
This is a distinction that you literally just made up.
And yeah, if you redefine "P is memory safe" as "P is accepted by (a model of) Rust's borrow checker", then of course the Rust compiler is (modulo implementation bugs) a decision procedure for memory safety.

All Rust-safe programs are memory safe, modulo implementation bugs. Not all memory safe rust programs are Rust-safe.

Rust's safety concept is more restrictive because it deals with more than just memory, it's generally applicable to concurrency problems and eliminating racing conditions in general.

>This is a distinction that you literally just made up.
Call "memory correctness" whatever the fuck you want---np undefined behavior from dereference, no segfaults, etc. I'm really not attached to the phrase. It's a thing that Rust prevents, and if you don't recognize it, you don't know C either.
>And yeah, if you redefine "P is memory safe" as "P is accepted by (a model of) Rust's borrow checker", then of course the Rust compiler is (modulo implementation bugs) a decision procedure for memory safety.
Right, which solves a billion-dollar problem because no safe Rust program causes segfaults. So was a sequence of proof sketches needed to see my point, or were you being obtuse on purpose?

**NO undefined behavior from dereferences...

>Rust's safety concept is more restrictive because it deals with more than just memory, it's generally applicable to concurrency problems and eliminating racing conditions in general.
Also this, if my race condition you mean data races. Data race C-tards BTFO.

>So was a sequence of proof sketches needed to see my point
No, of course not. The most valuable part of that post was when you revealed that you're using a wildly non-standard definition of "memory safety". I think we agree on everything else.

This, ironically it's never been memory leaks that I've had problems with in the past, it's always been specifications mismatch.

Rust is for retards

>I've never maintained a ~100k line codebase in a language with pointers and therefore have never encountered one safety flaw.
Okay. Stick with C. We don't necessarily need you.

Why use an R for their logo when there is already a language called R?

No, this is the language of the past that we wished was around.

This is the language you refer to when you say "There's gotta be a better way to do it."

The great Problem of rust is its community which was toxic sjws from the start. I mean, just look at the responses to those who want to defend C. There's still a lot of C programming out there and programmers won't switch to rust because someone tells them they use a bad programming language and bla bla. Yes, rust may be the better language but it definitely doesn't have an open-minded community. Its more comparable to functional language's community where everyone is shilling for software that can be statically proven correct...

That's cute, I actively juggling between two code bases at work that are in the multiple of hundreds of thousands of lines of code, the majority of it being automatically generated.

But yeah what I really need is memory management because I'm a retard like your average Rust homosexual. (NOT)

If I had things my way, if you can't prove your code works (I mean mathematically) you shouldn't be anywhere near a computer.

unironically this

I've taken an interest in rust over the past couple of years simply because of the safety guarantees without compromising performance. I started writing a text editor in rust to try and become more proficient, but the better I became the less appealing the language was. The syntax feels really over-encumbered in it's safety bullshit. Eventually I lost interest in learning it because I started doubting rust's ability to replace C as a serious systems-level programming language. It's simply a tedious syntax, and all for the sake of hand-holding for bad programmers.
Now I'm not saying C++ doesn't have a tedious syntax, but it's definitely less so, plus generally more familiar to most people (like those who have used Java, Javascript, C, etc.). And yes, it can be unsafe - if you're fucking stupid about how you use it. Any C++ programmer with the tiniest amount of experience and half a brain will know how to abstract ‘new’ and ‘delete’ calls with RAII, or use thread-safe data structures to pass information between threads. It's hardly brain surgery, but people still manage to fuck it up time and time again. Why? Because people are fucking stupid.

Attached: rust_in_a_nutshell.png (500x700, 85K)

Keeping that in mind, consider this:
1. One of the first things you learn in C++ is ‘new’ and ‘delete’ are evil. They can royally fuck you over. Only use them if you have to, and even then abstract them through a safe interface.
2. One of the first things you learn in rust is ‘unsafe’ is evil. It can royally fuck you over. Only use it if you have to, and even then abstract it through an safe interface.
Woah! It’s almost as if the kind of person who is going to fuck up ‘new’ and ‘delete’ in C++ is also going to fuck up ‘unsafe’ blocks in rust. And if you’ve ever imported a crate in rust, you’ll know that unsafe blocks aren’t uncommon, apparently because many programmers would rather just quickly write something in an ‘unsafe’ block that just works instead of wrestling their safe logic through the compiler.

In addition I’d like to point out that the C++ programmer who can’t use ‘new’ and ‘delete’ without blowing their leg off probably isn’t so great at programming altogether, and is probably going to introduce simple logic-based bugs whether they’re using C or fucking python.
Having said all that, C++ is inelegant and bloated. It's only where it's at today because it's fast, it's (mostly) a superset of C, and there's a C++ library for just about everything. Anyone who claims to like C++ for the language itself doesn't know it very well or has a very bad case of Stockholm syndrome. It’s why everyone’s always on their toes about a C++ killer coming along to swoop in and save them from it, and why people keep trying to make it happen. The bitter truth is that it'll stay where it is for a very long time because it's not *quite* bad enough for organizations to bother migrating away from it, not unlike how Unix wasn’t/isn’t quite bad enough for organizations to bother migrating to Plan9. And not unlike Unix-y systems getting stuffed with Plan9 features like the /proc/ filesystem, C++ is being drip fed features from almost every other language.

tldr; all systems languages are kind of shitty in their own ways, people are stupid and will fuck up programming regardless of the language, and you should just use whatever you can tolerate, pays well, and works for the task at hand.

I agree, also rust simply doesn't have the tooling for systems programming. Everything for microcontrollers is written in C or C++

>In addition I’d like to point out that the C++ programmer who can’t use ‘new’ and ‘delete’ without blowing their leg off probably isn’t so great at programming altogether, and is probably going to introduce simple logic-based bugs whether they’re using C or fucking python.
C++ makes it astonishingly easy to introduce bugs of this kind even if you're a decent programmer. For example:
void foo()
{
Obj *ptr = new Obj;
ptr->doWhatever();
delete ptr;
}
If an exception is thrown, you have a memory leak. How about this?
Obj *ptr = new Obj[n];
ptr[2].doWhatever();
delete ptr;
Oops, undefined behavior.

new/delete in C++ is garbage,regardless of how good a programmer you are.

OH NONONONONONONO

Not really, but it has potential.

Same thing can be said to literally every language in comparison to asm.

Did you had any experience with Rust community at all? Can you share any story?
I was on their IRC few times, and I never experienced anything like that. Everyone just focus on rust and programming and they were very helpful when I asked some questions.

Except Rust is not all about RAII. RAII surely is useful in any language, but Rust also prevents you from much more dangers than any safe C++ interface can do. And it doesn't have that huge ugly legacy, no &&, has cargo which makes it much easier to install new libraries than in C++, no constructors, no slow exceptions, compiler plugins and much more.

RAII is a crappy idiom and more of a hindrance than anything.

How is it hindrance? Does anyone forces you to use RAII?
Also what do you suggest instead.

>"Rust is better than C++! Watch how easily I can deliberately fail at writing C++"
>*writes awful C++ code sample*
>"See!?"
I really wish every rust pros-and-cons thread wouldn't boil down to this, but it does every time without fail. Where's that image of the rust programmer jamming a pipe in his bike wheel?

I'm not defending Rust, I'm criticizing C++. new/delete was supposed to simplify your code by combining malloc with initialization, but only introduced more asinine rules and pitfalls.

I think you skimmed over the bit about abstracting 'new' and 'delete' through safe interfaces rather than using them directly (not unlike 'unsafe' in rust).
Alternatively smart pointers exist (although I'm not a huge fan).
Also 'noexcept' is a thing.

>How is it hindrance?
severely damages the intelligibility of your code by inserting invisible function calls at the beginning and end of every scope. This is not appropriate for systems programming e.g. on a microcontroller.
In C++ you become dependent on constructors and the exceptions they throw to report errors, which is inefficient and further damages the predictability of your code by making its behavior dependent on nonlocal information. In Rust you become dependent on inefficient static methods instead. In both languages it becomes impossible to directly handle any errors that might arise in a destructor.

> Does anyone forces you to use RAII?
In Rust, yes. If you're using anything from a C++ library, pretty much.

>Also what do you suggest instead.
init/close always worked fine. Constructors are simply init functions that are crippled in that they cannot return an error code - destructors are further crippled in that they can't throw an exception either. Code is more easily understood when all the relevant concerns are made explicit.

If you really need some scope guard mechanism, something like defer is probably better suited.

>I think you skimmed over the bit about abstracting 'new' and 'delete' through safe interfaces rather than using them directly (not unlike 'unsafe' in rust).
What do you mean by this if not smart pointers?

>program fighter jet soft with rust
>the plane does random shit because muh feelings

it's meme-tier at best

Attached: rustorbust.jpg (638x479, 62K)

>severely damages the intelligibility of your code by inserting invisible function calls at the beginning and end of every scope. This is not appropriate for systems programming e.g. on a microcontroller.
How so? Code written using RAII is much cleaner and easier to read than code using malloc and frees.

>In Rust you become dependent on inefficient static methods instead.
What is inefficient in static methods? How would you want to construct an object/struct if not make a function for it. Copying initializing code every place you want to create it doesn't sound like sane idea.

>In both languages it becomes impossible to directly handle any errors that might arise in a destructor.
You shouldn't use destructors/RAII to execute code that requires additional error handling. This is not a use case for them.

>Constructors are simply init functions that are crippled in that they cannot return an error code
Then can in Rust.

>destructors are further crippled in that they can't throw an exception either.
Not a valid use case. RAII is for closing files, freeing arrays, boxes, etc.

Sounds like you are retarded.

>That OP filename

Attached: rustvirgin.jpg (2048x833, 176K)

>jet begins identifying as an attack helicopter

>How so? Code written using RAII is much cleaner and easier to read than code using malloc and frees.
It's easier to skim over some code to understand generally what it does, but important information (e.g. information concerning error and their handling) is obscured. Like I said, it becomes a lot harder to get a complete picture of the local control flow graph using only local information. This makes it easy to introduce subtle bugs during maintenance.

>What is inefficient in static methods?
Passing heavy objects by value. Unless Large::new is inlined, this is going to be doing a completely superfluous memcpy from the stack onto the heap.
Box::new(Large::new())
There is a reason init functions take a pointer parameter, it allows in-situ construction.

>Then can in Rust.
Static methods are not constructors.

>You shouldn't use destructors/RAII to execute code that requires additional error handling. This is not a use case for them.
>Not a valid use case. RAII is for closing files, freeing arrays, boxes, etc.
I'm glad you live in a world without I/O errors.

>It's easier to skim over some code to understand generally what it does, but important information (e.g. information concerning error and their handling) is obscured. Like I said, it becomes a lot harder to get a complete picture of the local control flow graph using only local information. This makes it easy to introduce subtle bugs during maintenance.
Information about errors is never obscured in Rust. If your static method for creating a struct can return an error, you have to handle it.

>Passing heavy objects by value. Unless Large::new is inlined, this is going to be doing a completely superfluous memcpy from the stack onto the heap.
Does Placement In and Box syntax solve this issue?

>Static methods are not constructors.
Yeah, I guess. But they are used in same way, except have less restrictions.

>I'm glad you live in a world without I/O errors.
What would you want to do if your array or something fails to dealloc? Is this even recoverable?

>Information about errors is never obscured in Rust. If your static method for creating a struct can return an error, you have to handle it.
This is correct and this is an improvement over RAII in C++ (which largely mandates the use of constructors and exceptions)

>Does Placement In and Box syntax solve this issue?
I'm not sure what you're referring to here.

>But they are used in same way, except have less restrictions
Unless you want to construct an object in place.

>What would you want to do if your array or something fails to dealloc? Is this even recoverable?
Not all cases of releasing a handle may fail, but there do exist cases where it may so RAII ultimately proves itself not to be a silver bullet.

Your first example is not really an fault of new/delete but due shitty exceptions in C++. Your second example is just shit

>what are smart ptrs

The first example is a fault of exceptions. The second example is a fault of the garbage type system.
Regardless, the point is not to pin the blame on any particular feature but to demonstrate how laden with pitfalls new/delete is.

You could say they same about open()/close() or literally any kind of API that requires manual cleanup

The distinction between delete and delete[] is unique to C++. Other open/close APIs don't suffr from this kind of retardation.

>I'm not sure what you're referring to here.
>Unless you want to construct an object in place.
These features allow you to construct objects(and evaluate expressions(?)) directly on heap. They are still WIP though, and I think you need #![...] to enable it.

>Not all cases of releasing a handle may fail, but there do exist cases where it may so RAII ultimately proves itself not to be a silver bullet.
Because it's not. If you want to free resources and handle errors, make a method for it and add warning/panic if destructor is called without it.

I'll keep an eye on that feature then, that's quite interesting.

Rust is basically C++ with a nicer syntax for std::unique_ptr. Prove me wrong.

>Nicer syntax
C++ has abominable syntax and Rust somehow manages to be even worse.
let mut ref foo = Foo::()?.panic!();[/ode]

Can you provide functionally equivalent in C++?

> Literally mashing together Rust keywords into nonsense

5/10 i replied

>let ref
>passing lifetimes to function without any arguments
>conditioning chaining + macro
>using macro as member function
Just because you threw some keywords in it, it doesn't it make a valid Rust code. This code doesn't make any sense at all.

> Rust is basically C++ with worse syntax for everything
ftfy

Bloated garbage

>Rust
>bloat

Attached: enhanced-buzz-26895-1445458041-7.jpg (540x360, 21K)

Try compiling hello world and tell me how big the binary is.

Dude. Come on.
I don't like Rust, but this is just stupid. Have you seen Eiffel language, for example? It's main language in my uni. It gets translated into C, and all files that it lefts in your project after compiling Hello World weight 80 megs. THIS is the bloat. Not your "100 bytes bigger than C++".

>rust is not bloated because this other language is also bloated
?

C++ hello world takes 8.7KB.
Rust hello world takes few MBs.
However, if I tell Rust to avoid static linking to make it imitate how g++ works, it takes 14KB. The difference is negligible in such a short code.
I'm not sure how to make g++ statically link all standard libraries, so we could compare these results.

Attached: Screenshot_2018-03-31_17-17-12.png (307x91, 7K)

Found comparison on StackOverflow:
-rw-r--r-- 1 aij aij 63 Apr 5 14:26 printf.c
-rwxr-xr-x 1 aij aij 6696 Apr 5 14:27 printf.dyn
-rwxr-xr-x 1 aij aij 829344 Apr 5 14:27 printf.static
-rw-r--r-- 1 aij aij 59 Apr 5 14:26 puts.c
-rwxr-xr-x 1 aij aij 6696 Apr 5 14:27 puts.dyn
-rwxr-xr-x 1 aij aij 829344 Apr 5 14:27 puts.static
-rwxr-xr-x 1 aij aij 8712 Apr 5 14:28 rust.dyn
-rw-r--r-- 1 aij aij 46 Apr 5 14:09 rust.rs
-rwxr-xr-x 1 aij aij 661496 Apr 5 14:28 rust.static

It's fucking nothing.

#[no_std];

Attached: 1509751555513.png (600x382, 163K)

rust bundles jemalloc, you also get nice tracebacks and such if you keep the large binaries