On Wednesday, 23 January 2019 at 16:47:04 UTC, Neia Neutuladh wrote:
> 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?

Go is garbage and it's only popular because Google is behind it.

It has absolutely nothing to do with the language itself.

On Wednesday, 23 January 2019 at 12:26:02 UTC, rikki cattermole wrote:
> 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.

Java is going to get CSP-style concurency as in Go probably in JDK13. It's called Project Loom. Here is a presentation by Mark Reinhold (Java project lead at Oracle) where he is presenting a preview of JDK13 and Project Loom:

https://www.youtube.com/watch?time_continue=4125&v=nKJbDYRsO0s (starting at 1:08:47)

This will create some competition for Go what the multi-threading model is concerned. Java is better than Go otherwise in every aspect except memory consumption.

On Wednesday, 23 January 2019 at 18:42:06 UTC, bauss wrote:

> Go is garbage and it's only popular because Google is behind it.
>
> It has absolutely nothing to do with the language itself.

I don't know if I'd agree that it's garbage - it has a lot of appeal to certain types of programmers, though not to me - but I do agree that it's popular (to whatever extent it is) because of Google. I remember when the language was first announced, there were a lot of people excited by the prospect that GOOGLE IS CREATING A LANGUAGE. IT HAS TO BE AWESOME. These were not people who tried the language and found it to be better than the alternatives. They were people who hadn't even seen it. That was back in the days when Microsoft was the devil and Google were the good guys.

Of course, one could argue that it must have offered enough to keep some of them interested. They were able to get stuff done when they used it.

On Thursday, 24 January 2019 at 14:44:07 UTC, bachmeier wrote:
> Of course, one could argue that it must have offered enough to keep some of them interested. They were able to get stuff done when they used it.

The build in and good performing http server hit the sweet spot. Never underestimate the desire of people to simply get going fast.

As a developer, you can be assured that your Go HTTP server will survive a upgrade to a new major release version. That assurance is a bit less with D. ;)

One of D its weak spots, that its so general positioned as a C++ replacement, that it lacks a identify for itself.

On Thursday, 24 January 2019 at 23:02:07 UTC, Ben wrote:
> On Thursday, 24 January 2019 at 14:44:07 UTC, bachmeier wrote:
>> Of course, one could argue that it must have offered enough to keep some of them interested. They were able to get stuff done when they used it.
>
> The build in and good performing http server hit the sweet spot. Never underestimate the desire of people to simply get going fast.
>
> As a developer, you can be assured that your Go HTTP server will survive a upgrade to a new major release version. That assurance is a bit less with D. ;)
>
> One of D its weak spots, that its so general positioned as a C++ replacement, that it lacks a identify for itself.

Yes!

The following idea was written by several posters:
Keep std. small, but offer a special label "recommended by D Foundation"
for some more packages available via code.dlang (DUB)

This would mean, that some of them, currently under individual control are moved to the official D Foundation Git repository.

So those could be kept up to date, to ensure no breakage when the language evolves.

( On my wish list at the top: An official D database connector. (MySql/MariaDB, Postgres, SQlite, MonetDB..) )

What about trying to find and to fund a maintainer for this purpose?
(Next funding goal Mike Parker?)

On Friday, 25 January 2019 at 10:15:15 UTC, Martin Tschierschke wrote:
> ( On my wish list at the top: An official D database connector. (MySql/MariaDB, Postgres, SQlite, MonetDB..) )
>
> What about trying to find and to fund a maintainer for this purpose?
> (Next funding goal Mike Parker?)

I think it requires an official API specification like DB-API in Python.

Being a general-purpose programming language, D introduces some fragmentation inside its community. For example, some people don't want to use the GC, but some people do.

So the API probably need to take such points into consideration.

And I could say the same for HTTP-related standards. Take a look at what PHP has:
https://www.php-fig.org/psr/psr-7/
https://www.php-fig.org/psr/psr-18/

Regarding the killer feature:

I have a strong feeling that D would perfectly fit the web application development scenario.
The HTTP protocol is stateless by its nature, so it's theoretically possible to use a region-based allocation strategy for HTTP request handling. This is where the precise GC might play a better role, BTW.

Also, D has much closer syntax to JavaScript, which means this may help to decrease frustration switching between different backend and frontend languages when you develop a web app (if I'm correct, this problem is solved only in Clojure/ClojureScript today).

In addition, I guess that it's totally possible to write a TypeScript-like transpiler for D, which can help to bring type safety to the frontend.

On Friday, 25 January 2019 at 11:07:48 UTC, Jacob Shtokolov wrote:
> This is where the precise GC might play a better role, BTW.

Misspelling: not precise, conservative GC of course.