November 27, 2017
On Monday, 27 November 2017 at 05:11:06 UTC, Neia Neutuladh wrote:
> You might say that I could use C++ style manual memory management and get even better performance. And you'd be wrong.

No... Not if you do it right, but it takes more planning. I.e. Design. Which is why scripting and high level languages dont use it.

> std::string does the same thing. So if I reimplemented subtex naively in C++, its performance would be closer to the C# version than to the D version.

You meant stupidly, you would rather use std::string_view for string references in C++. std::string is a library convenience type that typically is only used for debugging and filenames. If you want performance then it really isnt possible to make do with a fixed library type for strings so in a realistic program people would write their own.

> I could probably get slightly better performance than the D version by writing a special `stringslice` struct. But that's a lot of work,

No...

> On the whole, it sounds like you don't like D because it's not C++. Which is fine, but D isn't going to become C++.

Sure. But maybe you shouldn't use a tiny 400k input when discussing performance. Try to think about how many instructions a CPU executes in 50ms...

If you dont know C++ then it makes no sense for you to compare performance to C++.

November 27, 2017
On Monday, 27 November 2017 at 01:03:29 UTC, Adam Wilson wrote:
> On 11/26/17 16:14, IM wrote:
>> Hi,
>> I'm a full-time C++ software engineer in Silicon Valley. I've been
>> learning D and using it in a couple of personal side projects for a few
>> months now.
[snip]
>>
>> I could add more, but I'm tired of typing. I hope that one day I will
>> overcome my frustrations as well as D becomes a better language that
>> enables me to do what I want easily without standing in my way.
>
> Well. D has it's own idioms and patterns. So we fully expect some of the idioms that are easy in C++ to be not easy in D, and indeed that's kind of the point. If you look at the those idioms that are hard in D, it's probably because said idiom allows you to do some fantastically unsafe (and insecure) thing in C++. Yes, I am sure that it gives some performance boost, but D is not trying to be the pinnacle of language performance.

It sure does. Otherwise there are plenty languages that are safe and somewhat fast.
C# or Java fit the bill nicely. Also Go.

> D is trying to be a memory-safe language, quite intentionally

And thus @system is the default, right?
I think memory safety came as an afterthought.

> at the expense of speed (see this DConf 2017 talk: https://www.youtube.com/watch?v=iDFhvCkCLb4&index=1&list=PL3jwVPmk_PRxo23yyoc0Ip_cP3-rCm7eB). Bounds checking by default, GC, etc. are all memory safety features that come explicitly at the cost of performance.
>
> We are not trying to be C++

True, albeit doesn’t feel like that.

> and we are not trying to replace C++

Patently false.

> It sounds like C++ works better for you. We are OK with that. We always recommend using what works best for you. That is after all why WE are here. :)

That WE might have been just you :)
D certainly tries to replace C++ in a number of ways. It’s not a drop-in replacement and doesn’t cover all of C++ niche.


November 26, 2017
On 11/26/2017 9:11 PM, Neia Neutuladh wrote:
> The culprit for the C# version's poor performance was System.String.Substring, which allocates a copy of its input data. So "Hello world".Substring(5) creates a new char* pointing at a new memory allocation containing "Hello\0". C++'s std::string does the same thing. So if I reimplemented subtex naively in C++, its performance would be closer to the C# version than to the D version.
> 
> I could probably get slightly better performance than the D version by writing a special `stringslice` struct. But that's a lot of work, and it's currently just barely fast enough that I realize that I've actually run the command instead of my shell inexplicably swallowing it.

0 terminated strings in C (and C++) have always been a severe performance issue for programs that deal a lot in strings, for these reasons:

1. To get a substring, a copy must be made, meaning also that storage allocated and managed for it.

2. To do most operations on it, you need to do a strlen() or equivalent.

You can always write your own string package to deal with, and I've written many :-( and they all failed for one reason or another, mostly because about everything in the C/C++ ecosystem is built around 0 terminated strings.


