If Rust is so great, why dont people use it instead of C++?

If Rust is so great, why dont people use it instead of C++?

Attached: tensor.png (294x125, 6K)

Other urls found in this thread:

compcert.inria.fr/compcert-C.html
twitter.com/AnonBabble

Gatekeeping.

Because Rust was stabilized only three months before Tensorflow's first public release.

And Google started working on the predecessor to Tensorflow four years earlier.

If cancer is so bad, why do people get it?

google is a c++ shop anyway, i wouldn't expect them to use rust

Rust is trying to solve problems that stem from human fallibility and writing code quickly and carelessly, by making a new language. That's a long-standing temptation, because there's nothing programmers like more than building a new shiny toy, but it doesn't work.

>rust is trying to solve problems that humans have
How is that a bad thing?

Did they get ayys to write Rust?

Ever hear that saying about how security is a process, not a product? Rust is a product trying to fix a process problem. We have insecure code because writing secure code is difficult, nit-picky work, even by programming standards. Programmers hate it, because it isn't interesting, and the organizations that employ programmers hate it, because it necessarily involves slowing down a lot, writing tests and doing code reviews, and prioritizing finding and fixing bugs over time-to-market. Both those groups would dearly love to think "Gee, if only we use this new language, we'll magically solve this nonsense, and we can get on with doing what we really want!" Doesn't work. Same way it doesn't work on the ops side when some vendor comes in and says "You don't have to worry about all those persnickety permissions and firewall rules and such! Buy this magic box and put it in your rack and you're done!"

>constantly writing tests and doing code reviews to avoid simple memory bugs
Why do that when you can write a compiler that does it for you and then write tests for it once?

Because it doesn't solve the problem. It's a band-aid on a bullet wound. Same way static type-checking hasn't brought us secure code.

>it only solves a part of the problem but not all of it so we shouldn't use it
Sure, KRACK would've still happened but Heartbleed and two exploits that were used against the Tor Browser wouldn't have.
Static type-checking hasn't brought us secure code but it prevents many errors that can happen in dynamic languages.

Static analysis of C++ is a band-aid, a type system with a built-in notion of lifetimes is solving the problem.

I don't doubt that the Rust people have good intentions. But they're patching the latest leak on the boat when the problem is that devs keep sailing the boat into hurricanes. Plug a memory-safety hole and the water will leak in somewhere else. There is no solving the problem with a new tool - if there was Valgrind would have solved our problems with C before Rust came along. You won't solve the problem until you get devs to say "Wait, we need to fix up what we have here, instead of rushing off to the next thing. We need to prioritize maintenance over features." That's a people problem, which is why its so difficult and persistent. Saying that a new language that solves one more problem area can fix it just breeds complacency and kicks the can that much further down the road. Because if you'll remember, we went through this "replace C, it's not safe" business before with Java. Look where that got us.

The only problem it's solving is Mozilla's junior employees couldn't fix memory management bugs in C++ code. So instead of you know, figuring out how to train their employees, they wrote an entirely new language, compiler, standard library, toolchain....

thats the same issue I have with KDE, they should focus more on maintenance than features and maybe I would consider using it.

>Valgrind
Valgrind won't find the problem if it doesn't run into it.

>complacency
I don't think that having to pay attention to more things at once is going to help you miss fewer errors.
On the contrary, having fewer things to worry about means that you can focus on making sure that your program is doing some other dumb shit that the compiler can't berate you for.

>Java. Look where that got us
Java is much better language than C if you can afford to use it, and a lot of people could so they did.
The problem is that sometimes you can't and that's a hole that Rust fills quite nicely.

I don't doubt that your homework assignments have no memory management bugs.

>I don't doubt that your homework assignments have no memory management bugs.

Yes, because I spent the time fixing them instead of just expecting my tooling to do my homework for me.

They wound up with new JVM security patches every week. Your tower of abstractions needs a foundation, and that foundation isn't going to be memory safe because the CPU its running on isn't memory safe.

it's helping to raise the incredibly low standards of c/c++

>JVM security patches every week
But those patches are not for a bug that lets anyone on the internet read the program's entire memory space.
At best it's a privilege escalation in the security manager which requires you to already be running Java code on the target.
Don't forget which language the JVM is written in.

