C++ V.S. Rust: The Final Battle

Let's settle this once and for all.

Other urls found in this thread:

tour.golang.org
strawpoll.me/11949086
dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/
news.ycombinator.com/item?id=8817990
rocket.rs/
hyper.rs/
ironframework.io/
diesel.rs/
forge.rust-lang.org/platform-support.html
rocket.rs
diesel.rs
twitter.com/NSFWRedditImage

Rust is better, but is still in its meme phase.

C

Rust will get out of it's meme phase as soon as more developers start using it

go to your room, the adults are talking

Rust is objectively better, but C++11/14/17/20 is on the right way and it presents a more practical upgrade path from C or C++03. Coupled with a large pool of C++ specialists and huge amount of legacy code, I don't think Rust will be able to compete with C++ for real in the next decade.

My biggest problem is the lack and immaturity of libraries. I know Rust is really young, but I cannot recommend it to use in production for this reason.

C++ if you only consider the language.
Rust if you don't want to spend hours setting up your project before you've even written a single line of code whose purpose isn't evaluating the library you wanted to use.

Rust is the future, C++ is the past.

>I'm too dumb to learn to use any of these languages so I will start a flame thread to make the fanboys mad at each other, and to justificate my opinion on the usability of said languages
t. butthurt/brainlet OP

C++

Rust is a meme. If i want "security", then Ada is the right choice.

>either manual management or GC
>security
>performance
>right choice
You're the meme.

Rust is the better language, C++ is trying to play catch-up with it as far as memory safety is concerned, but it will never be able to.

how many Rust jobs are there? approximately 5?

better to write your backend processing maybe but anything user facing looks like a fucking nightmare in rust so far

looks ideal for writing libraries to do stuff though, leave ui to some other language and take advantage of rust where it'll help the most

learn Go (golang). surely won't work for making an OS or some critical low level stuff, but for eveything else, it works and it's just awesome.

>comparing godlevel Rust with shitty c++

Rust is still a meme

C++ is more widely used dogshit

stick to Java if you can

>java
toplmao!! why is Sup Forums full of plebs?

c++ is nothing but bloat, pain and suffering

I'd rather be a happy and productive plebfag

Not any more or less than C++ (actually less than C++ due to the functional, high-level features).

>all the flaws of C
>no feature from the past 40 years of language improvements
How about 'no'.

...

>>all the flaws of C
wat

>>no feature from the past 40 years of language improvements
yeah, the kind of "improvements" that make devs think themselves as 1337 h4x0rz while producing/duplicating shitty code

The joke is that linus doesn't know shit about C nor C++.
>m-muh os!11
It's like that guy who made libhungarian. Worst code I've seen in my life and it barely works but it works.

Gotards, everyone.

>impying I like c++

patches are welcome
also, you clearly don't know shit about Go

btw, you can start here:
tour.golang.org

>go
>any contribution whatsoever being welcome
Gotards everybody!

Yes, but it's the future.
5 jobs for humans and everything else for robots.

Depends on context.

If you're a guy looking for a job, C++, more companies use it atm.

If you're an old company with established practices, C++, because libraries.

If you're a new company, with time, money and developers, and you want to be able to do things that other companies can't yet, Rust.

If you're an open source developer with lots of time, Rust.

I can't see why would anyone have any interest in castrated C with GC. I spent some time reading about Go and it's like the authors stuck in 80s: weak type system, no generics, no pattern matching, interface{} all the way down, retarded error handling based on Bools and Strings, horrendous syntax and relatively poor performance for compiled language. The only reason it's still alive is because it has Google's prestige behind it. The only good thing about it is gorutines, and C++ and Rust are making steps in this directions.

I mean, for a long time they didn't even have bootstraping, having a lot of C code. Then suddenly they declared they rewrote it all to Go, yet when I check it, it turned out they wrote a tool which AUTO-CONVERTED all their C code to Go, and so they now have a ton of auto-generated Go code they need to support somehow. After that I became dead sure the developers not only are retrogrades stuck in 80s, but also brain dead.

Features isn't what c++ is missing.
There are 3 main problems which are never gonna get fixed.

1. Header files & long compile times
2. No reflection for automatic (de) serialisation.
3. Absolutely horrible trying to port/build to a different platforms

