www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D is coming to a town near you

reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
It's just me sharing a positive experience.

TL;DR I have a strong (anecdotal) evidence that D is rapidly gaining 
popularity :)

I was well aware of D certain number of D enthusiasts from Russia,
but seeing one casually going by in the wild is another thing.

In brief I was half-sleeping in a train when a young guy
takes a seat next to me. He pulls out a laptop and powers it up.

Idly wondering what I'll see this time around (HTML/JS? Python/Ruby? MS 
Word, PowerPoint?) to my surprise I notice it boots Arch linux.

Cute... and then the guy starts X11 from the console... (dubious) with 
Xfce (+1 from me, though I'm with Cinnamon now).

The next thing he does: fire up a terminal and Geany.

Command line goes like:

cd Code/D

cd <some-project>

git pull

And then he's off furiously hacking on some GTK-based project written in D.
(I omit the details, though the repo is public)
Actually it's some kind of client-server file transfer utility, alpha 
quality it seems. I even checked the repo, seems like he's involved in 
some tiny software startup.

Bottom line for me this kind of thing beats TIOBE index any day of the 
week :)

-- 
Dmitry Olshansky
Feb 20 2013
next sibling parent reply "Rob T" <alanb ucora.com> writes:
On Wednesday, 20 February 2013 at 17:48:29 UTC, Dmitry Olshansky 
wrote:

 It's just me sharing a positive experience.

 TL;DR I have a strong (anecdotal) evidence that D is rapidly 
 gaining popularity :)


[..]

I've noticed what looks like a large increase in the postings in 
D learn, which to me indicates a sudden increase in the people 
who are checking D out.

--rt
Feb 20 2013
parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Wednesday, 20 February 2013 at 17:52:46 UTC, Rob T wrote:

 On Wednesday, 20 February 2013 at 17:48:29 UTC, Dmitry 
 Olshansky wrote:

 It's just me sharing a positive experience.

 TL;DR I have a strong (anecdotal) evidence that D is rapidly 
 gaining popularity :)


 [..]

 I've noticed what looks like a large increase in the postings 
 in D learn, which to me indicates a sudden increase in the 
 people who are checking D out.

 --rt


I would say in late 2011 - early 2012 I hit more than usual talks 
about D in russian segment of the web, maybe it was growing that 
time.

But D has been loosing position in Tiobe index for a year. And 
two other measures which I know: http://langpop.com/ and 
http://lang-index.sourceforge.net/ also do not give much 
preference to it.
Feb 20 2013
parent reply "Rob T" <alanb ucora.com> writes:
On Wednesday, 20 February 2013 at 18:03:50 UTC, Maxim Fomin wrote:

 I would say in late 2011 - early 2012 I hit more than usual 
 talks about D in russian segment of the web, maybe it was 
 growing that time.

 But D has been loosing position in Tiobe index for a year. And 
 two other measures which I know: http://langpop.com/ and 
 http://lang-index.sourceforge.net/ also do not give much 
 preference to it.


When I fist investigated D about a year ago, I noticed that 
Google searches brought up more D1/Tango stuff than D2 stuff, and 
there seemed to be a ton of former D1/Tango activity that 
suddenly stopped when D2/Phobos came out. I also noted the same 
indexes that showed D was relatively noticeable on the charts, 
but then dropped almost out of sight.

It was clear to me that a fight had happened and there was a 
split and many people had suddenly abandoned D causing the rapid 
drop off the charts.

What may be underway is a resurgence around D2, so what we need 
to do is not repeat past mistakes, and do a ton of boring stuff 
like stabilize D2/Phobos before moving on to D3, install better 
processes for documentation and developing the language 
specifications, and of course continue to improve the release 
process (it still needs a real beta and stable release), etc.

--rt
Feb 20 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Rob T:


 and do a ton of boring stuff like stabilize D2/Phobos before 
 moving on to D3, install better processes for documentation and 
 developing the language specifications, and of course continue 
 to improve the release process (it still needs a real beta and 
 stable release), etc.


