You want to develop a large desktop application

>C/C++ as a core language
+Tons of resources and large community
+Faster/est binaries
-Codebase is ugly, leads to shitty design (with C++)
-Slowly becomes unmaintainable
-Close to 0 productivity (with C)
-No memory safety

>Rust
+Binaries just as fast as C++
+Tons of features
+Maintainable codebase with package managers and Modules, strict checks
+Close to 0 memory leaks and corruptions
-Much less community
-Much less libraries unless you are calling C libraries

>D
+Productive as fuck
+Small and yet mature community
+Libraries better than Rust
-Slow binaries
-Almost no memory safety (not as much as C/C++)

Discuss. No flame wars please

Other urls found in this thread:

github.com/kud1ing/awesome-rust
gcc.gnu.org/projects/cxx-status.html#cxx14
clang.llvm.org/cxx_status.html
nim-lang.org/
benchmarksgame.alioth.debian.org/u64q/rust.html
benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html
twitter.com/SFWRedditGifs

>+Close to 0 memory leaks and corruptions
You shouldn't be leaking memory in C++ either if you're using RAII.

>+Tons of features
Describes C++14 as well.

I'd go with C++.
I don't like few things in rust, like '!' in println!() or variables being constant by default.
D is just slow and Dead.
C is functional, so writing anything large in it is hard.

Shii best car

electron app with Angular 2 frontend and custom C++ nodejs native plugins for any heavy lifting :^)

>C is functional
What?

I meant that it uses functions to do everything, and it doesn't have objects.
>inb4 c with classes
It still uses functions to do everything with those objects.

Rust community isn't that small.

github.com/kud1ing/awesome-rust

Not every compiler has implemented C++14 yet

It matters not, because - even if D or Rust actually become good in the future - the thing that is cancerous in all kinds of flavor is the GUI library. It's all garbage.
Don't even try to prove me wrong; you can't.

>C is functional

Seriously?

nyanko is love

See

Every important - meaning clang and gcc has, though.

You have no idea what you're talking about.
C using functions in no way makes it a functional programming language.
C is imperative and structural.

Ok then, my bad, but the point still stands.
C doesn't have true objects, making it hard to write large desktop apps.

C#

>C doesn't have true objects, making it hard to write large desktop apps.
>I don't know how to design non-POO systems
>Therefore it cannot be done

D's dead. Not sure why it keeps on coming up. I'd do C/C++.

gcc.gnu.org/projects/cxx-status.html#cxx14
clang.llvm.org/cxx_status.html

The only two compilers that matter support all of C++14.

>hard == impossible
You could make it only with C, but it's easier to design desktop apps with C++ or any higher level language, that's a fact.
Prove me wrong.
Protip: you can't.

Is Rust better than Go?

Prove yourself right, idiot.
There are other (and frankly, better) ways to design programs.
Procedural programming exists, and is the more obvious and natural way to program imperatively.

u hav never writen a program
prov wron
letip u cant xd

>not building your own C++14 compatible divine intellect compiler as a white man
??????????????

Script kiddies get out

>Rust
>+Binaries just as fast as C++
I wish this myth would die. Only bare metal languages can compete with other bare metal languages.

D also has the con of being forced-gc'd OR forced-mem leaking (because of the std lib). Because of that I consider it currently downright unusable. When they fix it, I'll consider it not worth the effort to learn because its advantages over C++ are just too subtle while having distinct disadvantages.

Large desktop applications come in many flavors. If you are mostly designing brand-new concepts, I'd go with rust because you couldn't leverage C++ libraries anyway. If you're mostly tying together many non-trivial services, I'd probably prefer C++, but still note that rust is a viable option in that scenario thanks to its FFI.

It's actually larger than e.g. haskell's or lisp's, but it still is small compared to the likes of java's, python's, or C++'s.

See e.g.

>-Slowly becomes unmaintainable
>-Close to 0 productivity (with C)
>-No memory safety
??

In what sense is Rust not a "bare metal language"?

because its an oxide

It's a safety language.

Please explain what you mean by "bare metal language". Because none of the definitions that come to mind for me have anything to do with safety.

If you have to explicitly use and maintain usage through pointer objects, you're really just passing objects by value which use RAII to slowly manage memory (refcounting is slower than GC). It's not really safe memory management in the sense used here, and you still have issues whenever calling out to foreign code because they won't accept your object.

Productivity in modern C++ is actually pretty good, but still lacking due to the obtuse syntax which is a result of attempts at backward-compatibility. It makes it clunky and verbose where languages built from the ground up with modern features don't need to be. I think trying to compare it with C in that regard is misguided, though, it's definitely a lot better.