Google cared mostly about compile times

You forgot memory unsafety and exceptions.

This. And despite all that, gotards are somehow still a thing.

c++ is getting modules and reflection in c++20, hopefully. if it doesnt get pushed back to a later release again.

>I can't see why would anyone have any interest in castrated C with GC. I spent some time reading about Go and it's like the authors stuck in 80s: weak type system, no generics, no pattern matching, interface{} all the way down, retarded error handling based on Bools and Strings, horrendous syntax and relatively poor performance for compiled language. The only reason it's still alive is because it has Google's prestige behind it. The only good thing about it is gorutines, and C++ and Rust are making steps in this directions.
it's easy and simple, and supports lots of platforms, architectures, etc. sure, error management sucks and Go doesn't support generics... but, again, the Go devs have said so themselves:
patches are welcome

>I mean, for a long time they didn't even have bootstraping, having a lot of C code. Then suddenly they declared they rewrote it all to Go, yet when I check it, it turned out they wrote a tool which AUTO-CONVERTED all their C code to Go, and so they now have a ton of auto-generated Go code they need to support somehow. After that I became dead sure the developers not only are retrogrades stuck in 80s, but also brain dead.
being Go a small language, I don't even see the problem with this. also, as someone told me once, it's not exactly C what they autoconverted... but specific flavour of C they have used for decades.
and afaiu, they removed lots of the bad autogenerated code in Go 1.6.
the Go ecosystem moves fast as hell, but according to you, that's a bad thing, and the devs are "are retrogrades stuck in 80s, but also brain dead". meanwhile, Rust is still alpha, apparently for eternity.

btw, did you notice that Go takes lots of good features from many other langs? meanwhile, other lang devs are polishing their turds, simply making a mess of them

> 1. Header files & long compile times
Yeah, but I hope Modules will fix this.
> 2. No reflection for automatic (de) serialisation.
There are some proposals for compile-time reflections, but I personally don't think there is a huge need for this in compiled language. Serialization isn't such a big thing to include support for it in the language itself. Some actual macros system or C#-style attributes would be nice though, but it's unlikely we'll ever get them.
> 3. Absolutely horrible trying to port/build to a different platforms
I don't get it, the only language which have better crosplatform story is C.

Memory unsafety is a feature of systems programming languages. You NEED pointers. With gc it simply isn't a system programming language. Unless you want a draconian compiler checking like rust.

Exceptions suck and should be disabled in the compiler.

The C compiler used by Go wasn't all that great to start with. AFAIK it's a relic from Plan 9. Like you said, they auto converted the code from C to Go for whatever reason. It was most likely a prestige thing.
I never understood why they didn't utilize something like LLVM. They'll never catch up.

>No need for reflection
Is that why so many projects have some kind of shitty slow meta tool
>I don't get it
What I mean it's a horrible experience trying to build a project on different platforms. Everyone does kinda its own thing and there are dozens of different build systems.

Personally I switched to a unity build myself. This actually removed the need for header files ( only one for public api) and build systems and reduced the compile time.

>systems programming language
>won't work for making an OS or some critical low level stuff

Just because you need memory unsafety for 0.00001% of programs in 0.1% of those program's codebases does not mean it should be the only way to deal with memory.

strawpoll.me/11949086

>it's easy and simple
This is might be the key here.
>the Go ecosystem moves fast as hell, but according to you, that's a bad thing
>specific flavour of C they have used for decades
So how "using a specific flavor of C" instead of standard C is a good thing to begin with? Read this - dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/ , their compiler infrastructure is a bunch of NIH shit they invented literally in 80s for failed Plan 9 meme OS and refuse to let go since then. Like, they have their own assembler with their own syntax, their own linker and codegen, all weird and incomparable with the rest of the world. Meanwhile things like LLVM exists for decade. I mean, yeah, they try to fix it but it's still idiosyncratic shit for no reason except for authors' severe NIH syndrom.
>Rust is still alpha, apparently for eternity.
Rust is stable since May 2015, they released 1.14 a couple days ago, stable Firefox uses Rust from some components.
>did you notice that Go takes lots of good features from many other langs? meanwhile, other lang devs are polishing their turds, simply making a mess of them
This is an interesting thing to say, considering Go still lacks algebraic types, real macro system, pattern matching and generics, while even C++17 have the last 3 in some form or another. Like, do you really have an idea how C++ or Rust changed in the last 5 years?

