On Wednesday, 23 January 2019 at 09:14:18 UTC, Bienlein wrote:
> On Friday, 18 January 2019 at 08:55:23 UTC, Paulo Pinto wrote:
>> D really needs its killer use case if it is to move away from that list.
>
> D is a lot like Scala on the JVM: Both language have myriads of language features and bells and whistles, but there is no killer feature in the language itself.

For me the killer feature is meta-programming. No other language comes close.

Take the wasm-reader [1] library I recently wrote for instance. While not feature complete - nor a fair direct comparison - it is far less code than anything in C++ [2] or Rust [3].

[1] https://github.com/skoppe/wasm-reader/blob/master/source/wasm_reader/reader.d
[2] https://github.com/WebAssembly/binaryen/blob/master/src/wasm/wasm-binary.cpp
[3] https://github.com/rustwasm/twiggy/blob/master/parser/wasm_parse/mod.rs

On Wednesday, 23 January 2019 at 09:58:05 UTC, Sebastiaan Koppe wrote:
> On Wednesday, 23 January 2019 at 09:14:18 UTC, Bienlein wrote:
>> On Friday, 18 January 2019 at 08:55:23 UTC, Paulo Pinto wrote:
>>> D really needs its killer use case if it is to move away from that list.
>>
>> D is a lot like Scala on the JVM: Both language have myriads of language features and bells and whistles, but there is no killer feature in the language itself.
>
> For me the killer feature is meta-programming. No other language comes close.

It's a nice feature, but won't make any startup company choose D or any other company as the language for their next software product.

On Wednesday, 23 January 2019 at 11:42:24 UTC, Bienlein wrote:
> On Wednesday, 23 January 2019 at 09:58:05 UTC, Sebastiaan Koppe wrote:
>> On Wednesday, 23 January 2019 at 09:14:18 UTC, Bienlein wrote:
>>> On Friday, 18 January 2019 at 08:55:23 UTC, Paulo Pinto wrote:
>>>> D really needs its killer use case if it is to move away from that list.
>>>
>>> D is a lot like Scala on the JVM: Both language have myriads of language features and bells and whistles, but there is no killer feature in the language itself.
>>
>> For me the killer feature is meta-programming. No other language comes close.
>
> It's a nice feature, but won't make any startup company choose D or any other company as the language for their next software product.

Well, the truth is, people don't come to a language because of a killer feature. Sometimes it's even the opposite. Java and Dart are familiar to some extent because of lack of killer features. But what they might lack in "expressiveness", they make up for with amazing ecosystem and IDE support (which is usually inversely proportional to language expressiveness). I can't think of any language that is popular just because of language features. Python? Not really, it has a great standard library, a broad ecosystem of libraries for networking, science etc. Rust? Not really. While their memory management features are cool, many people flock to Rust because of its rapidly growing ecosystem and a good strategy/project scope management.

On 24/01/2019 1:20 AM, JN wrote:
> Well, the truth is, people don't come to a language because of a killer feature. Sometimes it's even the opposite. Java and Dart are familiar to some extent because of lack of killer features.

Actually that isn't quite true.

Java's killer feature is consistent simplicity. That is how it was originally sold to great success. The ecosystem and tooling came later.

Also as an FYI, Rust has had significant marketing effort put into it. Consider its home page, it tells a story to get you into developing code fast. D's doesn't. It is much better and I think it might be time to have a complete rethink of D's because the last redesign wasn't all that different to what it was prior.

On Wednesday, 23 January 2019 at 12:26:02 UTC, rikki cattermole wrote:
> Java's killer feature is consistent simplicity. That is how it was originally sold to great success. The ecosystem and tooling came later.

Also, the Internet was Java's killer application. No other language had the libraries for accessing the Internet easily. Then there is dynamic class loading. This made things a little bit more unsafe at runtime but in general developer productivity rose sharply, comparable to Smalltalk and by order of magnitude compared to C++. At that time the competition for Java was only Smalltalk and C++. Performance was nevertheless good, because of runtime code optimization (HotSpot), which was a new thing (albeit taken from Strongtalk, some Smalltalk high performance variant)

On Wednesday, 23 January 2019 at 12:26:02 UTC, rikki cattermole wrote:

> Also as an FYI, Rust has had significant marketing effort put into it. Consider its home page, it tells a story to get you into developing code fast. D's doesn't. It is much better and I think it might be time to have a complete rethink of D's because the last redesign wasn't all that different to what it was prior.

I've made this comparison many times before, but I'll do it again...

Look at what Rust offers as documentation for Cargo:
https://doc.rust-lang.org/cargo/index.html