"Stabilize" is the wrong word to use. Implementing the 64 
compiler is good, implementing shared libraries is good, porting 
D runtime/Phobos to RISC CPUs is good, replacing the GC is good, 
improving the floating point management by DMD is good, and so on 
and on.

But in my opinion what's more needed now is instead to try to 
complete as much as possible the design and implementation of the 
missing/broken/incomplete parts of the core language (like 
finishing const/immutable design, finishing the implementation of 
pure, redesigning properties, fixing  trusted, doing what's 
possible with shared, doing what's possible to finish the 
inference of tags like pure in templated functions, finishing the 
design of packages, finishing the implementation of the module 
system, finishing the design of operator overloading, and so on. 
The complete list of broken/unfinished parts scares me).

Bye,
bearophile
Feb 20 2013
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Feb 20, 2013 at 07:42:41PM +0100, bearophile wrote:
[...]

 But in my opinion what's more needed now is instead to try to
 complete as much as possible the design and implementation of the
 missing/broken/incomplete parts of the core language (like finishing
 const/immutable design, finishing the implementation of pure,
 redesigning properties, fixing  trusted, doing what's possible with
 shared, doing what's possible to finish the inference of tags like
 pure in templated functions, finishing the design of packages,
 finishing the implementation of the module system, finishing the
 design of operator overloading, and so on. The complete list of
 broken/unfinished parts scares me).


[...]

Yeah, D already has enough features, but their interactions with each
other still haven't been ironed out completely. The C/C++ inherited part
of the language seems stable enough, barring a bug or two here and
there. I've been writing small programs in D that I used to write in
C/C++, and it's quite a pleasant experience.

But once I get into the realm of new features introduced in D, like
generic metaprogramming, functional-style code, non-trivial range APIs,
const-correctness, purity, etc., I just keep running into bugs,
unexpected interactions, conflicting designs, etc.. It can be quite
frustrating at times. No doubt, a lot of stuff *does* work, but bugs /
design issues are also quite frequent, which detracts a lot from one's
experience of D.

Sometimes I wonder if we're over-stretching ourselves with the amount of
clever features in D, as Kernighan once said:

	Debugging is twice as hard as writing the code in the first
	place. Therefore, if you write the code as cleverly as possible,
	you are, by definition, not smart enough to debug it. -- Brian
	W. Kernighan

Maybe D already has enough innovations, and now is the time to revisit
what is already there and polish it up into the refined product that it
should be.


T

-- 
Valentine's Day: an occasion for florists to reach into the wallets of
nominal lovers in dire need of being reminded to profess their
hypothetical love for their long-forgotten.
Feb 20 2013
prev sibling next sibling parent d coder <dlang.coder gmail.com> writes:
On Thu, Feb 21, 2013 at 12:27 AM, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:

 But once I get into the realm of new features introduced in D, like
 generic metaprogramming, functional-style code, non-trivial range APIs,
 const-correctness, purity, etc., I just keep running into bugs,
 unexpected interactions, conflicting designs, etc.. It can be quite
 frustrating at times. No doubt, a lot of stuff *does* work, but bugs /
 design issues are also quite frequent, which detracts a lot from one's
 experience of D.

 Sometimes I wonder if we're over-stretching ourselves with the amount of
 clever features in D, as Kernighan once said:

         Debugging is twice as hard as writing the code in the first
         place. Therefore, if you write the code as cleverly as possible,
         you are, by definition, not smart enough to debug it. -- Brian
         W. Kernighan

 Maybe D already has enough innovations, and now is the time to revisit
 what is already there and polish it up into the refined product that it
 should be.


On that measure, the present state of D is goof. When I try something
clever in metaprogramming for example, I generally hit a wall. Then I
think again and usually I get a much simpler way and the D compiler
too is happy with that.