>I never understood why they didn't utilize something like LLVM. They'll never catch up.
speed, the devs said so: news.ycombinator.com/item?id=8817990
>Honestly, if we'd built on GCC or LLVM, we'd be moving so slowly I'd probably have left the project years ago.

>muh "systems programming language" meme

>does not mean it should be the only way to deal with memory.
thats what custom pointer classes are for.

>significant overhead
>plus even more overhead and non-determinism than gc because lmao refcounting ebin!

If you don't need pointers why the fuck are you going through the pain of using C++ in the first place. Use some GC language.

>what is std::unique_ptr

you can use gc in c++ or any other memory management style you want if you really want to.

C++

Because freedom > safety
Freedom brings responsability = Better programmers
Safety brings confort = Pajeet programmers

Also, the necessary tooling already exists. Rewriting everything from scratch because it's hard to get "C++ done right" sounds like a bad excuse.

Because most languages don't have value types.

-deprecated
-as noted, still massive overhead
-not compatible with other pointer semantics
>unique

Is there a good library for web API on Rust?
What about db connections?
Maybe even ORM? Or at least some library that can generate query for you?

Or I could decide that maybe my IQ isn't in the single-digits and use rust instead, since it solves all related issues perfectly.

>Freedom brings responsability = Better programmers
>this is what pajeet believes
Don't you have another memory leak and 20 segfaults to fix pajeet? What are you doing not working?

>We refuse to look into any other toolchain than what Plan9 provides

Wait it can compile against arm-none-eabi?

Why do you even argue about things you don't know?
- Not only unique_ptr isn't deprecated, it's the recommended way to manage objects on the heap. You're confusing it with std::auto_ptr from C++98, which is deprecated.
- unique_ptr compiles to no-op, it literally does nothing, its purpose is to force ownership semantic during the compile time. You're confusing with std::shared_ptr which does refcounting on construction and destruction.
- what

C++ with good programming practices is objectively better than Rust.

>I want full control over my memory so i can reduce overhead and minimize memory latencies
>I don't want to deal with the inevitable consequences of that freedom

Can't have your cake and eat it to.

...

Check crates.io for all your questions.
1- rustful/rustless, hyper, iron, aries, etc.
2- postgres, unqlite, ejdb, r2d2, mongo-rs, mysql, etc.
3- diesel, deuterium

>Is there a good library for web API on Rust?
rocket.rs/
hyper.rs/
ironframework.io/
>Maybe even ORM? Or at least some library that can generate query for you?
diesel.rs/

>literally posts a pic that literally describes the cost of unique_ptr
>"i-it totally c-compiles to nop nevermind what I just posted but don't forget what I just posted!"
My sides. Enjoy using your deprecated, slow pointer wrapper, retard.

> I can't handle sanitizers.

rofl

It can target anything LLVM targets, so yes.

This.

Turns out you can. It's called rust. Look it up.

forge.rust-lang.org/platform-support.html

>dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/
>2014/12
whatever, m8. keep masturbating over your specialized knowledge of this or that language, while the Go devs produce shit that works™

I myself, like most devs, have no need for that.

>Is there a good library for web API on Rust?

rocket.rs

> Maybe even ORM? Or at least some library that can generate query for you?

diesel.rs

>no destructuring binds
>no proper functional tools
>mutability by default
>lmaoconst
>reversed ownership model
>heavyweight classes instead of 0-cost structs
>lmaoexceptions
>memory management is either costly or a guaranteed significant source of bugs ranging from heisenglitches to critical security vulnerability allowing full system access
>no proper modules
>no proper dependency management tools e.g. for reproducible building
Not even close.

Only neet would ask stupid question like this.

Can you read?
>Cost: same as new/delete or malloc/free
The smart pointer itself costs nothing, using unique_ptr is equivalent to using new/delete, which is more or less equivalent to using malloc/free.

Noob Question; what's the point of immutable variables?

for long nights of 'brain-off' programming

if the compiler shouts that you are changing an immutable variable, you should go into 'brain-on' mode