This is what you get with Dub:
https://dub.pm/getting_started

One is professional documentation, the other was something hacked together by a sixth grader over the weekend. The Dub documentation is good through the part demonstrating `dub init`, then it falls apart. It talks about two configuration file formats - not one, but two ("use whichever you prefer") and I have no idea there is even a discussion of configuration file formats at that point. Then there's a link to this word dump https://dub.pm/package-format-json.html.

Noticeably absent: how I'm supposed to *use* Dub. Where do I put my source files? How do I add dependencies? Have you ever heard of an example?

Then a little below that is a link to this page: https://dub.pm/publish.html. I wonder what that is for. Can't make heads or tails out of that.

This is *introduction to the language*. If someone sees that and doesn't run away, there's something wrong. I most definitely would have gone with Rust if it had been usable when I started using D. The Dub documentation makes it really hard to bring in users - and makes Rust look like a sane language in comparison.

On Wednesday, 23 January 2019 at 14:14:06 UTC, bachmeier wrote:
> I've made this comparison many times before, but I'll do it again...
>
> Look at what Rust offers as documentation for Cargo:
> https://doc.rust-lang.org/cargo/index.html
>
> This is what you get with Dub:
> https://dub.pm/getting_started
>
> One is professional documentation, the other was something hacked together by a sixth grader over the weekend. The Dub documentation is good through the part demonstrating `dub init`, then it falls apart. It talks about two configuration file formats - not one, but two ("use whichever you prefer") and I have no idea there is even a discussion of configuration file formats at that point. Then there's a link to this word dump https://dub.pm/package-format-json.html.
>
> Noticeably absent: how I'm supposed to *use* Dub. Where do I put my source files? How do I add dependencies? Have you ever heard of an example?
>
> Then a little below that is a link to this page: https://dub.pm/publish.html. I wonder what that is for. Can't make heads or tails out of that.
>
> This is *introduction to the language*. If someone sees that and doesn't run away, there's something wrong. I most definitely would have gone with Rust if it had been usable when I started using D. The Dub documentation makes it really hard to bring in users - and makes Rust look like a sane language in comparison.

This is all true, but you need to keep in mind that Go had no real package manager for a long time. There was the "go get" command which loaded the code from some github repo in the state it was at the time when being loaded. There was no version control. Nobody really cared (the vendor stuff in Go was added with Go 1.10 or 1.11). Goroutines were the killer feature of the language that paved the way, because this was badly needed for writing server-side software.

I don't think D will have some killer app in the mid-term future. So what is left is to put a killer feature into the language like CSP or safe manual memory management or something.

On Wednesday, 23 January 2019 at 13:03:18 UTC, Bienlein wrote:
>
> Also, the Internet was Java's killer application. No other language had the libraries for accessing the Internet easily. Then there is dynamic class loading. This made things a little bit more unsafe at runtime but in general developer productivity rose sharply, comparable to Smalltalk and by order of magnitude compared to C++. At that time the competition for Java was only Smalltalk and C++. Performance was nevertheless good, because of runtime code optimization (HotSpot), which was a new thing (albeit taken from Strongtalk, some Smalltalk high performance variant)

I would think that dynamic class loading is something that could be bolted on to C++ (and presumably D as well), albeit awkwardly.

On Wednesday, 23 January 2019 at 15:04:00 UTC, jmh530 wrote:
> I would think that dynamic class loading is something that could be bolted on to C++ (and presumably D as well), albeit awkwardly.

Dynamic class loading means there is no more link step.

On Wed, 23 Jan 2019 14:37:30 +0000, Bienlein wrote:
> This is all true, but you need to keep in mind that Go had no real package manager for a long time. There was the "go get" command which loaded the code from some github repo in the state it was at the time when being loaded. There was no version control. Nobody really cared (the vendor stuff in Go was added with Go 1.10 or 1.11). Goroutines were the killer feature of the language that paved the way, because this was badly needed for writing server-side software.

Go has several killer features:
* It's got a GC and yet is endorsed by one of the major people behind C.
This helps people get over their fear of garbage collection and into
appreciating the benefits.
* It's also got "pointers". They're actually references with pointer-ish
syntax, but that makes people coming from C/C++ more comfortable.
* It's not Java, and it's not slower than Java.
* There was a team in Google that would rewrite old, crufty C++ code in
Go. Was Go a benefit? Maybe in some ways, but the major benefit was a
rewrite that the owning team didn't have to do. That earned goodwill among
thousands of developers attached to Go as a language.
* It's backed by Google (in large part because of that goodwill).

I don't think fibers are all that important for Go's success. Maybe for people who would have looked at node.js but didn't want to use javascript?