In a way the buggy facet of D compiler is helping me :-)
Feb 20 2013
prev sibling next sibling parent reply "Rob T" <alanb ucora.com> writes:
On Wednesday, 20 February 2013 at 18:42:42 UTC, bearophile wrote:

 Rob T:


 and do a ton of boring stuff like stabilize D2/Phobos before 
 moving on to D3, install better processes for documentation 
 and developing the language specifications, and of course 
 continue to improve the release process (it still needs a real 
 beta and stable release), etc.


 "Stabilize" is the wrong word to use. Implementing the 64 
 compiler is good, implementing shared libraries is good, 
 porting D runtime/Phobos to RISC CPUs is good, replacing the GC 
 is good, improving the floating point management by DMD is 
 good, and so on and on.

 But in my opinion what's more needed now is instead to try to 
 complete as much as possible the design and implementation of 
 the missing/broken/incomplete parts of the core language (like 
 finishing const/immutable design, finishing the implementation 
 of pure, redesigning properties, fixing  trusted, doing what's 
 possible with shared, doing what's possible to finish the 
 inference of tags like pure in templated functions, finishing 
 the design of packages, finishing the implementation of the 
 module system, finishing the design of operator overloading, 
 and so on. The complete list of broken/unfinished parts scares 
 me).

 Bye,
 bearophile


Yes your additions is included in what I meant by "stabilize". We 
need to freeze the addition of new features for the "stable 
release of the language" (we currently do not have a stable 
release that is documented) and put it through the acid test of 
real world use so it can be polished up based on the feedback.

It may be a good idea to create a team that concentrates only on 
releasing a stable version of the language and polishing it up, 
otherwise it will never get done. We cannot polish up an 
undefined moving target, it's as simple as that.

--rt
Feb 20 2013
parent reply "Namespace" <rswhite4 googlemail.com> writes:
 Yes your additions is included in what I meant by "stabilize". 
 We need to freeze the addition of new features for the "stable 
 release of the language" (we currently do not have a stable 
 release that is documented) and put it through the acid test of 
 real world use so it can be polished up based on the feedback.


+1
But what about the features, that should be included, but are 
still missing?
Feb 20 2013
parent reply "Rob T" <alanb ucora.com> writes:
On Wednesday, 20 February 2013 at 19:49:51 UTC, Namespace wrote:

 Yes your additions is included in what I meant by "stabilize". 
 We need to freeze the addition of new features for the "stable 
 release of the language" (we currently do not have a stable 
 release that is documented) and put it through the acid test 
 of real world use so it can be polished up based on the 
 feedback.


 +1
 But what about the features, that should be included, but are 
 still missing?


Missing plus new and improved features show up in the next stable 
release of the language. The problem though is that we do not 
have a stable release of the language, nor do we even have a beta 
release. What we have can be described as a perpetual 
experimental release of the language.

 From what I can tell, we have enough already to document a stable 
release that will be useful in practical terms. Yes more features 
can and possibly should be added - but the desire to evolve and 
improve the language will always be there, so it never stops. We 
have to force a "stop" with an artificially imposed "stable" 
release.

--rt
Feb 20 2013
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
21-Feb-2013 00:08, Rob T пишет:

 On Wednesday, 20 February 2013 at 19:49:51 UTC, Namespace wrote:

 Yes your additions is included in what I meant by "stabilize". We
 need to freeze the addition of new features for the "stable release
 of the language" (we currently do not have a stable release that is
 documented) and put it through the acid test of real world use so it
 can be polished up based on the feedback.


 +1
 But what about the features, that should be included, but are still
 missing?


 Missing plus new and improved features show up in the next stable
 release of the language. The problem though is that we do not have a
 stable release of the language, nor do we even have a beta release.


There are betas. Just subscribe to the right mailing list.
That being said the start of new beta cycle should be listed at 
D.announce IMHO.


-- 
Dmitry Olshansky
Feb 20 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Rob T:


 What we have can be described as a
 perpetual experimental release of the language.


Is it normal for a language to be in such state for so many 
years? Are other languages in such state?

I am not intelligent (and experienced) enough to design the 
currently missing/broken parts of D. Is someone able to?

And even if someone (or a group of persons) is in theory able to 
do it, is it possible to do it not changing most of the other 
parts of D?

Bye,
bearophile
Feb 20 2013
parent "Kagamin" <spam here.lot> writes:
On Wednesday, 20 February 2013 at 21:05:42 UTC, bearophile wrote:

 I am not intelligent (and experienced) enough to design the 
 currently missing/broken parts of D. Is someone able to?