November 27, 2017
On Monday, 27 November 2017 at 03:01:24 UTC, Jon Degenhardt wrote:
> Forum discussions are valuable venue. Since you are in Silicon Valley, you might also consider attending one of the Silicon Valley D meetups (https://www.meetup.com/D-Lang-Silicon-Valley). It's hard to beat face-to-face conversations with other developers to get a variety of perspectives. The ultimate would be DConf, if you can manage to attend.

Thanks. I intend to attend some of their meetup events.
November 27, 2017
On Monday, 27 November 2017 at 05:11:06 UTC, Neia Neutuladh wrote:
> On Monday, 27 November 2017 at 00:14:40 UTC, IM wrote:
>> - ‎It's quite clear that D was influenced a lot by Java at some point, which led to borrowing (copying?) a lot of Java features that may not appeal to everyone.
>
> Have you observed a human to exist who has complained about a specific feature in D that is similar to a feature in Java? Relaying their complaints would be much more useful.
>

Yes, in particular All classes inherit from `Object`, virtual methods by default, inner classes pointers to parent classes ... to name a few.
November 27, 2017
On Monday, 27 November 2017 at 02:56:34 UTC, Walter Bright wrote:
> On 11/26/2017 4:14 PM, IM wrote:
>> I'm a full-time C++ software engineer in Silicon Valley. I've been learning D and using it in a couple of personal side projects for a few months now.
>
> Great! Glad you're enjoying it and took the time to post your thoughts.
>
>
>> - D is unnecessarily a huge language. I remember in DConf 2014, Scott Meyers gave a talk about the last thing D needs, which is a guy like him writing a lot of books covering the many subtleties of the language. However, it seems that the D community went ahead and created exactly this language!
>
> You'll find the same language in 2014 as today, it hasn't changed much. All languages (except C) in common use accrete features.
>
> D does have some baggage that has been removed, like `typedef`, but on the whole whenever we try to remove something, someone always has built their store around it.
>
> The good news, however, is just use the subset of D that works for you.
>
>
>> - ‎D is very verbose. It requires a lot of typing. Look at how long 'immutable' is. Very often that I find myself tagging my methods with something like 'final override nothrow @safe @nogc ...' etc.
>
> The idea is if you just want to write code, you can eschew using them (except 'override'), and just write code. They're all used for optimization or to provide enforceable self-documentation. Other languages would require those to be documented in the comments, which is not enforceable and even more wordy :-)
>
> 'override' is as opposed to 'virtual' which C++ requires and D doesn't.
>
>
>> - ‎It's quite clear that D was influenced a lot by Java at some point, which led to borrowing (copying?) a lot of Java features that may not appeal to everyone.
>
> That's true. Java looked like it was going to take over the world when D was young. These days I'd get rid of inner classes in favor of lambdas if I could, but you can just ignore inner classes.
>
>
>> - ‎The amount of trickeries required to avoid the GC and do manual memory management are not pleasant and counter productive. I feel they defeat any productivity gains the language was supposed to offer.
>
> That's true. But it's hard to beat GC for just writing code and getting it to run safely and without pointer bugs.
>
>
>> - ‎The thread local storage, shared, and __gshared business is annoying and doesn't seem to be well documented, even though it is unnatural to think about (at least coming from other languages).
>
> The idea with TLS is to deal with endemic threading bugs other languages have. The default in C/C++ is for globals to be shared, which is completely impractical to examine a large code base for. __gshared is meant to stand out and be greppable, making code much more auditable.
>
>
>> - ‎D claims to be a language for productivity, but it slows down anyone thinking about efficiency, performance, and careful design decisions. (choosing structs vs classes, structs don't support hierarchy, use alias this, structs don't allow default constructors {inconsistent - very annoying}, avoiding the GC, look up that type to see if it's a struct or a class to decide how you may use it ... etc. etc.).
>
> D structs are value types, and classes are reference types. Everything flows from that. C++ structs and classes are the same thing, and can be used as both reference and value types at the same time, whether that works or not. I rarely find C++ classes with documentation saying if they are intended as a reference or value type, and the documentation won't prevent one from misusing it.
>
> I'm not the only one to suggest that making the value/ref design decision is a pretty crucial one to make before designing the code. :-)
>
>
>> I could add more, but I'm tired of typing. I hope that one day I will overcome my frustrations as well as D becomes a better language that enables me to do what I want easily without standing in my way.
>
> Many people have difficulty with D when coming from, say, C++, because it does require a different way of thinking about code. This passes once one gains experience and comfort with D. After all, my early Fortran code looked just like BASIC, my C code looked like Fortran, my C++ code looked like "C with a few classes", and my D code looked a bit too much like C++ :-)
>
> I have recently finished converting the Digital Mars C++ compiler front end from "C with classes" to D. Even though it is a rote line-by-line translation, it simply looks better in D (much less of a snarl). Over time, as I refactor bits of it, it'll steadily look better. I find it significantly easier to write good looking code in D, and it is less verbose than C++.
>
> For some trivial examples,
>
>     C++: unsigned long long
>     D: ulong
>
>     C++: template<typename T> struct S { ... };
>     D: struct S(T) { ... }
>
>     C++: for (int i = 0; i < 10; ++i)
>     D: foreach (i; 0..10)
>
>     C++: decltype
>     D: auto

Thank you Walter, and all for your replies.

I want to re-state that I really like D, *despite* of feeling frustrated with it sometimes. I only mentioned in my post some of the things I don't like about D, but I didn't mention the many things I _DO_ like about it, but that's not the point now.

I intend to stick with D for a while. I bought all the available books about D I could find and reading through them. I watched many of the DConf videos, and I read the (weekly?) blog post. I also intend to write a doc introducing D and its benefits to my co-workers and colleagues, suggesting that we could use it in some areas where it makes sense, but my D knowledge isn't quite there yet. Also I won't be able to write it until I manage to overcome my points of frustration with the language.

My plan to overcome my frustration is:
- Continue learning and experimenting with D.
- Stop thinking about D as C++ with slightly better syntax, and do a paradigm shift.

What I hope to see in D in the feature:
- Sane correct defaults (as someone mentioned above, @safe by default for instance?).
- More exposure. I sometimes feel like there isn't enough D material to consume on a regular basis (and I and certainly many others are eager to learn more and more about the language). i.e. one blog post (weekly?), and a single DConf annually is not enough. In the C++ world, there's always something to read (various blog posts) or something to watch (CppCon, C++Now, Meeting C++, code::dive, Pacific++, ...etc.)

Thank you all for the hard work that I really appreciate!



November 27, 2017
On Monday, 27 November 2017 at 07:58:27 UTC, IM wrote:
> On Monday, 27 November 2017 at 03:01:24 UTC, Jon Degenhardt wrote:
>> Forum discussions are valuable venue. Since you are in Silicon Valley, you might also consider attending one of the Silicon Valley D meetups (https://www.meetup.com/D-Lang-Silicon-Valley). It's hard to beat face-to-face conversations with other developers to get a variety of perspectives. The ultimate would be DConf, if you can manage to attend.
>
> Thanks. I intend to attend some of their meetup events.

I'll be giving a presentation on Thursday evening on using D for (among other things) GPGPU, hope you can make it!
November 27, 2017
On Monday, 27 November 2017 at 09:07:10 UTC, Nicholas Wilson wrote:
> On Monday, 27 November 2017 at 07:58:27 UTC, IM wrote:
>> On Monday, 27 November 2017 at 03:01:24 UTC, Jon Degenhardt wrote:
>>> Forum discussions are valuable venue. Since you are in Silicon Valley, you might also consider attending one of the Silicon Valley D meetups (https://www.meetup.com/D-Lang-Silicon-Valley). It's hard to beat face-to-face conversations with other developers to get a variety of perspectives. The ultimate would be DConf, if you can manage to attend.
>>
>> Thanks. I intend to attend some of their meetup events.
>
> I'll be giving a presentation on Thursday evening on using D for (among other things) GPGPU, hope you can make it!

Any chance it gets recorded? I'd be highly interested!
November 27, 2017
On Monday, 27 November 2017 at 10:11:40 UTC, Zoadian wrote:
> On Monday, 27 November 2017 at 09:07:10 UTC, Nicholas Wilson wrote:
>> On Monday, 27 November 2017 at 07:58:27 UTC, IM wrote:
>>> On Monday, 27 November 2017 at 03:01:24 UTC, Jon Degenhardt wrote:
>>>> [...]
>>>
>>> Thanks. I intend to attend some of their meetup events.
>>
>> I'll be giving a presentation on Thursday evening on using D for (among other things) GPGPU, hope you can make it!
>
> Any chance it gets recorded? I'd be highly interested!

We'll try, but I'm lead to believe the track record is not great, though it has worked before.
I'll see if I can record on my end as well.
November 27, 2017
On Monday, 27 November 2017 at 01:05:08 UTC, codephantom wrote:
> On Monday, 27 November 2017 at 00:14:40 UTC, IM wrote:
>> - D is unnecessarily a huge language. I remember in DConf 2014, Scott Meyers gave a talk about the last thing D needs, which is a guy like him writing a lot of books covering the many subtleties of the language. However, it seems that the D community went ahead and created exactly this language!
>
> I hear this argument a lot, about this language or that.
>
> It has become an argument void of any real value, in my view.
>
> The reason is, programming needs have changed a lot, the problems being solved have changed alot, there is a great diversity in how people think about solving those problems, and a greater need to solve problems that are not solvable with current langauges.

+1: I'd say D is sufficiently sized for the things I try to accomplish -- meaning I wouldn't want it to be smaller. I am not aware of any other language that is as much an enabler as D is. D allows magic to happen when you need magic, although it arguably takes time to learn to be a magician. The good thing is that, simultaneously, people can be productive (safely) writing ordinary code without the need to be an expert.