>heavyweight classes instead of 0-cost structs
the only difference is whether the default is public: or private:

threadsafe. simpler to understand and optimize.
creates a ton of garbage in functional languages because you cant mutate anything.

>no destructuring binds
They added it in C++17, at least for tuples.
>no proper functional tools
Like what? With lambdas and std::function you can do pretty much everything.
>mutability by default
Just write "const".
>lmaoconst
You forgot "volatile".
>reversed ownership model
Whatever.
>heavyweight classes instead of 0-cost structs
Classes and structs are literally the same and they are zero-cost except for vtable, and you don't have it unless you're dumb enough to use virtual methods.
>lmaoexceptions
It was a mistake, I agree.
>memory management is either costly or a guaranteed significant source of bugs ranging from heisenglitches to critical security vulnerability allowing full system access
Not if you know what you're doing.
>no proper modules
>no proper dependency management tools e.g. for reproducible building
Wait for C++20.

The compiler can optimize them, such as all immutable variables with the same value could actually be pointing to the same object.
The more important part, though, is that it acts as a simple protection against modifying part of the environment you do not want to modify inadvertently. For example, if you have the functions ret = do_first_step(x); and do_second_step(ret, x); it could be that do_second_step and do_first_step both modify x, yet both require the unmodified x as input. In C++, you don't even have a hint that this is happening. In rust, the compiler prevents you from calling do_first_step without making x a mutable reference, which in turn must mean that x itself is mutable.

Then there's concurrency. If two things are trying to read to an object, you can do that in parallel. When one thing tries to write to it, all reads must first be complete, then no other write must happen, then the scheduled write can happen, and finally the reads, or further writes, can resume. It's impossible to tell what needs to be locked in this manner without knowing if something needs to be mutable. On the other hand, if you know what is mutable and what isn't, it's not an issue.

>Not if you know what you're doing.

Nobody knows what they're doing then since basically all C and C++ code is riddled with vulnerabilities. The only reason you think yours isn't is because it's so small and irrelevant that nobody smarter than you has bothered to look at it.

No it's not. In rust, the only overhead for structs is the variant identifier. In C++, every time you create or destroy a class, you have a runtime cost. On top of that if you use inheritance in any way, size cost is not trivial at all.

Nice, tanks!

Fuck off Rob

unique_ptr simply calls new in the constructor and delete in the destructor. That's all. There is no overhead.

Rust shills are shilling for emptiness.

No one uses Rust (yet)

Inheritance in C++ is a meme anyway. Only use it for java style interfaces at best.

The overhead is small != there is no overhead.

> C++ V.S. Rust

fuck both

It is hard to program for linux since the api is meant for C

because of the model used in c++, only a retard wouldn't use it. the trait-based approached is infinitely superior for sure.

I don't agree with this statement. Rust makes it truly painless to work with C while retaining as many of its advantages as possible (and libcore and the like of runtime are goat, much better than anything C++ has to offer for working with C).

struct {...}; == class {public:...};
class {...}; == struct {private:...};


it only has runtime cost if constructors/destructor has runtime cost.

and obviously inheritance is going to increases the size unless it has no data.

> No it's not. In rust, the only overhead for structs is the variant identifier.
Did they get rid of the drop bit or whatever they called it? They had to put a byte in every type to see if Drop::drop was called on it already or not, because the compiler was too dump to determine it at the compile time.
> In C++, every time you create or destroy a class, you have a runtime cost.
You have no idea what you're talking about. Creating a class instance on heap in C++ is basically a single operator new() (which is malloc) + constructors chain. Creating a boxed value in Rust is exactly the same, ::new() being a constructor. Yes, virtual methods add vtable to the picture, but so do Trait Objects in Rust.

t. inbred

I laughed, but only a bit.

Come on mate this is shit-tier trolling. Ever heard of inline?

unique_ptr literally does what you would do in C, it just removes some of the potential for mistakes.

>Like what? With lambdas and std::function you can do pretty much everything.
Most of the whining about 'muh functional' that I've heard seems to revolve around not having reflection/type info that can be hacked into a json serialiser

std::function and all the tricky shit like bind and remove_reference make it so much easier to do a lot of common shit like gui or any other event-based stuff