If one writes a short description of problems, then it will be 
easier to find people and ideas. For example, I have no clue 
what's wrong with `shared`.
Feb 22 2013
prev sibling parent reply 1100110 <0b1100110 gmail.com> writes:
On 02/20/2013 12:42 PM, bearophile wrote:

 Rob T:


 and do a ton of boring stuff like stabilize D2/Phobos before moving on
 to D3, install better processes for documentation and developing the
 language specifications, and of course continue to improve the release
 process (it still needs a real beta and stable release), etc.


 "Stabilize" is the wrong word to use. Implementing the 64 compiler is
 good, implementing shared libraries is good, porting D runtime/Phobos to
 RISC CPUs is good, replacing the GC is good, improving the floating
 point management by DMD is good, and so on and on.

 But in my opinion what's more needed now is instead to try to complete
 as much as possible the design and implementation of the
 missing/broken/incomplete parts of the core language (like finishing
 const/immutable design, finishing the implementation of pure,
 redesigning properties, fixing  trusted, doing what's possible with
 shared, doing what's possible to finish the inference of tags like pure
 in templated functions, finishing the design of packages, finishing the
 implementation of the module system, finishing the design of operator
 overloading, and so on. The complete list of broken/unfinished parts
 scares me).

 Bye,
 bearophile


Yes. Shared Libraries Please.

Thank you.
Feb 20 2013
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 20 February 2013 at 21:26:58 UTC, 1100110 wrote:

 On 02/20/2013 12:42 PM, bearophile wrote:

 Rob T:


 and do a ton of boring stuff like stabilize D2/Phobos before 
 moving on
 to D3, install better processes for documentation and 
 developing the
 language specifications, and of course continue to improve 
 the release
 process (it still needs a real beta and stable release), etc.


 "Stabilize" is the wrong word to use. Implementing the 64 
 compiler is
 good, implementing shared libraries is good, porting D 
 runtime/Phobos to
 RISC CPUs is good, replacing the GC is good, improving the 
 floating
 point management by DMD is good, and so on and on.

 But in my opinion what's more needed now is instead to try to 
 complete
 as much as possible the design and implementation of the
 missing/broken/incomplete parts of the core language (like 
 finishing
 const/immutable design, finishing the implementation of pure,
 redesigning properties, fixing  trusted, doing what's possible 
 with
 shared, doing what's possible to finish the inference of tags 
 like pure
 in templated functions, finishing the design of packages, 
 finishing the
 implementation of the module system, finishing the design of 
 operator
 overloading, and so on. The complete list of broken/unfinished 
 parts
 scares me).

 Bye,
 bearophile


 Yes. Shared Libraries Please.

 Thank you.


+1

It's the most important issue for me. Particular feature bugs can 
be worked around, lack of shared library support is 
insurmountable for many applications.
Feb 20 2013
parent reply "Rob T" <alanb ucora.com> writes:
On Thursday, 21 February 2013 at 00:48:50 UTC, John Colvin wrote:
[...]

 Yes. Shared Libraries Please.

 Thank you.


 +1

 It's the most important issue for me. Particular feature bugs 
 can be worked around, lack of shared library support is 
 insurmountable for many applications.


Yes, it's a major barrier towards adoption in a production 
environment. Walter said it's now a priority, so I cross the 
fingers and hope.

--rt
Feb 20 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Feb 21, 2013 at 01:55:00AM +0100, Rob T wrote:

 On Thursday, 21 February 2013 at 00:48:50 UTC, John Colvin wrote:
 [...]

Yes. Shared Libraries Please.

Thank you.


+1

It's the most important issue for me. Particular feature bugs can
be worked around, lack of shared library support is insurmountable
for many applications.


 
 Yes, it's a major barrier towards adoption in a production
 environment. Walter said it's now a priority, so I cross the fingers
 and hope.


[...]

Better yet, maybe more of us should start delving into DMD's code...
Currently only a small number of people really understand the compiler,
which has a rather low bus factor. We need to increase that (not only to
improve the bus factor, but also so that more people are aware of
compiler issues and hopefully how to fix them).


