You want to develop a large desktop application

>+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.

>>59469010
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

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

>>59469595
>C is functional
What?

>>59469729
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.

>>59469010
Rust community isn't that small.

https://github.com/kud1ing/awesome-rust

>>59469125
Not every compiler has implemented C++14 yet

File: reality.png (740KB, 1834x1200px) Image search: [Google]

740KB, 1834x1200px

>>59469010
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.

File: 1468479851395.jpg (30KB, 439x392px) Image search: [Google]

30KB, 439x392px

>>59469595
>C is functional

>>59470060
Seriously?

>>59469010
nyanko is love

>>59470228
See >>59469776

>>59470060
Every important - meaning clang and gcc has, though.

>>59470274
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.

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

>>59469010
C#

File: 1379272606191.jpg (18KB, 512x384px) Image search: [Google]

18KB, 512x384px

>>59470481
>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

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

>>59470060

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

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

>>59470534
>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?

>>59470596
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.

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

File: 1438005654680.jpg (53KB, 403x403px) Image search: [Google]

53KB, 403x403px

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

>>59469640
Script kiddies get out

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

>>59469010
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.

>>59469825
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.

>>59471892
See e.g. >>59456085

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

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

>>59472145
because its an oxide

>>59472145
It's a safety language.

>>59472161
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.

>>59472109
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.

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

>>59472185
This anon 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.

>>59470481
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)

>>59473229
>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.

>>59473312
OOP is just that under the hood.

>>59473329
Structs are not OOP

>>59473229
>>59473312
>>59473329
>>59473785

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.

>>59469776

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

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

>>59470060

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

It can do everything important.

electron w/ react+flow typing

>>59474177
This

>>59473154
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)

>>59474216
Better python is not a bad thing

>>59473229

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.

>>59474216
>a "better Python"
https://nim-lang.org/

>>59474226
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 >>59473229
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.

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

>>59474263

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?

>>59469595
I think you mean procedural

>>59474313
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.

>>59474377

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

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

>>59474480

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

fuck off

>>59474543
Using Rust won't prevent that from happening.

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

File: 16427455.jpg (62KB, 960x864px) Image search: [Google]

62KB, 960x864px

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

>>59469010
>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.

File: rust_vs_c.png (243KB, 665x2557px) Image search: [Google]

243KB, 665x2557px

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

File: image1[1].png (13KB, 512x320px) Image search: [Google]

13KB, 512x320px

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

File: Screenshot from 2017-03-19 08-23-38.png (164KB, 1934x1069px) Image search: [Google]

164KB, 1934x1069px

>>59475269
Idiot

File: how_many_times_slower.png (43KB, 645x364px) Image search: [Google]

43KB, 645x364px

>>59475269
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.

File: 1488577937023.png (81KB, 512x288px) Image search: [Google]

81KB, 512x288px

>>59475269
https://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html

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

>>59475315
Point still stands

>>59472154
Noone else took notice of you, anon. 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.

>>59475293
>>59475294
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.

>>59475330
You sound extremely butthurt, anon

File: Moving-the-goalposts-300x2402.jpg (29KB, 300x240px) Image search: [Google]

29KB, 300x240px

>>59475330

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

>>59475293
>>59475294
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

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

>>59469010
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.

>>59475436
Rust is currently faster than C++

>>59470596
>easy = good

>>59475454
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

>>59475454
>What did he mean by this?

>>59469010
>discuss
>No flame wars
>Posts biased opinions

Yeah ok op. You clearly just want the answer.

>>59476663
Learn to read the thread

>>59477064
>biased opinions
I think they are agreed on facts.

>>59470069
>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

>>59477248
bogpill me on Rust GUIs vs C GUIs

>>59477260
That question does not make any sense

>>59477248
Who writes GUIs in 2017 tho?

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

>>59473228
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.

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

>>59477398
>thousands of different ways of doing the same thing

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

>>59477331
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.

>>59477422
traits

>>59477412
That's objectively a good thing. Different ways have different pros and cons. Not all specific scenarios call for the same tradeoffs.

>>59477444
What about them?

>>59475436
Rust is somewhat easier and much faster to write than correct C++ code. In fact, the only safe types of safe C++ code are those that use reference counting and those that don't exist. That's how hard and slow it is to do that in C++.

>>59469010
>C++
>No memory safety
What fucking year is it? What are std::vector, std::string, std::map, std::shared_ptr and so on? I swear everyone just looked at C++03, went "Nah" and then never looked at the language ever again, missing all the improvements that have been added since. A couple typedefs and you can pretend you're using Java if you really want to.

>>59477495
C++ ugly af

>>59472185
Serious question, does GC not depend on refcounting? How are you supposed to know when to garbage collect without it?

>>59477495
What improvements? Can you give me some articles to read?

>>59477534
https://news.ycombinator.com/item?id=7587978

>>59477526
I have no issue with the syntax, I'm curious, what do you find prettier?

>>59477534
The addition of a plethora of memory safe standard library template classes that get rid of most of the ugly things people complain about with C (needing to remember to destroy stuff, forgetting how big that array was and running off the end, reallocating arrays, fucking strings, etc.).

