On Wednesday, 8 January 2014 at 23:43:43 UTC, NoUseForAName wrote:
> Looks pretty boring/conventional to me. If you know many programming languages you immediately recognize "let" as a common keyword for assignment.

Yes, but I cannot think of a single one of them that I would like to use! ;-)

> That leaves only the funny sounding "mut" as slightly unusual. It is the result of making immutable the default which I think is a good decision.

Agree on the last point, immutable should be the default. Altough I think they should have skipped both "let" and "mut" and used a different symbol for initial-assignment instead.

> (I am not part of that majority, though). I mean C gave us classics like "atoi".. still reminds me of "ahoi" every time I read it. And I will never get over C++'s "cout" and "cin". See?

I don't mind cout, I hardly use cin, I try to avoid cerr, and I've never used clog… I mind how you configure iostreams though. It looks worse than printf, not sure how they managed that.

> Rust makes C/C++ damaged people feel right at home even there ;P

Well, I associate "let" with the functional-toy-languages we created/used at the university in the 90s so I kind of have problem taking Rust seriously. And the name? RUST? Decaying metal. Why? It gives me the eerie feeling that the designers are either brilliant, mad or both, or that it is a practical joke. I'm sure the compiler randomly tells you Aprils Fools! Or something.

Thanks. Not many votes though given all the downvotes. The comments manage to be even worse than on my first blog post.

For some reason they all assume I don't know C++ even though I know it way better than D, not to mention that they nearly all miss the point altogether. Sigh.

On Wednesday, 8 January 2014 at 18:59:45 UTC, Paulo Pinto wrote:
> Am 08.01.2014 19:31, schrieb Atila Neves:
>> I don't know if I have enough rep for it, I'd appreciate it if someone
>> who does posts it there.
>>
>> On Wednesday, 8 January 2014 at 18:24:00 UTC, bearophile wrote:
>>> Atila Neves:
>>>
>>>> http://atilanevesoncode.wordpress.com/2014/01/08/adding-java-and-c-to-the-mqtt-benchmarks-or-how-i-learned-to-stop-worrying-and-love-the-garbage-collector/
>>>>
>>>
>>> Going to Reddit?
>>>
>>> Bye,
>>> bearophile
>>
>
> Done
>
> http://www.reddit.com/r/programming/comments/1uqabe/adding_java_and_c_to_the_mqtt_benchmarks_or_how_i/
>
> http://www.reddit.com/r/d_language/comments/1uqa4d/adding_java_and_c_to_the_mqtt_benchmarks_or_how_i/
>
> --
> Paulo

> No, this expierence is not only based of this. I observed multiple discussions on the newsgroup, where turning off the GC would speed up the program by factor 3. The most recent one was

The GC doesn't even show up in the profiler for this/my use case. The one optimisation I did to avoid allocations increased performance by all of 5%. It really depends on the use case, and I don't think assuming a factor of 3 is advisable.

> That is another common argument of pro GC people I have never seen in partice yet. Meaning, I never seen a case where freeing a tree of objects would cause a significant enough slowdown. I however saw lots of cases where a garbage collection caused a significant slowdown.

Well, if I wasn't aware of allocation I wouldn't have done the optimisation mentioned above, so it's a good point.

As far as slowdown happening with manual memory management, in certain cases cleaning up reference counted smart pointers can cause as much of a slowdown as a GC kicking in. This isn't my opinion though, there are data to that effect. Again, it depends on the use case.

> Still it only solves half the problem.

Maybe in Java. In D at least we have struct destructors for other resources.

> It was never intended to. I just wanted to make the point, that even if you want, you can't avoid C++.

A fair point. I think what we're saying is not that we won't ever write C++ again, but that we won't write it again if given the choice and if another language (not necessarily D) is also a good fit.

I'd be surprised if I wasn't still writing / refactoring / debugging C++ code a few decades for now. I don't want to write C again ever, but I know I'll have to.

> I fully agree here. Still when choosing a programming language you also have to pick one that all programmers on the team can and want to use. I fear that the D metaprogramming capabilities will scare of quite a few programmers because it seems to complicated to them. (Its really the same with C++ metaprogramming. Its syntactically ugly and verbose, but gets the job done, and is not so complicated if you are familiar with the most important concepts).

I disagree wholeheartedly. It's a _lot_ more complicated in C++. D can also do more than C++, with far saner syntax.