T

-- 
Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG
Feb 20 2013
next sibling parent reply 1100110 <0b1100110 gmail.com> writes:
On 02/20/2013 06:55 PM, H. S. Teoh wrote:

 On Thu, Feb 21, 2013 at 01:55:00AM +0100, Rob T wrote:

 On Thursday, 21 February 2013 at 00:48:50 UTC, John Colvin wrote:
 [...]

 Yes. Shared Libraries Please.

 Thank you.


 +1

 It's the most important issue for me. Particular feature bugs can
 be worked around, lack of shared library support is insurmountable
 for many applications.






I was playing with LuaD (https://github.com/JakobOvrum/LuaD) and was 
disappointed to learn that the only way to call D functions from Lua is 
for the lua code to be 'inside' a D module. (string l = "lua goes here"; 
or similar)

There are a few tricks you can perform, but it placed a very real limit 
on its usefulness.  Which is sad because other than that LuaD is beautiful.


 Yes, it's a major barrier towards adoption in a production
 environment. Walter said it's now a priority, so I cross the fingers
 and hope.


 [...]

 Better yet, maybe more of us should start delving into DMD's code...
 Currently only a small number of people really understand the compiler,
 which has a rather low bus factor. We need to increase that (not only to
 improve the bus factor, but also so that more people are aware of
 compiler issues and hopefully how to fix them).


 T


I only know enough C/C++ to know that I don't know enough...
If I could, I would totally go tearing through the source right now.

But some of it seems ambiguous to me.  I'm afraid I'd do more harm than 
good.
Feb 20 2013
parent reply "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Thursday, 21 February 2013 at 01:50:27 UTC, 1100110 wrote:

 I was playing with LuaD (https://github.com/JakobOvrum/LuaD) 
 and was disappointed to learn that the only way to call D 
 functions from Lua is for the lua code to be 'inside' a D 
 module. (string l = "lua goes here"; or similar)


I don't understand "inside a D module"

void someFun(string content) { ... }

lua["someFun"] = &someFun;

lua.doFile("SomeFileName.lua");
Feb 21 2013
parent reply 1100110 <0b1100110 gmail.com> writes:
On 02/21/2013 11:13 AM, Jesse Phillips wrote:

 On Thursday, 21 February 2013 at 01:50:27 UTC, 1100110 wrote:

 I was playing with LuaD (https://github.com/JakobOvrum/LuaD) and was
 disappointed to learn that the only way to call D functions from Lua
 is for the lua code to be 'inside' a D module. (string l = "lua goes
 here"; or similar)


 I don't understand "inside a D module"

 void someFun(string content) { ... }

 lua["someFun"] = &someFun;

 lua.doFile("SomeFileName.lua");



D starts lua, and lua finishes before D.
That fits my definition of 'inside a D file' but I admit I should have 
chosen my phrasing better.

Try lua starts D, and D finishes before lua.
Feb 22 2013
parent reply FG <home fgda.pl> writes:
Those are two different approaches:


 D starts lua, and lua finishes before D.


It's _embedding_ LUA in D. Can be easily done now.


 Try lua starts D, and D finishes before lua.


It's _extending_ LUA with D. Requires good D shared library support. :(
Feb 22 2013
parent 1100110 <0b1100110 gmail.com> writes:
On 02/22/2013 04:51 AM, FG wrote:

 Those are two different approaches:


 D starts lua, and lua finishes before D.


 It's _embedding_ LUA in D. Can be easily done now.


 Try lua starts D, and D finishes before lua.


 It's _extending_ LUA with D. Requires good D shared library support. :(



Thanks for setting me straight.
Feb 22 2013
prev sibling parent reply "Rikki Cattermole" <pbdadmin gmail.com> writes:
On Thursday, 21 February 2013 at 00:57:46 UTC, H. S. Teoh wrote:

 On Thu, Feb 21, 2013 at 01:55:00AM +0100, Rob T wrote:

 On Thursday, 21 February 2013 at 00:48:50 UTC, John Colvin 
 wrote:
 [...]

Yes. Shared Libraries Please.

Thank you.


+1

It's the most important issue for me. Particular feature bugs 
can
be worked around, lack of shared library support is 
insurmountable
for many applications.


 
 Yes, it's a major barrier towards adoption in a production
 environment. Walter said it's now a priority, so I cross the 
 fingers
 and hope.


 [...]

 Better yet, maybe more of us should start delving into DMD's 
 code...
 Currently only a small number of people really understand the 
 compiler,
 which has a rather low bus factor. We need to increase that 
 (not only to
 improve the bus factor, but also so that more people are aware 
 of
 compiler issues and hopefully how to fix them).


 T


I just want to say, as I have only worked in D for ~6 months the 
usage of Optilink is a real pain.
Couple of days ago I took a strong look at removing 64bit only 
code from Coff support and allowing it to compile 32bit.
I failed yes.
But I definitely will take another look into this.
Hopefully learn wayy more of how it works!
Feb 21 2013
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
21-Feb-2013 12:48, Rikki Cattermole пишет:

 On Thursday, 21 February 2013 at 00:57:46 UTC, H. S. Teoh wrote:

 On Thu, Feb 21, 2013 at 01:55:00AM +0100, Rob T wrote:

 On Thursday, 21 February 2013 at 00:48:50 UTC, John Colvin wrote:
 [...]

Yes. Shared Libraries Please.

Thank you.


+1

It's the most important issue for me. Particular feature bugs >can
be worked around, lack of shared library support is >insurmountable
for many applications.


 Yes, it's a major barrier towards adoption in a production
 environment. Walter said it's now a priority, so I cross the fingers
 and hope.


 [...]

 Better yet, maybe more of us should start delving into DMD's code...
 Currently only a small number of people really understand the compiler,
 which has a rather low bus factor. We need to increase that (not only to
 improve the bus factor, but also so that more people are aware of
 compiler issues and hopefully how to fix them).


 T


 I just want to say, as I have only worked in D for ~6 months the usage
 of Optilink is a real pain.


Checkout this alternative linker:
ftp://ftp.styx.cabel.net/pub/UniLink/

The only issue is that it converts debug info to some other format 
compatible with Borland's tools (TDS?).


 Couple of days ago I took a strong look at removing 64bit only code from
 Coff support and allowing it to compile 32bit.
 I failed yes.
 But I definitely will take another look into this.
 Hopefully learn wayy more of how it works!



-- 
Dmitry Olshansky
Feb 21 2013
parent "Rikki Cattermole" <pbdadmin gmail.com> writes:
On Thursday, 21 February 2013 at 17:02:06 UTC, Dmitry Olshansky 
wrote:

 21-Feb-2013 12:48, Rikki Cattermole пишет:

 On Thursday, 21 February 2013 at 00:57:46 UTC, H. S. Teoh 
 wrote:

 On Thu, Feb 21, 2013 at 01:55:00AM +0100, Rob T wrote:

 On Thursday, 21 February 2013 at 00:48:50 UTC, John Colvin 
 wrote:
 [...]

Yes. Shared Libraries Please.

Thank you.


+1

It's the most important issue for me. Particular feature 
bugs >can
be worked around, lack of shared library support is

insurmountable


for many applications.


 Yes, it's a major barrier towards adoption in a production
 environment. Walter said it's now a priority, so I cross the 
 fingers
 and hope.


 [...]

 Better yet, maybe more of us should start delving into DMD's 
 code...
 Currently only a small number of people really understand the 
 compiler,
 which has a rather low bus factor. We need to increase that 
 (not only to
 improve the bus factor, but also so that more people are 
 aware of
 compiler issues and hopefully how to fix them).


 T


 I just want to say, as I have only worked in D for ~6 months 
 the usage
 of Optilink is a real pain.


 Checkout this alternative linker:
 ftp://ftp.styx.cabel.net/pub/UniLink/

 The only issue is that it converts debug info to some other 
 format compatible with Borland's tools (TDS?).


 Couple of days ago I took a strong look at removing 64bit only 
 code from
 Coff support and allowing it to compile 32bit.
 I failed yes.
 But I definitely will take another look into this.
 Hopefully learn wayy more of how it works!




Been there tried that. Wasn't terribly happy with it.
The removal of 64bit code generation in coff format isn't a 
killer for me.
But it does make it harder. I can make do without it as I really 
only want my apps to be running on newer i5+ gear.
Its more of something to learn the compiler and help the 
community out a bit. Since I know that there will be others that 
would think this is a killer for not using D.
Feb 21 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-02-21 01:55, Rob T wrote:


 Yes, it's a major barrier towards adoption in a production environment.
 Walter said it's now a priority, so I cross the fingers and hope.


Several pull request from Martin Nowak have already been merged in that 
last couple of days which implement parts of what's needed.

-- 
/Jacob Carlborg
Feb 20 2013
prev sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On 2/20/2013 4:55 PM, Rob T wrote:

 On Thursday, 21 February 2013 at 00:48:50 UTC, John Colvin wrote:
 [...]

 Yes. Shared Libraries Please.

 Thank you.


 +1

 It's the most important issue for me. Particular feature bugs can be worked
around, lack of shared library support is
 insurmountable for many applications.


 
 Yes, it's a major barrier towards adoption in a production environment. Walter
said it's now a priority, so I cross the
 fingers and hope.
 
 --rt


It's _a_ barrier for adoption in _some_ production environments.  So are many
other features for many other
environments.  It's really easy to over color the priorities based on your own
use case.  The community is large with
lots of needs.  Juggling priorities is a very grey process.

Hope is about the least likely to produce results (other than maybe
disappointment).  I highly encourage those with
needs to actively help address them.  It doesn't take a lot of people to add a
lot of value.

My 2 cents,
Brad
Feb 21 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/21/2013 12:07 AM, Brad Roberts wrote:

 Hope is about the least likely to produce results (other than maybe
disappointment).  I highly encourage those with
 needs to actively help address them.  It doesn't take a lot of people to add a
lot of value.


I agree. Even fixing minor stuff is surprisingly helpful.
Feb 21 2013
prev sibling parent "Rob T" <alanb ucora.com> writes:
On Thursday, 21 February 2013 at 08:07:34 UTC, Brad Roberts wrote:

 On 2/20/2013 4:55 PM, Rob T wrote:

 Yes, it's a major barrier towards adoption in a production 
 environment. Walter said it's now a priority, so I cross the
 fingers and hope.
 
 --rt


 It's _a_ barrier for adoption in _some_ production 
 environments.  So are many other features for many other
 environments.  It's really easy to over color the priorities 
 based on your own use case.  The community is large with
 lots of needs.  Juggling priorities is a very grey process.


I think there's a lot more to it than that. For example, if D 
supported shared libs that can be integrated with C/C++ code then 
adoption in a production environment becomes much less risky and 
much more practical. For example, instead of recoding an entire 
C++ app in D, one could instead include a shared lib that adds on 
functionality. Shared libs provide a means to migrate into D 
without the all or nothing approach, and that what is currently 
one of the major barriers towards adoption.


 Hope is about the least likely to produce results (other than 
 maybe disappointment).  I highly encourage those with
 needs to actively help address them.  It doesn't take a lot of 
 people to add a lot of value.

 My 2 cents,
 Brad


I agree, and I have tried to help in small ways. I'll try and do 
more when I can and as I learn more.

--rt
Feb 23 2013
prev sibling next sibling parent d coder <dlang.coder gmail.com> writes:
Cool I will try not to sleep when I catch a train next time. :-)
Feb 20 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Feb 20, 2013 at 09:48:25PM +0400, Dmitry Olshansky wrote:
[...]

 In brief I was half-sleeping in a train when a young guy
 takes a seat next to me. He pulls out a laptop and powers it up.
 
 Idly wondering what I'll see this time around (HTML/JS? Python/Ruby?
 MS Word, PowerPoint?) to my surprise I notice it boots Arch linux.
 
 Cute... and then the guy starts X11 from the console... (dubious)
 with Xfce (+1 from me, though I'm with Cinnamon now).
 
 The next thing he does: fire up a terminal and Geany.
 
 Command line goes like:
 
 cd Code/D
 
 cd <some-project>
 
 git pull
 
 And then he's off furiously hacking on some GTK-based project written
 in D.  (I omit the details, though the repo is public) Actually it's
 some kind of client-server file transfer utility, alpha quality it
 seems. I even checked the repo, seems like he's involved in some tiny
 software startup.
 
 Bottom line for me this kind of thing beats TIOBE index any day of the
 week :)


[...]

Wait, wait, so you're saying, this random guy sitting next to you is, of
all things, coding in D, and you didn't even have a conversation with
him?!


T

-- 
Без труда не выловишь и рыбку из пруда.
Feb 20 2013
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
20-Feb-2013 23:00, H. S. Teoh пишет:

 On Wed, Feb 20, 2013 at 09:48:25PM +0400, Dmitry Olshansky wrote:
 [...]

 In brief I was half-sleeping in a train when a young guy
 takes a seat next to me. He pulls out a laptop and powers it up.

 Idly wondering what I'll see this time around (HTML/JS? Python/Ruby?
 MS Word, PowerPoint?) to my surprise I notice it boots Arch linux.

 Cute... and then the guy starts X11 from the console... (dubious)
 with Xfce (+1 from me, though I'm with Cinnamon now).

 The next thing he does: fire up a terminal and Geany.

 Command line goes like:

 cd Code/D

 cd <some-project>

 git pull

 And then he's off furiously hacking on some GTK-based project written
 in D.  (I omit the details, though the repo is public) Actually it's
 some kind of client-server file transfer utility, alpha quality it
 seems. I even checked the repo, seems like he's involved in some tiny
 software startup.

 Bottom line for me this kind of thing beats TIOBE index any day of the
 week :)


 [...]

 Wait, wait, so you're saying, this random guy sitting next to you is, of
 all things, coding in D, and you didn't even have a conversation with
 him?!


It felt like a dream I was afraid to break this nice illusion, only 
half-joking :)