>i spent time doing a thing that a computer could do for me
Why were you even writing computer programs if you want to do everything yourself?

>Don't forget which language the JVM is written in.
Yeah and something has to be written in C. Or assembly. That's what I meant by how your tower of abstractions has to end somewhere. You have to write your standard library, interpreter, VM, OS kernel, or hypervisor in something. That something won't be memory safe, since the hardware isn't. You can push the location where the bugs occur around, but you can't eliminate them with a new language, because unless that language has all the no-guardrails properties of C, it'll be layered somewhere on top of a language that does.

If your tower of abstractions ends with a safe language then by fixing bugs in the tower you're fixing those bugs for everyone.
In the case of C++ everyone has the opportunity to make their own new bugs and no fixes in the tower are going to help.
Rust's tower is also much lower than Java's.

who fucking cares tensorflow is done in C++, everybody uses wrappers on that crappy brainlet language called python .

Your'e right, I should have never bothered learning math either because obviously I can just have my computer do it all for me. Hell programmers shouldn't even have to learn data structures because they have all been written already.

Rust really does solve that problem though. "Nope, fuck you, memory use error, won't compile." Unsafe languages like C, C++, etc. have a defect density that RISES with the size of the project. It's why Mozilla created Rust in the first place - fast, native, safe, multithread friendly code is already making Firefox better. IE/Edge, Webkit, and Blink are probably going to start falling further and further behind.

There's a point at which you should stop bothering because you already know the process but the computer will do it faster and better than you.

The only way the computer would do it faster and better than me is if I programmed it to do so.

Someone did.

And because you're not retarded you understand how it works.
And because you're not an amish you are using it because it's better and faster.

The tower of abstractions *can't* end in a safe language.

If you're saying that it's impossible to write a safe language because it will always have bugs then the answer to that is already in the post you replied to.

Brainlet here.

For all the great things Rust are supposed to be, or at least, become, it sure doesn't solve the problem that looking at the language hurts your eyes and feels like shit to write. It's like you're fighting the very thing that's trying to help you.

It takes time to get productive in. Even if you know C++, Java, python, javascript or any other common, relatively modern language really. I could jump into Go and make stuff straight off the bat. Rust? Not so much.

The hardware doesn't enforce the safeguards that you want your safe language to. You have NX and the usermode/kernel split and that's about it. So at bottom there's no safety other than "I promise to myself not to do that." And you can't just enforce that unsafe things are never done, since unsafe things are how you implement the stuff that firmware and operating system kernels do. You read and write arbitrary things from arbitrary memory addresses and you're on your own to keep track of what's where and what you mustn't do with it.

>feels like shit to write
I think the standard library is much better designed than any of the other languages you listed and I use two of them regularly.
Anyway Rust is a complex language even if you ignore lifetimes so it does take a while to learn.

>hardware doesn't enforce the safeguards
It doesn't need to. If you can prove that your compiler is correct then the guarantees it makes will hold for any program you compile with it.
Obviously you have to write unsafe code at some point but if 99% of your code is safe then that's one hundred times less code to scrape through when you're looking for bugs that you know should be prevented by the compiler.

>If you can prove that your compiler is correct
Yeah and if frogs had wings they wouldn't drag their asses on the ground. Proving the compiler's correctness isn't done any more than people prove that the application they're feeding to the compiler is correct. Arguably less so, since compilers are some of the most complicated pieces of code we have. If everyone proved what they wrote correct, we'd have no need for the compiler to enforce anything.

compcert.inria.fr/compcert-C.html
But it can be done and it only needs to be done once, not every fucking time you're writing a new program.
It doesn't even matter if it's formally verified or not, you're still enjoying the fact that if a bug does arise, you only need to fix it once, in one codebase.

Argumentum ad populum

Yes, I understand how it works, and I still think it's hubris because you are still caught up in trying to solve the halting problem with yet another toy language.

Also since I am amish, I actually take time to ponder the ramifications of my decisions and I realize that engineering is about tradeoffs. With any tool you are trading one class of bugs for another.

>solve the halting problem
You can come back after you read the documentation and figure out what kind of problems Rust is trying to prevent.

You can come back when you work for a company that isn't mozilla and you realize that other orgs have different issues

Is there any free cloud hosting API that I can use to store serialized or encrypted data for backup?

Ops, wrong thread.
Strawman. Not him btw.