Because of verbosity, ancestral features (such as #include and C-style macros in general) and feature creep, C++ codebases become less maintainable with every line of code added to them. Other languages may maintain the same maintainability level indefinitely.

Go can't even compete, rust is faster than C++

This user gets it. D has a great syntax and it's much more readable and maintainable. Small D programs may not have the best performance but as tge application goes larger D keeps the codebase clean, easier for refactoring and human eye friendly. Which is a big wise plus

If you're worried about C being unsafe just get some safe libraries, or make them yourself. You can replicate C++ vectors in C in like 5 minutes, write functions for handling pointers that won't allow you to be a retard with them, whatever you need you can find online or just write yourself.

OOP isn't actually that hard in C.

struct foo
{
int x;
};

void foo_method(struct foo *self, int x)
{
self->x = x;
}


Polymorphism can be done with function pointers.

You don't need inheritance, although it's still possible. (see berkeley sockets)

>OOP is "structs and functions that work on those structs"
No. You don't know what you're talking about.
That falls under procedural programming.

OOP is just that under the hood.

...

Structs are not OOP

C++ isn't even fully object-oriented. You need something like Python, where just about everything is an object, to use OOP in the truest sense.

I feel c's functions are better described as subroutines, because each function has its own context and can access the global context.

>ancestral features (such as #include and C-style macros in general)
a -std=c++unfucked would be amazing

if VC++ doesn't care about the standard then neither do I.

It can do everything important.

electron w/ react+flow typing

This

D was initially designed to be a "better C++", but it has ended up as more of a "better Python" (although lacking the strong ecosystem of Python)

Better python is not a bad thing

foo should contain a function pointer called foo_method, then foo will be its own self contained thing that relates its own behaviours and data.

For example, a cat can have its own sneeze method, it shouldn't have to call some external sneeze method.

>a "better Python"
nim-lang.org/

Except that's wrong.
Methods are NOT part of the object data-wise.
When you create a method on an object, it is basically syntactic sugar for You can verify this yourself in C++ by just simply looking at the assembly.
Of course, if you want a virtual method, then it has to use functions pointers via a vtable, which i literally addressed in that same post just without a vtable.

True, but the one of the good things about Python is its large ecosystem.

I won't argue implementation details, but I will ask : isn't the point of OOP to relate a set of data and a set of methods that naturally modify that data in a way that humans can understand? If that's the case, why is it wrong to have function pointers in your struct? Isn't that just another way to do OOP?

I think you mean procedural

It's an inefficient way to do OOP.
If you want to do it that way sure, I won't stop you. But it's just unnecesary data bloat and instructions cycles (when copying structs, and actually calling the methods, for example) to me.
I'd rather just have normal functions that act like methods. They provide basically the same thing with more efficiency.

I might be talking out of my expertise here, but in the given example of a setter method, can't I call foo_method with a void* pointer instead of a struct foo *? Which would make this way unsafe

Yes? so what? Don't do that then.
Use Rust if you're concerned about safety.

>there's no such thing as hackers who decompile binaries to compromise systems.

fuck off

Using Rust won't prevent that from happening.

Here's a better summary:
>C++
Support
>Rust
Safety
>D
Productivity

OP here fuck support; I want both safety and productivity.
I'd pick D but D is kinda slow.

>just as fast as C

more like 4-5 times slower. Which is fine if you're running a simple program that executes on the order of seconds, but not if you're running something that needs to execute on the order of milliseconds or hours.

Stop pulling data out of your ass: benchmarksgame.alioth.debian.org/u64q/rust.html

Apparently there's a lot of data in my ass, since we seem to be using the same source.

Idiot

No, you're using an outdated source from 2 years ago, even in your source it's nowhere near 4-5 times slower, and in the recent update Rust is the closest to C out there.

benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html

Stop posting this shit, the programs are not identical and the task is too small to be a measure of anything.

Point still stands

Noone else took notice of you, user. But just know that I did. I saw when noone else wanted to see. Those who were too cought up in the heated debates bellowing loudly may have turned a blind eye to the humble word play expressed by your heart; by your soul, but I didn't. I listened when noone else wanted to listen. The gloomy sands of life that will eventually fade from every persons possession was momentarily frozen. It was akin to a chance encounter with the humble dandelion struggling to break free from a sea of cold, melancholy cement. For even though the dandelion's colors it may not boast, through time and space will forever be it's underrated post.

Yes but it's NOT C or anywhere close to C. 10-30% is not acceptable when you always have the option of using C and even in some fucked up land where you must use C++, you don't have to learn an entirely new language to do it.

You sound extremely butthurt, user

...

Happy to trade 10-30% performance gain over safety and ease of use/maintaining

So in two years Rust topped C++ and the closest to C? Fascinating. Anything that competes with C++ is fast in my book, if it is faster than C++ it's more performance than I wanted

Rust is nice like that. But the language is very big to master easily.

C++.
Everything with C++ is established, more or less, and way more people use it.
Arguably the best widget library, Qt, works natively with C++.
>Rust
It's more difficult to write, and not many people use it.
Writing correct C++ code is way faster than Rust anyways and it's not even that hard.
It also attracts SJWs, which are to be avoided at all costs if you want to get anything done.
>D
No one uses D, it's slow as fuck, and it has a GC.
Instantly dropped.
>C
Not that great for desktop programs.

Rust is currently faster than C++

>easy = good

Not by that much it looks like, oh well.
It's easier to squeeze every last bit of performance out of C++ than Rust, i'd imagine.
There are still loads of other reasons not to use Rust.

What is the point of this thread? Just use haskell people

>What did he mean by this?

>discuss
>No flame wars
>Posts biased opinions

Yeah ok op. You clearly just want the answer.

Learn to read the thread

>biased opinions
I think they are agreed on facts.

>It matters not, because - even if D or Rust actually become good in the future - the thing that is cancerous in all kinds of flavor is the GUI library. It's all garbage.
I came to tell the same

bogpill me on Rust GUIs vs C GUIs

That question does not make any sense

Who writes GUIs in 2017 tho?

Pleb here. How can I write a GUI library for X or Wayland?

Safe code in C literally does not exist and if you're not going to use any of C's libraries then you might as well use a sane language instead of the antiquated garbage that is C. Hell, writing safe ASM is literally easier than writing safe C.

Nah, because rust is also the more productive of the 3.

>thousands of different ways of doing the same thing

The language is actually smaller than C itself, but the intricacies of the borrow semantics take time to master for sure.

Every coder who needs their code to be used by an end "USER" unless there some other coder who does it for them.

>bogpill me on Rust GUIs vs C GUIs
Never used Rust GUI. Only mess with Qt Framework in C++. It was good but when i compare it with Web GUIs, it feels like all Desktop GUIs are centuries backward.