Seriously, it feels like I've lost an opportunity to get acquainted with 
the local D resistance cell. But what's the hell, my email is there in 
the open and the guy seems to peruse the NG (d coder?).

-- 
Dmitry Olshansky
Feb 20 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
20-Feb-2013 23:36, Dmitry Olshansky пишет:


 But what's the hell, my email is there in
 the open and the guy seems to peruse the NG (d coder?).


Hmm... apparently was confused. Got to sleep more in trains instead of 
poking into somebody else laptops :)

-- 
Dmitry Olshansky
Feb 20 2013
prev sibling parent reply "Michael" <pr m1xa.com> writes:
 Wait, wait, so you're saying, this random guy sitting next to 
 you is, of
 all things, coding in D, and you didn't even have a 
 conversation with
 him?!


No time for explain, I will write it in D!!!
Feb 20 2013
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
20-Feb-2013 23:52, Michael пишет:

 Wait, wait, so you're saying, this random guy sitting next to you is, of
 all things, coding in D, and you didn't even have a conversation with
 him?!


 No time for explain, I will write it in D!!!


Obviously, I'm deeply indirect. This is typically bad for performance :)

-- 
Dmitry Olshansky
Feb 20 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Feb 21, 2013 at 12:16:08AM +0400, Dmitry Olshansky wrote:

 20-Feb-2013 23:52, Michael пишет:

Wait, wait, so you're saying, this random guy sitting next to you
is, of all things, coding in D, and you didn't even have a
conversation with him?!


No time for explain, I will write it in D!!!


 
 Obviously, I'm deeply indirect. This is typically bad for performance
 :)


[...]

Yeah, too many pointer lookups. :-P


T

-- 
"Holy war is an oxymoron." -- Lazarus Long
Feb 20 2013
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 20 Feb 2013 21:48:25 +0400
Dmitry Olshansky <dmitry.olsh gmail.com> wrote:


 [...]
 


Cool! I'm almost expecting to see someone reply here with "What a
coincidence! I just had the opposite thing happen to me: I was riding a
train in Russia, booted my laptop to Arch, started some D coding on a
Git project all while some other D user kept watching my screen!" :)
Feb 20 2013