Thread overview | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
June 02, 2016 Blocking points for further D adoption | ||||
---|---|---|---|---|
| ||||
>I don't see it the same way. Yes, I agree my opinion is not representative. I'd also say I'm glad I can do something about this. Moved Andrei's post (http://forum.dlang.org/post/nipb14$ldb$1@digitalmars.com) to a new thread. >> [...] >>> Meanwhile, I go to conferences. Train and consult at large companies. >>> Dozens every year, cumulatively thousands of people. I talk about D >>> and ask people what it would take for them to use the language. >>> Invariably I hear a surprisingly small number of reasons: >>> [..] >>> * Tooling is immature and of poorer quality compared to the >>> competition. >> >> And what have we done about it? How long has it been since dfix existed, >> yet we still haven't really integrated it into the dmd toolchain? > >I've spoken to Brian about it. Dfix does not do lookup, which makes it sadly not up for meaningful uses. How about we start calling dfix and dscanner "official", move them over to the Dlang github namespace and ship them with every release? >>> * Hiring people who know D is a problem. >> >> There are many willing candidates right here. :-P > >Nice. We should start to list companies that use D - that solves the chicken vs. egg problem too: https://github.com/dlang/dlang.org/pull/1312 >>> * Documentation and tutorials are weak. >> >> And what have we done about this? > >http://tour.dlang.org is a good start. Yes it is good step, but we need to improve this and create more! Having a MOOC (usually >50K viewers!) would be the best way to move forward. >>> * There's no web services framework (by this time many folks know of >>> D, but of those a shockingly small fraction has even heard of vibe.d). >>> I have strongly argued with Sönke to bundle vibe.d with dmd over one >>> year ago, and also in this forum. There wasn't enough interest. >> I heard this a lot too. "You don't have a web server in your standard libary?? It's 2016!" We should close the gap to NodeJS, Go (and all the other languages) ASAP and standardize the API for the following: 1) event loop library (e.g. https://github.com/etcimon/libasync) 2) bare-metal http server with full HTTP2 support (e.g. https://github.com/etcimon/libhttp2) NodeJS provides such a low-level API and this has been a key part of their success, because so many libraries built on-top of this without breaking each other. https://nodejs.org/api/http.html >> What about linking to it in a prominent place on dlang.org? This isn't >> a big problem, AFAICT. I don't think it takes months and years to put >> up a big prominent banner promoting vibe.d on, say, the download page of >> dlang.org. > >PR please. I can't babysit everything. I'm preparing for a conference where I'll evangelize for D next week (http://ndcoslo.com/speaker/andrei-alexandrescu/). As I mentioned at DConf, for better or worse this is the kind of stuff I cannot delegate. That could help, but it's needs more work: https://github.com/dlang/dlang.org/pull/1314 |
June 02, 2016 Re: Blocking points for further D adoption | ||||
---|---|---|---|---|
| ||||
Posted in reply to Seb | On 06/02/2016 11:40 AM, Seb wrote: > How about we start calling dfix and dscanner "official", move them over > to the Dlang github namespace and ship them with every release? From my email dated 2015/05/31 entitled "Make dformat and dfix part of the dmd distribution": > Hi Brian, > > > I was very pleased at DConf to see that your toolset has nicely > reached maturity. > > The logical next step is to make your tools part of the dmd > distribution. I'm thinking making dformat and dfix trivially easy to > use and of great help to folks. > > What do you think? Could you work on that? Any blockers you could > see? > > I'm thinking getting this done for 2.068. > > > Thanks, > > Andrei I have followed that with several attempts to push things forward with dfix, last on 2016/03/03, with various major contributors. There was no blocker, but also no finalization. We have made tools "official" in the past. Some we've put in our github (e.g. VisualD). As far as I can tell that did nothing to accelerate work on them. But I'd be hasty to generalize from that and would be willing to try it again. Andrei |
June 02, 2016 Re: Blocking points for further D adoption | ||||
---|---|---|---|---|
| ||||
Posted in reply to Seb | On 02-Jun-2016 18:40, Seb wrote: >> I don't see it the same way. Yes, I agree my opinion is not >> representative. I'd also say I'm glad I can do something about this. > > Moved Andrei's post > (http://forum.dlang.org/post/nipb14$ldb$1@digitalmars.com) to a new thread. > Biggest issue w.r.t. "Blocking points for further adoption" is doesn't solve any of "my" problems. That is problems of potential user. Then it turns out that language per se is rarely a problem (barring some older ones) but rather the platform or the ecosystem. It's a rare thing to have a user that wants to build something new in the vacuum (where D actually shines) using X times less code with the resulting speed of C++. In contrast a typical app is 95% frameworks/libraries haphazardly glued together in an MVP or demo that would then become a product eventually. Compare to the extreme example - Go. A pedestrian (IMHO) language that however built an attractive platform for web-services. Nobody goes to Go (pun) because of language features, but they do for hype (ad populum), builtin goroutines with scheduler and standard http library. All the hard work Go team done on the GC also payed off. TL; DR : The platform is the key. -- Dmitry Olshansky |
June 02, 2016 Re: Blocking points for further D adoption | ||||
---|---|---|---|---|
| ||||
Posted in reply to Seb | On Thursday, 2 June 2016 at 15:40:28 UTC, Seb wrote: >I heard this a lot too. > "You don't have a web server in your standard libary?? It's 2016!" Just to be clear, it's not a good idea to have a full blown server in your stdlib. Non-toy web servers are complicated pieces of software involving > 10KLOC. Not only that, but there are many ways to skin a cat in this field. Different products need varying, sometimes mutually exclusive, features from their servers. Therefore, I don't web servers are good candidates for standardization. > We should close the gap to NodeJS Go (and all the other languages) ASAP and standardize the API for the following: > > 1) event loop library (e.g. https://github.com/etcimon/libasync) > 2) bare-metal http server with full HTTP2 support (e.g. https://github.com/etcimon/libhttp2) A low level HTTP library, sure. Event loop libraries however, have the same problems with servers, i.e. a wide variety possible solutions with no clear "always use this method". |
June 02, 2016 Re: Blocking points for further D adoption | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Thursday, 2 June 2016 at 16:18:45 UTC, Andrei Alexandrescu wrote:
> We have made tools "official" in the past. Some we've put in our github (e.g. VisualD). As far as I can tell that did nothing to accelerate work on them. But I'd be hasty to generalize from that and would be willing to try it again.
Maybe development won't accelerate, but if you bundled dfmt/dscanner with the dmd zip downloads, I'd be willing to bet money that they'd get a huge boost in usage.
|
June 02, 2016 Re: Blocking points for further D adoption | ||||
---|---|---|---|---|
| ||||
Posted in reply to Seb | On Thursday, 2 June 2016 at 15:40:28 UTC, Seb wrote:
>
>> * Documentation and tutorials are weak.
Ugh, I was just looking at the classes section of the Spec and it has a header for alias this, but no header for inheritance.
|
June 02, 2016 Re: Blocking points for further D adoption | ||||
---|---|---|---|---|
| ||||
Posted in reply to Seb | On Thursday, 2 June 2016 at 15:40:28 UTC, Seb wrote:
> How about we start calling dfix and dscanner "official", move them over to the Dlang github namespace and ship them with every release?
Brian's tools are based on libdparse which is not in sync with the official D grammar and semantic. They can't be official. For example libdparse doesn't support some stuff that are deprecated byt still supported by DDMD.
|
June 02, 2016 Re: Blocking points for further D adoption | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jack Stouffer | On Thursday, 2 June 2016 at 18:14:08 UTC, Jack Stouffer wrote:
> A low level HTTP library, sure. Event loop libraries however, have the same problems with servers, i.e. a wide variety possible solutions with no clear "always use this method".
I like Python's HTTP and URL libraries and use them quite often.
|
June 02, 2016 Re: Blocking points for further D adoption | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jack Stouffer | On 06/02/2016 02:18 PM, Jack Stouffer wrote:
> On Thursday, 2 June 2016 at 16:18:45 UTC, Andrei Alexandrescu wrote:
>> We have made tools "official" in the past. Some we've put in our
>> github (e.g. VisualD). As far as I can tell that did nothing to
>> accelerate work on them. But I'd be hasty to generalize from that and
>> would be willing to try it again.
>
> Maybe development won't accelerate, but if you bundled dfmt/dscanner
> with the dmd zip downloads, I'd be willing to bet money that they'd get
> a huge boost in usage.
I'd be willing to experiment with that. -- Andrei
|
June 02, 2016 Re: Blocking points for further D adoption | ||||
---|---|---|---|---|
| ||||
Posted in reply to Seb | On Thursday, 2 June 2016 at 15:40:28 UTC, Seb wrote: >>I don't see it the same way. Yes, I agree my opinion is not representative. I'd also say I'm glad I can do something about this. > > Moved Andrei's post (http://forum.dlang.org/post/nipb14$ldb$1@digitalmars.com) to a new thread. > >>> [...] >>>> Meanwhile, I go to conferences. Train and consult at large companies. >>>> Dozens every year, cumulatively thousands of people. I talk about D >>>> and ask people what it would take for them to use the language. >>>> Invariably I hear a surprisingly small number of reasons: >>>> [..] > >>>> * Tooling is immature and of poorer quality compared to the >>>> competition. >>> >>> And what have we done about it? How long has it been since dfix existed, >>> yet we still haven't really integrated it into the dmd toolchain? >> >>I've spoken to Brian about it. Dfix does not do lookup, which makes it sadly not up for meaningful uses. > > How about we start calling dfix and dscanner "official", move them over to the Dlang github namespace and ship them with every release? > >>>> * Hiring people who know D is a problem. >>> >>> There are many willing candidates right here. :-P >> >>Nice. > > We should start to list companies that use D - that solves the chicken vs. egg problem too: > https://github.com/dlang/dlang.org/pull/1312 > >>>> * Documentation and tutorials are weak. >>> >>> And what have we done about this? >> >>http://tour.dlang.org is a good start. > > Yes it is good step, but we need to improve this and create more! > Having a MOOC (usually >50K viewers!) would be the best way to move forward. > >>>> * There's no web services framework (by this time many folks know of >>>> D, but of those a shockingly small fraction has even heard of vibe.d). >>>> I have strongly argued with Sönke to bundle vibe.d with dmd over one >>>> year ago, and also in this forum. There wasn't enough interest. >>> > > I heard this a lot too. > "You don't have a web server in your standard libary?? It's 2016!" > We should close the gap to NodeJS, Go (and all the other languages) ASAP and standardize the API for the following: > > 1) event loop library (e.g. https://github.com/etcimon/libasync) > 2) bare-metal http server with full HTTP2 support (e.g. https://github.com/etcimon/libhttp2) > > NodeJS provides such a low-level API and this has been a key part of their success, > because so many libraries built on-top of this without breaking each other. > > https://nodejs.org/api/http.html > >>> What about linking to it in a prominent place on dlang.org? This isn't >>> a big problem, AFAICT. I don't think it takes months and years to put >>> up a big prominent banner promoting vibe.d on, say, the download page of >>> dlang.org. >> >>PR please. I can't babysit everything. I'm preparing for a conference where I'll evangelize for D next week (http://ndcoslo.com/speaker/andrei-alexandrescu/). As I mentioned at DConf, for better or worse this is the kind of stuff I cannot delegate. > > That could help, but it's needs more work: > https://github.com/dlang/dlang.org/pull/1314 Hello, My first post on dlang. :) to #makedanggreatagain I guess dlang just needs to go where is noise and fish people from there. That place is web and mobile, and games The same as go, adding a html library a tiny sinatra style web framework given the speed of dlang, my bet this will manage to add more people. Even this website is amazing how fast it is. I know is vibe.d. But vibe.d is forever in beta mode. Mobile. This is long and complicated. I read that there some movements in this direction using android, but having in the next few years one lib to build cross platform will be a kill Games. Even here, adding a library to make with work with android or ios. Similar with sprite kit, or cocoa will move more people. tour.dlang.io is a nice beginning. Just a beginning. dfmt tool. In tour.dlang.io is a different style of writting code than what will generate for you. code.dlang. The website looks bad. But is very fast. I do have a domain, grab it last year, http://dlangbyexample.com/. I would like to donate it to dlang foundation and there someone should use https://www.gitbook.com/ and add a really nice website. IDE. mono-d and visual studio. Rest of them are bad I hope this post will not add any kind of rant over the people here. I know you are amazing. I would love to help, but, I have no idea how to start, where to go, what is the plan. |
Copyright © 1999-2021 by the D Language Foundation