Should I learn Rust or C++?

Does Rust have a future?

Other urls found in this thread:

cplusplus.com/doc/tutorial/
learncpp.com/
twitter.com/NSFWRedditGif

no

Rust
C is dead like windows

OP is talking about c++ not c

Well, what is your opinion on using a loo?

>risking capture by a toilet witch

I think you would enjoy java most.

धन्यवाद

Hello Rajeesh, 5 rupees have been deposited into your account.

Learn how to program.

...

you can learn most of C++ in a half hour, just dont chase after the (((((idiomatic C++11))))) dragon, there is no such thing as """"idiomatic C++""""

yess

Rust's idea of memory safety without a gc or runtime has a future. Rust itself suffers from an abysmal community and the syntax is cumbersome to work with. Maybe 2.0 will do something about the latter, but I don't know of a way to fix the former.

Yes

Isn't it just C++ that uses as many new features as possible?

>you can learn most of C++ in a half hour

people who study in the sciences who need to use C++ use this tutorial, its all they need, only takes a half hour
cplusplus.com/doc/tutorial/

That's a brief introduction. Basically a summary of the summary

Here is a bigger summary learncpp.com/ and it's only 1400 pages

by the time Rust will be widely used (if ever) you should be C++ expert so you can jump on any language you need in a week

>cancerous community
This desu. Just take a look at the raging dumpster fires that are rust threads on hn. Hell just look at their reddit subreddit. Look at how they express their disagreement. My experiences with them is that they're generally petty and extremely emotion-driven. If they for whatever reason dislike something you wrote, they'll attack you in any way that could be spun as on topic.

From my work with it, The language itself does provide something new and valuable to low level programming. Safe-by-default is sorely needed and dare I say required in languages of this type. The syntax, while disliked by some, encodes enough information that rust compilers are able to catch far more mistakes at compile time than any C/C++ compiler. This alone justifies the extra verbosity to me. (I'm also a twisted fuck that enjoys the syntax).

As to whether rust will succeed or not, only time will tell. My bet is that it will, in spite of the loonies that associate with it.

Rust is dead on arrival, Mozilla is fucked.

Nah, you don't understand how this works.

Java succeeded because of Sun and Oracle.
C succeeded because of UNIX.
C++ succeeded because of Windows.
Python succeeded because of retards.
Rust will not succeed because SJWs are very few in number.

> Rust will not succeed because SJWs are very few in number.
The fact that they're few works in Rust's favor. We'll see.

>hello world file
>2.2Mb

How can you live with yourselves, rustcucks

C++ will be there in the near and distant future, Rust will also be. At least in Mozilla's codebase.

lel
after a half hour learning c++ you might be able to write some small shitty programs: hello world, some calculations with arrays, integrals whatever, but at that point you could have learned python too.
To get to the point where you can use C++'s superior language to accomplish something, you will need to invest way more time. And the next step is accomplishing the same thing efficiently (not passing every object by value, using appropriate containers [vector > list], multi-threading?).

C++11's features are very helpful for making your code shorter/more readable and some of them can also make it safer (exception-safety, less memory leaks etc).

Use static_assert's where possible
Use auto
You can return objects by value
Don't use owning plain pointers (there's unique_ptr/shared_ptr for that)
Don't use new and delete in application code
...

You should learn both, and then settle on C++.

This.
Chase after the idiomatic C++17 dragon instead. Also read Effective Modern C++.

This.

It is hard to tell, because the language is still only beta quality. So many features are missing and problems unsolved. 1.0 is a terrible rushed lie born out of butthurt about new languages like Go and Swift gaining some traction. You need to wait at least 5 years and see.

Learn programming, don't focus too hard on what language, it is not important.

Idiomatic C++17 isn't far removed from C++11 though.

It remains a bad idea to use either.

Am I the only one on Sup Forums who genuinely loves C++? All I've ever known is C++11, so I might be a bit biased, but honestly, though, the language is great. Most of the shitty stuff is inherited from C.

C++ is powerful but so full of ugliness that it's almost impossible to write satisyingly elegant code.

I like it as much as I hate it.

I fully agree. It's the most powerful language and provides the most freedom to the developer, but also the ugliest. The biggest mistake was temple meta programming. Boost deserves to die in a ditch. Hopefully we'll get arbitrary compile time code execution by C++20 so we can finally retire that mess. There is a serious lack of good C++ libraries that compare to Java's or C#'s standard library. STL is too bare bones, Qt is bloat (it needs a fucking meta compiler) and boost is an eldritch abomination.

Has there really been a need for TMP since C++11? type_traits and constexpr seem like enough.

What are some ai languages

>not learning both
Brainlet.

>It remains a bad idea to use either.
No it doesn't, you're just a dumb Cfag.

I genuinely love the language too. It has plenty of problems but it's still the most powerful (and actually useful) programming language that compiles to efficient native code.

It is possible to write elegant C++, though it depends on your taste I guess.

Constexpr isn't enough.
There needs to be a way to guarentee compile time execution of constexpr functions (so that the parameters can be passed to templates as template parameters) and we need a way of passing string literals as template parameters.
In fact they just need to allow us to pass any constexpr class as a template parameter, I don't know why we can't already.

I don't even like C, it's inexpressive and error prone, and bogged down in boilerplate. But it is at least consistent and readable.

constexpr auto foo = bar();
Isn't that enough to guarantee compiletime evaluation of bar?

The following program compiles just fine, but not without the constexpr.
template
struct Foo {};

constexpr int triple(int x) { return x * 3; };

int main()
{
Foo foo;
}


Passing arbitrary values as template parameters is in D, right? It sounds pretty dangerous though, you might have a bad time if you try doing it with doubles because of roundoff errors. In fact, comparisons in general for user defined types seem like dangerous territory.

No, I don't mean like that.
I mean like this:
template
struct Blah {};

static constexpr void foo(int x) {
Blah blah;
}

int main() {
foo(47);
}

main.cxx:5:8: error: ‘x’ is not a constant expression
Blah blah;


It's because a constexpr function is not guarenteed to always have it's arguments known, so you can't pass them to template parameters.
If the standard allowed you to mark a constexpr function as compile-time only, that would lift that restriction and allow you to pass x in foo to Blah as a template parameter.
That + the ability to pass string literals (and ideally any constexpr class) as template parameters would enable you to do a lot of things, such as implementing fully type safe precompiled format strings supporting user defined types.

Rust is shit. Wait for Rust++.

I get you now.
That's a tricky one. I like constexpr because there's no distinction between a function that can only be run at compiletime or only at runtime. It's a small amount of elegance in a bloated language. But I can see the usefulness of this suggestion.

As for your string literal idea, how would it work?
template
struct Foo {};

Foo bar;
Foo baz;
Those pointers aren't guaranteed to compare equal. How's the compiler supposed to know not to instantiate two separate classes? Same for user defined types which are logically equal but have different data members.
struct Comparable
{
int x;
bool operator==(Comparable const &other)
{
return true;
}
}

Foo bar;
Foo baz;
Are these equal? Is the compiler just supposed to check == against every other instantiation? What if a == b yields true, b == c yields true but a == c yields false?

>As for your string literal idea, how would it work?
Perhaps it should expand to a parameter pack of chars, like this:
template
struct Foo {
...
static constexpr char[] some_string = {chars..., 0};
...
static constexpr size_t length = sizeof...(chars);
...
};

Foo bar; // expands to Foo (should the null terminator be included?)
Foo baz;


>Same for user defined types which are logically equal but have different data members.
Fair point, user defined types as template parameters would be tricky, but I think string literals could be done.