On Monday, 29 January 2018 at 11:48:07 UTC, Russel Winder wrote:
> [...]
> One thing that Go got almost right was the way of using FOSS packages and libraries. Rust, via Cargo, did a much better job. Go has a small standard library and allows use of any DVCS, there is no central contributed system. Rust/Cargo has a small standard library, a central contributed library, and the ability to use arbitrary DVCS. Rust/Cargo wins on this hands down. I suggest Dub needs more work to be like Cargo. This and documentation strike me as the most important things for the evolution of D.
> [...]

What would you say are the most important differences between dub and Cargo? What does Cargo do better than dub (or worse for that matter)? Superficially, they seem to be designed quite similarly.

Mafi

On Monday, 29 January 2018 at 03:22:54 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 28 January 2018 at 23:09:00 UTC, Michael wrote:
>> by the whole target audience. Rust, on the other hand, seems to be picking up those who have left Go.
>
> I guess some go to Rust after working with Go, but the transition matrix linked above suggests that the trend has been that people give up on Rust and try out Go then Python... Of course, with so little data things are uncertain and can change.

I would hazard a guess that Go is likely the language they settle on for whatever task required something more low-level like Rust/Go(/D? =[ ) and that they move to Python for the kinds of scripting tasks that follow development of something in the previous languages.

On Monday, 29 January 2018 at 05:21:14 UTC, jmh530 wrote:
> I don't deny that there are limitations to the data. At best, it would be telling you the transition of github users over a specific period.

Sure, but I don't think there are enough D github-repositories to get decent quantitative analysis... Maybe a qualitative analysis.

On Monday, 29 January 2018 at 22:28:35 UTC, Michael wrote:
> I would hazard a guess that Go is likely the language they settle on for whatever task required something more low-level like Rust/Go(/D? =[ ) and that they move to Python for the kinds of scripting tasks that follow development of something in the previous languages.

That could be, many have Python as a secondary high level language.

On Sunday, 28 January 2018 at 00:47:23 UTC, bachmeier wrote:
> On Saturday, 27 January 2018 at 20:15:51 UTC, aberba wrote:
>> There have been several complaints about tools, and certain important stuff missing in the standard library (HTTP/HTTP2, rpc, etc) and no 'official' response or some blog post from them about it (whether they even care).
>
> The community will have to do this.
They are part of the community. I'm not saying Andrei or Walter should write an http/https2, json,  etc.
 lib. They need to actively help build and grow the community/workforce that collectively make those things happen. Or pay someone part-time or full time to do that.

> If Walter and Andrei were interested in it, they'd have been working on it long ago. They have way too much to do the way it is,
They speak for themselves.

> and as soon as it becomes official, there are rules and rules about rules and six levels of bureaucracy.
I did say those things are missing in the standard library but it doesn't have to be in Phobos to receive upstream support.


There are a list of things developers need to build killer apps and web services in D. The larger the workforce,  the more likely we get people to contribute in those areas (theory,  code, tools,  documentation,  tutorials,  libraries, promotions, solutions, etc). And those things are equally important in every popular programming language today to continue to gain wider adoption.

On Sunday, 28 January 2018 at 18:54:34 UTC, Laeeth Isharc wrote:
> On Sunday, 28 January 2018 at 13:50:03 UTC, Michael wrote:
>> I do worry that, having been using D for about 3 1/2 years now, that the perceptions of D outside of this community don't seem to be changing much. It does seem to make a huge difference to have a big company behind a language, purely for the "free advertisement". Most people at my university, outside of the computer science department, that are using languages like Python and R and MATLAB the most, are very aware of Rust and Go, but not D. I wonder if we do need to pay more attention to attracting new users just to get people talking about it.
>
> That's what you would expect, because D is a very ambitious language, which means its natural user base is much more spread out and less highly concentrated.  And beyond that, most code is enterprise code that's closed source, and whilst the web guys talk a lot and influence the culture, enterprise guys talk much less and just do their thing quietly.  Even in our world, how often do you see the people using D get involved in forum discussions?  Sociomantic, Weka, Ebay, and so on.  (Or Microsoft - did you know that D was used in their COM team?  They didn't exactly send out a press release...)  A little bit, but only a little in relation to their use of the language.  If you're trying to accomplish something in a representative enterprise context with lean resources, you don't have much time to talk about what you are doing.
That's one big potential mistake. Enterprises care about making money with whatever will help them do that (impress investors). Its developers who care about languages that help them write code that suites their requirements. The focus should be on developers not companies. People using D cannot be represented by Microsoft,  Sociomantic,  Weka,  etc. employees. Its of no use chasing after companies... make it useful and everyone else will come.


>
> If you want to draw people to the language (and, honestly, I wonder why it matters so much to many here
Its a simple math well understood since long ago.  The larger the army/workforce the better. Things get done. Walter always say here "Its left with someone to do the work". There other stuff he doesn't address including those outside language internals.

>- it's clearly
> taking hold, has momentum and will continue to grow for decades; an acorn will become an oak tree, and fretting about how much it's grown in the past year might be missing the point, so long as it's healthy enough), why not just focus on both improving the language itself (pull requests, documentation)
Someone needs to do that and we're short of people willing,  have the time and able to do that.

Either someone is paid to care enough to do that (Like Google do with Go, Oracle with Java,  Jetbrains with Kotlin,  etc.) OR grow a community/workforce to collectively make that happen.

> and on accomplishing something useful and worth doing with it?
There's also a possibility the acorn will loose interest and momentum and... die. Your opinion on what is worth doing is based on your domain or interest.

>
> Of course there are the usual trolls who don't seem to write much D, but seem to be drawn like vampires to the energy of those who do.  Sad.

Someone who doesn't write D or have no stake in it's well-being will not waste a second in this forum.

> don't seem
You don't know for sure. Remember we don't all use D the same way.

>
>
>
>
> On Sunday, 28 January 2018 at 17:23:12 UTC, Paulo Pinto wrote:
>> This has been mentioned multiple times, D really needs some kind of killer application.
>
> Why?
>
> It's a generalist language for getting stuff done in an age where people have succumbed so much to Stockholm Syndrome that they think it's a positive thing in a language that you can only use it to do something special.  Yet trends in performance and performance demands point to the rising importance of efficiency (and I suspect there will be a return to the recognition of the importance of being a generalist - in programming, as in other fields).  There was a tweet by the author of Musl libc observing that software today runs slower than software twenty years ago, and linking the bloat to the insane pressure to maximise CPU performance over all else.  The era of that kind of ruthless optimization is over because it's not the only thing that matters, and we start to see the price of it.  And generalism - in a dynamic business environment, there's considerable value to have capabilities that aren't adapted to particular narrow skills when what you need is always changing and may be unknown even to you.
>
> My generation was privileged because very quickly if you wanted to get anything interesting done you had to learn assembly language (maybe write your own assembler or disassembler), had to learn a bit about hardware, and could never pretend the CPU was this perfect platonic abstraction.  And for a while that changed, but I think the past is returning again, as it often does.
>
> So I see a value in hiring hacker / generalist types who can figure things out.  For example:
>
> https://hackaday.com/2017/01/26/a-personal-fight-against-the-modern-laptop/
> https://www.youtube.com/watch?v=Fzmm87oVQ6c
>
> Back in 2007, most finance types would have said how completely impracticable and unreasonable.  But I say, with GK Chesterton, that "all progress depends on the unreasonable man".  And someone like that doesn't succumb to helplessness once they are outside of their shiny IDE, knows that in the end everything is just code, and you can change it if you want to, and there is strategic value from building organisational capabilities from hiring such people.  Usually I'm a couple of years ahead, and I think others will follow.  If you hold a contrarian point of view, you know you're right when surprises start coming in your direction, and people still can't see it.  And I think that's been the case since 2014.
>
> Anyway - so D is a general purpose language, and I think we are likely seeing a nascent return in recognizing the value of generalist tools and people.
>
>> On my line of work having Go on the skills list is slowly becoming a requirement, due to Docker and Kubernetes adoption on cloud infrastructures.
>
> That's great.  Walter says that good code should look good on the page, and Go code looks nice enough.  It's got nice network and infra libraries, as you say.  But why would the adoption of Go be bad for D?  I think it's great for D because after a period of stagnation it gets people open to newer languages, and on the other hand the gap between the spirit of Go and D isn't that far (GC, clean code, native target) even if they don't have generics.
>  It's a big world - both D and Go can succeed, and the success of one isn't bought at the cost of the other.
>
>> Just wondering if mir or easier GPGPU programming could be that killer application.
>
> We sponsor mir algorithm (some of the routines within were developed for us, and we were happy to open source them), and we are rewriting our core analytics - used across the firm in a $4.1bn hedge fund in D from C++ before that.  What alternative really exists for what we are doing there?  And C++ vs D, it's not even a fair fight if you care about productivity, plasticity of the code, and generating wrappers for other languages that you can still understand whilst maintaining decent performance.  At the same time, we're not a D shop - a diversity of languages is not a bad thing, provided you have some way for them to work together.  Code reuse is very difficult, but the UNIX way does work.  On the other hand, if you want to connect components, how are you to do that?  Well, D is pretty nice for writing DSLs that can connect to code written in other languages, and where expressions can be evaluated from other languages.
>
> A specialist language adapted to a particular domain or set of domains - yes, that benefits from a killer app.  But for a generalist language that's useful for getting stuff done - why would there be a single killer app?  That doesn't make sense to me.  There should be multiple successes across different domains, and that's what we are beginning to see.  Just bear in mind that the web and tech guys talk a lot, but most programmers don't work in those industries.  It would be a mistake to conflate salience with economic importance, I think.
>
>
> Laeeth.

On Sunday, 28 January 2018 at 18:54:34 UTC, Laeeth Isharc wrote:
> On Sunday, 28 January 2018 at 13:50:03 UTC, Michael wrote:
>> [...]
>
> That's what you would expect, because D is a very ambitious language, which means its natural user base is much more spread out and less highly concentrated.  And beyond that, most code is enterprise code that's closed source, and whilst the web guys talk a lot and influence the culture, enterprise guys talk much less and just do their thing quietly.  Even in our world, how often do you see the people using D get involved in forum discussions?  Sociomantic, Weka, Ebay, and so on.  (Or Microsoft - did you know that D was used in their COM team?  They didn't exactly send out a press release...)  A little bit, but only a little in relation to their use of the language.  If you're trying to accomplish something in a representative enterprise context with lean resources, you don't have much time to talk about what you are doing.
>
> [...]

You're absolutely right in that, for a language like D with such a broad range of features, that it should absolutely be marketed as a generalist language. However, the kinds of "killer apps" I think people are talking about, are likely referring to apps that simply shine a spotlight on D, and allow people to discover all of the things that they can also do in D. A variety of "killer apps" would therefore be helpful, but any attention shown to D would be good. At the moment, it feels like the language is somewhat peddling about but not really going anywhere. I'm sure, as we've seen from downloads and things, that this isn't exactly the case, but we're not seeing Go levels of adoption, or even Rust levels of adoption.

On Mon, 2018-01-29 at 17:18 +0000, Mafi via Digitalmars-d wrote:
> 
[…]
> What would you say are the most important differences between dub and Cargo? What does Cargo do better than dub (or worse for that matter)? Superficially, they seem to be designed quite similarly.

The single most important thing is that Cargo stores source on a per person basis and compiles for each project separately. Dub stores source and compilation products on a per person basis. So, for me, Dub does the wrong thing with compilation of dependencies, and Cargo does it right. Why? Compiler choice and compiler option choice is a per project thing, not a centralised thing.

Cargo allows for download from the central repository and from any arbitrary Git or Mercurial repository. Dub only seems to get from the central repository.

The Cargo repository is just nicer than the Dub repository.

Cargo uses TOML project specifications, Dub uses JSON or SDL. Cargo wins, Dub doesn't.

The Cargo per project compilation product structure is nicer that Dubs.

It is certainly true that Dub and Cargo have the same aims and goal, it's just that Cargo does it better on essentially all fronts as far as the project build and builder are concerned.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Tue, 30 Jan 2018 10:38:31 +0000, Russel Winder wrote:

> On Mon, 2018-01-29 at 17:18 +0000, Mafi via Digitalmars-d wrote:
>> 
> […]
>> What would you say are the most important differences between dub and Cargo? What does Cargo do better than dub (or worse for that matter)? Superficially, they seem to be designed quite similarly.
> 
> The single most important thing is that Cargo stores source on a per person basis and compiles for each project separately. Dub stores source and compilation products on a per person basis. So, for me, Dub does the wrong thing with compilation of dependencies, and Cargo does it right. Why? Compiler choice and compiler option choice is a per project thing, not a centralised thing.

Are you sure? Every project on my PC places the build files in $PROJECTDIR/.dub/build; the source is in ~/.dub/packages.

That said, the name of the compiler is kept in the directory structure (as well as architecture and OS), which means there could be advantages to placing build artifacts globally, since compiler changes would still be separated, we get a reduction in disk usage and (sometimes) compile speed for already-built libraries.


> Cargo allows for download from the central repository and from any arbitrary Git or Mercurial repository. Dub only seems to get from the central repository.

This would be nice. I wonder though if the community is too small for this right now; remove the necessity of the central repository and it may die (I would say it's somewhat struggling as it is) -- and when it comes to finding libraries there are advantages to it that Github doesn't have.


> The Cargo repository is just nicer than the Dub repository.

It looks a lot nicer. I'm going to argue that as far as functionality though, it's horrible (note this is my first time looking in a long time):

- Home page is nice; it makes me want to use it.
- I click "Browse All Crates"; the default sort is alphabetical - not
  useful unless I'm just browsing, even then I'd likely want to browse by
  category. Each project takes up too much space (it looks like something's
  missing on each project), but I like the links to the project's
  homepage/repo/docs being right there in the list.
- I don't see any sort of categories/tags to organize projects. I guess I
  have to know what I'm looking for and use the right search term.
- Overall, I have the impression that it was designed to look good, but
  less effort has gone into what people will want to do with it in the
  first place (assuming I can consider myself normal for a moment).

Dub doesn't look so nice, but it's efficient; I could see me searching Cargo for something and not finding it; I've never thought that about Dub (granted, far fewer packages) or Pypi.


> Cargo uses TOML project specifications, Dub uses JSON or SDL. Cargo wins, Dub doesn't.

Agreed.


> It is certainly true that Dub and Cargo have the same aims and goal, it's just that Cargo does it better on essentially all fronts as far as the project build and builder are concerned.

Have you opened issues on the dub repository for the various problems you see?

--Ryan

On Tue, 30 Jan 2018 09:20:37 +0000, aberba wrote:

> That's one big potential mistake. Enterprises care about making money
> with whatever will help them do that (impress investors). Its developers
> who care about languages that help them write code that suites their
> requirements. The focus should be on developers not companies. People
> using D cannot be represented by Microsoft,
>   Sociomantic,  Weka,  etc. employees. Its of no use chasing after
> companies... make it useful and everyone else will come.

Well... if the goal is merely number of programmers, getting enterprises on-board is the easiest way to do it. Many (most?) professional programmers write nothing/very little after hours. Even if the programmers are on board, getting management to sign off may require throwing big names around.


>> If you want to draw people to the language (and, honestly, I wonder why it matters so much to many here
> Its a simple math well understood since long ago.  The larger the army/workforce the better. Things get done. Walter always say here "Its left with someone to do the work". There other stuff he doesn't address including those outside language internals.

Most people that use a language (whether D, Rust, Python, C++) use their for their own projects, rather than for development of the language itself (I don't know about anyone else, but that's why I was looking for a new language in the first place). Increasing the number of programmers may just increase the number of requests for better infrastructure.

Better tooling isn't going to come from numbers; more likely from something like:

- A hobbyist that wants to build something, either for enjoyment or some
  other desire.
- An organization investing in tools to increase the productivity of its
  programmers.
- A partnership with a CS department somewhere, which might be mutually
  beneficial as students gain real-world experience arguing with engineers
  and graduate with code that they've written being used in production.


> Either someone is paid to care enough to do that (Like Google do with Go, Oracle with Java,  Jetbrains with Kotlin,  etc.) OR grow a community/workforce to collectively make that happen.

Like they always say, "It takes money to spend money." :)


>> Of course there are the usual trolls who don't seem to write much D, but seem to be drawn like vampires to the energy of those who do.  Sad.
> 
> Someone who doesn't write D or have no stake in it's well-being will not waste a second in this forum.

People are people, the Internet's the Internet. Anything can happen.


> You don't know for sure. Remember we don't all use D the same way.

There's a DConf slogan for some year; it could highlight the diversity of uses/tasks/problems people solve with D.


--Ryan