..because the heavy lifting is done in CUDA and on GPU?

what are you gonna say when years from now the language has evolved to the point where it's simple to write and has no performance penalty for all those security features?
what the fuck are you gonna say then?
reminder that REAL programmers use FORTRAN.

>and has no performance penalty for all those security features?
this isn't possible. Unless you forgo runtime checks entirely, and only rely on what the compiler can do at build time. Which is, y'know, what C does.

err what I mean was that the penalty is so small that it's as fast, if not faster than C.
obviously there could never be zero overhead for those checks

I thought go was supposed to replace c++

go managed to be worse than a language from 1998

Rust is a diversity hire language created for people who can't do C++. In fact, every language that tries to replace C++ is exactly that.

Nu males like it, so I dont. Works every time,I've never had a case of shittasteitis since I started following this policy.

t. tried to figure out lifetimes, failed, and now trying to rationalize it

I never pursued programming as a career. In the corporate world, the nigger is supreme. This trickles down to programming too. In the early days of personal computing, we got cucked by big corporations. All the sales went to IBM because the big companies wanted computers to run their business. They didn't care if there were alternatives that could do more for less, they wanted IBM. Ever hear the phrase vote with your wallet? We users were up against the multi-national corporations, and lost in the 1980s. Everyone who uses a computer of any type is pre-cucked by IBM decades into the future/past. Now that we have that out of the way, it is clear that companies see computers as a means to turn a buck or two. That means programming is all about slapping an app together barely working, because time is money. In order to be a programmer as a career, you have to embrace that. Pajeet the nigger will do it cheaper too. It is a dead end. Computers now cater to retards. Everyone loses and our society is destroyed in a possibly irreversible manner. I am happily making money in another sector of IT where I was hired because I was hard to find. I will go into IT security after this.

Attached: 1521508899732.jpg (662x602, 104K)

...

because it isn't and most people claiming that can't do shit on C++ even if their lives depend on it

>not using a purely functional language like Haskell instead to have infinitely scalable, parallelizable code that is completely safe

>PAAJEEEET TAKE JOB VERY BAD SIR
>I will go into IT security after this.
>Going into a field with more pajeets than helpdesk

Attached: 14664534657.gif (295x221, 646K)

But he's right. For the last 30 years, colleges and programs have directly targeted the disadvantaged colored youth (to no avail) ignoring the very source for which great talent comes; the highest STEM performers could easily be taught to replace corporations like Google in no time at all. The diversity scheme is more about creating more work for government and recruiting agencies (and schools, training programs etc.) not actually enriching the workplace or increasing productivity.

It's nothing to laugh at. Denver companies told thousands they would be hired with just a CCNA... I went to Job Corps 5 years ago and worked tirelessly for 6 months, fastest CCNA graduate they had... just to try and get hired. By the time I was out, Obama had signed 2 million Indian visas... Half these Indians were IT guys who had CCNPs. I worked via telephone with one such Visa worker, who could barely speak English and yet runs a major IBM remote division... These people are being invited in with incentives... not good for security or our education-to-workplace pathway.

/thread
c++ gives the programmer a lot of freedom so give it to a shitty programmer and you'll get shit in return. all the other languages have immense hand holding

Just use smart pointers properly and follow relevant guidelines when needed to manage lifetimes. If you're willing to use Rust, chances are you're willing to write modern C++ too.
Watch the talks from cppcon, they're really informative and convinced me a modern C++ application without legacy code can look good, perform well and be safe at the same time. There are very valid points why a new language is not the right answer and how modern C++ solves most issues.

run-time CoC checks

>Watch the talks from cppcon, they're really informative and convinced me a modern C++ application without legacy code can look good
I did the same thing and thought the same thing but when I tried to apply all that in a real application it didn't work nearly as well as I had hoped.

Move semantics are still shit because the default behaviour is copying.
>the rule of three
>wait no, it's the rule of five now
There are no good multithreading utilities in the standard library so you end up depending on boost.
Speaking of depending, managing dependencies in C++ is still a problem. So much of a problem that the hottest new thing right now is header-only libraries.
The standard library in general is horrible compared to most other languages. You'll be writing "function(something.begin(), something.end())" a lot.
Templates are still shit and concepts are yet to be added a whole decade after they were first suggested.