On Wed, Jan 08, 2014 at 11:59:58PM +0000, digitalmars-d-bounces@puremagic.com wrote:
> On Wednesday, 8 January 2014 at 23:43:43 UTC, NoUseForAName wrote:
[...]
> >(I am not part of that majority, though). I mean C gave us classics like "atoi".. still reminds me of "ahoi" every time I read it. And I will never get over C++'s "cout" and "cin". See?

The absolute worst offender from the C days was creat(). I mean, seriously?? I'm actually a fan of abbreviated names myself, but that one simply takes it to a whole 'nother level of wrong.


> I don't mind cout, I hardly use cin, I try to avoid cerr, and I've never used clog… I mind how you configure iostreams though. It looks worse than printf, not sure how they managed that.
[...]

I hate iostream with a passion. The syntax is only the tip of the proverbial iceberg. Manipulators that change the global state of the output stream, pathologically verbose ways of controlling output format (cout << setprecision(5) << num; -- really?!) that *also* modifies global state, crazy choice of output operator with counter-intuitive operator precedence (cout << a&b doesn't do what you think it does), ... I have trouble finding what's there to like about iostream.

Even when I was still writing C++ a few years ago, I avoided iostream like the plague. For all of its flaws, C's stdio is still far better than iostream in terms of everyday usability. At least for me. YMMV.


T

-- 
Marketing: the art of convincing people to pay for what they didn't need before which you can't deliver after.

On Thursday, 9 January 2014 at 00:52:04 UTC, H. S. Teoh wrote:
> The absolute worst offender from the C days was creat().

That's unfair, that's unix, not C!

http://linux.die.net/man/3/explain_creat_or_die

On Thu, Jan 09, 2014 at 01:06:01AM +0000, digitalmars-d-bounces@puremagic.com wrote:
> On Thursday, 9 January 2014 at 00:52:04 UTC, H. S. Teoh wrote:
> >The absolute worst offender from the C days was creat().
> 
> That's unfair, that's unix, not C!
> 
> http://linux.die.net/man/3/explain_creat_or_die

That's why I said "from the C days", not "in C". :) Remember that C was created... um, creat-ed... in order to write Unix.


T

-- 
Gone Chopin. Bach in a minuet.

On Thursday, 9 January 2014 at 01:26:27 UTC, H. S. Teoh wrote:
> That's why I said "from the C days", not "in C". :) Remember that C was
> created... um, creat-ed... in order to write Unix.

Yes, but you have to take into consideration that there are over twice as many anagrams for "creat" than for "create", so "creat" is clearly more versatile. There are no anagrams for "unix".

On 1/8/2014 12:23 PM, Benjamin Thaut wrote:
> Additionaly programming with a GC often leads to a lot more allocations,

I believe that this is incorrect. Using GC leads to fewer allocations, because you do not have to make extra copies just so it's clear who owns the allocations.

For example, if you've got an array of char* pointers, in D some can be GC allocated, some can be malloc'd, some can be slices, some can be pointers to string literals. In C/C++, the array has to decide on an ownership policy, and all elements must conform.

This means extra copies.

On Thursday, 9 January 2014 at 01:06:03 UTC, Ola Fosheim Grøstad
wrote:
> On Thursday, 9 January 2014 at 00:52:04 UTC, H. S. Teoh wrote:
>> The absolute worst offender from the C days was creat().
>
> That's unfair, that's unix, not C!
>
> http://linux.die.net/man/3/explain_creat_or_die

But that just means the same people are responsible.

On 9 January 2014 13:08, Walter Bright <newshound2@digitalmars.com> wrote:

> On 1/8/2014 12:23 PM, Benjamin Thaut wrote:
>
>> Additionaly programming with a GC often leads to a lot more allocations,
>>
>
> I believe that this is incorrect. Using GC leads to fewer allocations, because you do not have to make extra copies just so it's clear who owns the allocations.
>

You're making a keen assumption here that C programmers use STL. And no
sane programmer that I've ever worked with uses STL precisely for this
reason :P
Sadly, being conscious of eliminating unnecessary copies in C/C++ takes a
lot of work (see: time and money), so there is definitely value in
factoring that problem away, but the existing GC is broken. Until it
doesn't leak, stop the world, and/or can run incrementally, it remains no
good for realtime usage.
There were 2 presentations on improved GC's last year, why do we still have
the lamest GC imaginable? I'm still yet to hear any proposal on how this
situation will ever significantly improve...

*cough* ARC...

For example, if you've got an array of char* pointers, in D some can be GC
> allocated, some can be malloc'd, some can be slices, some can be pointers to string literals. In C/C++, the array has to decide on an ownership policy, and all elements must conform.
>
> This means extra copies.
>