I mainly learn about what's been added by reading the lists of changes on Wikipedia or just random articles on cppreference when I get bored. Autistic I know.

>>59477529
No. There are many forms of GC but one big difference is how cycles are handled. Mark-and-sweep GCs go over the heap and mark all memory that is reachable, typically starting from a root heap block. Generational GCs can also place the first-generation memory on stack and move it to the heap after a minor collection phase if it's still alive. Eitherway, in doing so, cycles are correctly accounted for. For reference counting, you have to manually adjust the count to get the same safety. In practice, the likes of python, who use refcounting for most memory management, also feature a GC phase to deal with cycles.
Aside from that, refcounting is a lot slower than GC, because GC can basically batch the operations and stop useless operations, whereas refcounting needs an extra 2 ops every time something is shared, and another 2 everytime something goes out of scope. There are also many papers that benchmark refcounting against modern GC techniques and find that GC is much faster if you're interested.

>>59477580
>what do you find prettier?
Let's see you write a C++ program that takes any number of strings, concatenates them and write them to the console, along with its length

>>59477495
std::string still has to be unwrapped (.c_str()) for most functions, which opens you to the same memory issues as usual. shared_ptr is reference counted and needs explicit handling because most code (and all C code) doesn't know about it and expect raw pointers (they don't actually behave the same way). This also opens you up to the same memory issues as usual but also happens to be slow when used in your own code.

Really, if C++ came up with region-based memory enforcement and modules, it would suddenly be great and there would be little to no reason to use anything else, but that's just not the C++ of today.

>>59477580
>what do you find prettier?
Practically anything.

>>59477617
That's not really an answer, but okay.

#include <iostream>

#include <string>
#include <vector>

using namespace std;

int main()
{
    string line;
    vector<string> lines;

    while (getline(cin, line))
    {
        lines.push_back(line);
    }

    string output;

    for (string line: lines)
    {
        output += line;
    }

    cout << output << " " << output.size() << "\n";
}

(Yes, I omitted the const ref declaration to make it look nicer, I'm cheating I know).

>>59470060

If you use VS, eat shit.

>>59477724
I hope you see my point

import std.stdio;

void main(string[] args)
{
    string joined_string;
    foreach(word; args[1..$])
    {
        joined_string ~= word;
    }
    writefln("%s: %s", joined_string, joined_string.length);
}

>>59477635
>std::string still has to be unwrapped (.c_str()) for most functions
This is mainly an issue with older libraries and C libraries, up to date stuff like Boost and many others no longer do this crap. Additionally, I have a 100,000 line C++ project that calls on several libraries with this problem and not once have I incurred a memory issue because of it.

>>59477758
>Boost
Not him, how is Qt?

>>59477758
Not even once do you THINK you incurred a memory issue, that's a big difference.
Yes, new C++ libraries tend to be aware of std::string, but then you have the same issue as usual if you restrain yourself to them: might as well use another language which is better in all ways but doesn't have many libraries available.

>>59477766
Qt does that thing many libraries do where they have their own string class, QString (this is a legitimate criticism of C++ I will accept, this shit needs to end) but you can convert to it from std::string without ever going through .c_str().

>>59477743
No I really don't, because you wrote a significantly simpler program, now that I know what you want more clearly, here's the C++ version:

#include <iostream>

#include <string>
#include <vector>

using namespace std;

int main(int argc, char* argv[])
{
    string output;
    for (int i = 1; i < argc; i++)
    {
        output += argv[i];
    }
    cout << output << " " << output.size() << "\n";
}

Only difference is more two includes and a namespace call.

>>59477789
I've poured over it with Valgrind at length, I'm pretty sure I didn't incur a memory issue (although I'm sure the libraries could be doing some totally off the wall nonsense Valgrind couldn't find). Considering what that .c_str() function actually does, as long the library in question doesn't attempt to store that pointer (which it would want to be insane to do, even in C that's stupid) and as long as your code is thread safe (which it should be anyway) there will be no issue.

>>59477842
>cout << output << " " << output.size() << "\n";
writefln("%s: %s", joined_string, joined_string.length);
>int main(int argc, char* argv[])
void main(string[] args)
Maybe because people have different preferences but I think C++ is not all that beautiful

>>59477882
If you prefer the writefln style, you can swap <iostream> with <cstdio> and use printf("%s: %d\n", output.c_str(), output.size()); instead. But yes, it's still slightly nicer.

The main I'll give you, but anywhere else you can just use vector or a similar container class, that problem is unique to main.

>>59477911
Actually you can also take out the vector include, forgot to remove that when reworking the code.

>>59477911
Well I do like the distinction between %s and %d, in D you just write %s and everything gets inferred - which I don't like for some reason

>>59477842

#include <iostream>
#include <algorithm>
#include <string>

int
main(int argc, char* argv[])
{
  auto output = accumulate(argv + 1, argv + argc, std::string());
  std::cout << output << ' ' << output.size();

  return 0;
}

>>59477495
>what is iterator invalidation
>what is unchecked indexing
>what is use-after-free