www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - [Semi-OT] I don't want to leave this language!

reply e-y-e <yurtqbqn grr.la> writes:
Currently I have been learning D for about a year and a half. 
This may seem like a short time, but this is the longest I have 
stuck with any language. I have only been learning for 4 years 
and I am currently in university studying first year of computer 
systems engineering.

My main problem is that now I am looking for industry placements, 
it is clear that in this field C and C++ are highly desired. I 
have used C++ prior to discovering D, but much of my learning 
curve has occured while using D, and I feel quite comfortable 
using it. Using D makes me look back at what a great language it 
is compared to C++ (I know it can also be compared to C but I 
haven't used C).

So I don't want to go back. It isn't as if I have a career in C++ 
(like I know some people here have) and use D (only) for pleasure 
so I have no real knowledge of how things I write in D compare to 
what I would do in C++ (and none whatsoever for C).

Does anyone have any advice for me? Obviously I'm going to have 
to make this leap and the organizations will have their own 
ecosystem but while I'm learning how can I replace some of the 
great things about D? Things like built-in unittests, sane static 
if, painless CTFE, ranges, or even just the DUB package 
manager/build tool.

Failing that, think of this as another one of those 'D is great!' 
posts ;). And whatever happens, I'll certainly try and convince 
my host company to use it...
Dec 05 2016
next sibling parent bachmeier <no spam.net> writes:
On Monday, 5 December 2016 at 17:18:25 UTC, e-y-e wrote:

 Currently I have been learning D for about a year and a half. 
 This may seem like a short time, but this is the longest I have 
 stuck with any language. I have only been learning for 4 years 
 and I am currently in university studying first year of 
 computer systems engineering.

 My main problem is that now I am looking for industry 
 placements, it is clear that in this field C and C++ are highly 
 desired. I have used C++ prior to discovering D, but much of my 
 learning curve has occured while using D, and I feel quite 
 comfortable using it. Using D makes me look back at what a 
 great language it is compared to C++ (I know it can also be 
 compared to C but I haven't used C).

 So I don't want to go back. It isn't as if I have a career in 
 C++ (like I know some people here have) and use D (only) for 
 pleasure so I have no real knowledge of how things I write in D 
 compare to what I would do in C++ (and none whatsoever for C).

 Does anyone have any advice for me? Obviously I'm going to have 
 to make this leap and the organizations will have their own 
 ecosystem but while I'm learning how can I replace some of the 
 great things about D? Things like built-in unittests, sane 
 static if, painless CTFE, ranges, or even just the DUB package 
 manager/build tool.

 Failing that, think of this as another one of those 'D is 
 great!' posts ;). And whatever happens, I'll certainly try and 
 convince my host company to use it...


I'm an academic, so no useful advice. I was reminded when reading 
your post of all the comments from Lisp, Scheme, Haskell, and 
[insert language] users that are able to choose their language 
for much of their job. Many use Lisp. Just not for production. An 
advantage of D is that you can mix C/C++ with D, so that 
increases the chance of using it.
Dec 05 2016
prev sibling next sibling parent reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
Hi e-y-e,

The main problem with D for production is its runtime. GC, 
DRuntime, Phobos is big constraint for real world software 
production.

Good D code should be nothrow,  nogc, and betterC. BetterC means 
that it must not require DRuntime to link and to start. I started 
Mir as scientific/numeric project, but it is going to be a 
replacement for Phobos to use D instead/with of C/C++.

For example, Mir CPUID, Mir GLAS, Mir Random are nothrow  nogc 
and do not need DRuntime to start/link. (Mir Random is not tested 
for BetterC, so maybe few dependencies are exist.) Mir Random 
covers C++11 random number generation for example.

If D code can be compiled into a common C libraries like Mir 
libs, than you can include it into existing ecosystem. Currently 
it is possible only with LDC (requires some programming 
techniques for now).

I will be happy to see more Mir contributors [1]

Currently there are 5 Mir devs (not all are visible publicly).

[1] https://github.com/libmir

Cheers,
Ilya
Dec 05 2016
next sibling parent reply e-y-e <yurtqbqn grr.la> writes:
On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko wrote:

 Hi e-y-e,

 The main problem with D for production is its runtime. GC, 
 DRuntime, Phobos is big constraint for real world software 
 production.

 Good D code should be nothrow,  nogc, and betterC. BetterC 
 means that it must not require DRuntime to link and to start. I 
 started Mir as scientific/numeric project, but it is going to 
 be a replacement for Phobos to use D instead/with of C/C++.

 For example, Mir CPUID, Mir GLAS, Mir Random are nothrow  nogc 
 and do not need DRuntime to start/link. (Mir Random is not 
 tested for BetterC, so maybe few dependencies are exist.) Mir 
 Random covers C++11 random number generation for example.

 If D code can be compiled into a common C libraries like Mir 
 libs, than you can include it into existing ecosystem. 
 Currently it is possible only with LDC (requires some 
 programming techniques for now).

 I will be happy to see more Mir contributors [1]

 Currently there are 5 Mir devs (not all are visible publicly).

 [1] https://github.com/libmir

 Cheers,
 Ilya


You know from the 15th December I will have a month of free time, 
and I would love to get myself up to speed with Mir to contribute 
to it. If you don't mind me saying, I think Mir could be one of 
the best things for the future of D (along with LDC) and I'd be 
glad to help it on its way.
Dec 05 2016
next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Monday, 5 December 2016 at 20:49:50 UTC, e-y-e wrote:

 On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko 
 wrote:

 [...]


 You know from the 15th December I will have a month of free 
 time, and I would love to get myself up to speed with Mir to 
 contribute to it. If you don't mind me saying, I think Mir 
 could be one of the best things for the future of D (along with 
 LDC) and I'd be glad to help it on its way.


That'd be great, drop in to our gitter some time 
https://gitter.im/libmir/public if you have any questions. The 
modules last updated before November are not very interesting at 
the moment. dcompute is, but is waiting on pulls for LDC.
Dec 05 2016
prev sibling next sibling parent Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Monday, 5 December 2016 at 20:49:50 UTC, e-y-e wrote:

 On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko 
 wrote:

 [...]


 You know from the 15th December I will have a month of free 
 time, and I would love to get myself up to speed with Mir to 
 contribute to it. If you don't mind me saying, I think Mir 
 could be one of the best things for the future of D (along with 
 LDC) and I'd be glad to help it on its way.


Awesome! The main directions are:
  1. stdC++ analogs implementation in betterC Dlang subset
  2. betterC analogs of existing Phobos modules. We can reuse 
DRuntime / Phobos code for initial commits.
  3. Various numeric / sci software.
  4. GPU algorithms. This require dcompute to be a part of LDC.

Thank you,
Ilya
Dec 06 2016
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/5/16 3:49 PM, e-y-e wrote:

 If you don't mind me saying, I think Mir could be one of the best things
 for the future of D (along with LDC) and I'd be glad to help it on its way.


Yes, Mir is awesome! I keep on thinking of ways to make it better 
supported by the language and infra. -- Andrei
Dec 06 2016
prev sibling next sibling parent reply Andrea Fontana <nospam example.com> writes:
On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko wrote:

 Good D code should be nothrow,  nogc, and betterC. BetterC 
 means that it must not require DRuntime to link and to start. I 
 started Mir as scientific/numeric project, but it is going to 
 be a replacement for Phobos to use D instead/with of C/C++.


Completly disagree. You're speaking about scientific projects, 
maybe.
Phobos/Druntime are pretty good for a lot of projects.

Andrea
Dec 06 2016
parent reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Tuesday, 6 December 2016 at 08:14:17 UTC, Andrea Fontana wrote:

 On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko 
 Phobos/Druntime are pretty good for a lot of projects.


In theory
Dec 06 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/6/16 3:28 AM, Ilya Yaroshenko wrote:

 On Tuesday, 6 December 2016 at 08:14:17 UTC, Andrea Fontana wrote:

 On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko
 Phobos/Druntime are pretty good for a lot of projects.


 In theory


And what seem to be the issues in practice with code that is not highly 
specialized? -- Andrei
Dec 06 2016
parent reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Tuesday, 6 December 2016 at 13:02:16 UTC, Andrei Alexandrescu 
wrote:

 On 12/6/16 3:28 AM, Ilya Yaroshenko wrote:

 On Tuesday, 6 December 2016 at 08:14:17 UTC, Andrea Fontana 
 wrote:

 On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko
 Phobos/Druntime are pretty good for a lot of projects.


 In theory


 And what seem to be the issues in practice with code that is 
 not highly specialized? -- Andrei


If code is not highly specialized there is no reason to spent 
resources to use C/C++/D. A company will be happy with Python, 

level he can not use D because DRuntime. Only a subset of D can 
be used. And current problem that we have not BetterC paradigm in 
D specification. So, only crazy companies will consider D for 
large projects. Current D is successful in small console text 
routines.

If a system PL can not be used as C for highly specialized code, 
it is not a real system PL.

DRuntime and Phobos is going to compete with Java and Go. It is 
suicide for D, IMHO. In other hand, BetterC is a direction where 
D can be populated among professionals and replace C/C++.

Ilya
Dec 06 2016
parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Tuesday, December 06, 2016 13:36:20 Ilya Yaroshenko via Digitalmars-d-
learn wrote:

 On Tuesday, 6 December 2016 at 13:02:16 UTC, Andrei Alexandrescu

 wrote:

 On 12/6/16 3:28 AM, Ilya Yaroshenko wrote:

 On Tuesday, 6 December 2016 at 08:14:17 UTC, Andrea Fontana

 wrote:

 On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko
 Phobos/Druntime are pretty good for a lot of projects.


 In theory


 And what seem to be the issues in practice with code that is
 not highly specialized? -- Andrei


 If code is not highly specialized there is no reason to spent
 resources to use C/C++/D. A company will be happy with Python,

 level he can not use D because DRuntime. Only a subset of D can
 be used. And current problem that we have not BetterC paradigm in
 D specification. So, only crazy companies will consider D for
 large projects. Current D is successful in small console text
 routines.

 If a system PL can not be used as C for highly specialized code,
 it is not a real system PL.

 DRuntime and Phobos is going to compete with Java and Go. It is
 suicide for D, IMHO. In other hand, BetterC is a direction where
 D can be populated among professionals and replace C/C++.


While I am quite sure that there are use cases where folks would be unhappy
with druntime and Phobos and want to avoid them, there are definitely
companies using D with druntime and Phobos right now, and personally, I've
never worked at a company where anything about druntime or Phobos would have
been a showstopper in switching to D. The showstopper would be in convincing
them to use a new language rather than one that they were already familiar
with. C++ works for them, and they're not interested in switching. And
honestly, pushing for a subset of D that didn't have the functionality in
druntime and Phobos would just make it an even harder sell. At that point,
they're _really_ not interested in using D. C++11/14/17 quickly and easily
wins out in that fight.

So, while there are certainly folks who would prefer using D as a better C
without druntime or Phobos, I think that you're seriously overestimating how
many folks would be interested in that. Certainly, all of the C++
programmers that I've worked with professionally would have _zero_ interest
in D as a better C.

- Jonathan M Davis
Dec 06 2016
next sibling parent reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Tuesday, 6 December 2016 at 17:00:35 UTC, Jonathan M Davis 
wrote:

 So, while there are certainly folks who would prefer using D as 
 a better C without druntime or Phobos, I think that you're 
 seriously overestimating how many folks would be interested in 
 that. Certainly, all of the C++ programmers that I've worked 
 with professionally would have _zero_ interest in D as a better 
 C.

 - Jonathan M Davis


My experience is completely orthogonal. --Ilya
Dec 06 2016
parent bachmeier <no spam.net> writes:
On Tuesday, 6 December 2016 at 20:01:38 UTC, Ilya Yaroshenko 
wrote:

 On Tuesday, 6 December 2016 at 17:00:35 UTC, Jonathan M Davis 
 wrote:

 So, while there are certainly folks who would prefer using D 
 as a better C without druntime or Phobos, I think that you're 
 seriously overestimating how many folks would be interested in 
 that. Certainly, all of the C++ programmers that I've worked 
 with professionally would have _zero_ interest in D as a 
 better C.

 - Jonathan M Davis


 My experience is completely orthogonal. --Ilya


There is a theorem that all programming language discussions on 
the internet start with the assumption that real programming is 
exactly the same as the programming done by the author.
Dec 06 2016
prev sibling next sibling parent reply bpr <brogoff gmail.com> writes:
On Tuesday, 6 December 2016 at 17:00:35 UTC, Jonathan M Davis 
wrote:

 So, while there are certainly folks who would prefer using D as 
 a better C without druntime or Phobos, I think that you're 
 seriously overestimating how many folks would be interested in 
 that. Certainly, all of the C++ programmers that I've worked 
 with professionally would have _zero_ interest in D as a better 
 C.


I would guess that the vast majority of interest shown in Rust is 
from people who essentially want a better C or C++, with no 
runtime/GC. So, I think Ilya's point is very plausible. D with no 
GC, but with modules, templates, overloading, CTFE, and some 
other features might have been more tempting to the no-GC crowd, 
which includes many hardcore C++ programmers.

Those programmers who are comfortable working in a GC-ed language 
will likely eschew D because D's GC is really not that great.
Dec 06 2016
next sibling parent reply bachmeier <no spam.net> writes:
On Tuesday, 6 December 2016 at 22:13:54 UTC, bpr wrote:

 Those programmers who are comfortable working in a GC-ed 
 language will likely eschew D because D's GC is really not that 
 great.


So someone working with Ruby is not going to want to work with D 
because of GC performance? I wonder what percentage of Ruby 
programmers have thought about garbage collection ever. I could 
see an argument that there are existing frameworks or some other 
reason to prefer another language, but it is highly unlikely that 
GC would be the reason that both C++ and Ruby programmers would 
not want to use D.
Dec 06 2016
parent reply bpr <brogoff gmail.com> writes:
On Tuesday, 6 December 2016 at 22:23:25 UTC, bachmeier wrote:

 On Tuesday, 6 December 2016 at 22:13:54 UTC, bpr wrote:

 Those programmers who are comfortable working in a GC-ed 
 language will likely eschew D because D's GC is really not 
 that great.


 So someone working with Ruby is not going to want to work with 
 D because of GC performance?


Ruby programmers are probably not concerned with performance at 
all ever. It's a slow interpreted language with a GIL. But if 
you're on a Rails project, that's what you'll use.

If I really *want* to use a GC, say I'm writing a server and I 
believe that a well tuned GC will allow my server to stay alive 
much longer with less fragmentation, I'll probably skip D and 
pick Go or maybe (hmmm...) even Java because their GCs have had a 
lot of engineering effort.


 I wonder what percentage of Ruby programmers have thought about 
 garbage collection ever.


Why would a Ruby or Python programmer unconcerned with 
performance want to switch to D? I'm sure there are some who 
would, but I'd imagine they're rare.
Dec 06 2016
parent bachmeier <no spam.net> writes:
On Wednesday, 7 December 2016 at 02:24:56 UTC, bpr wrote:

 If I really *want* to use a GC, say I'm writing a server and I 
 believe that a well tuned GC will allow my server to stay alive 
 much longer with less fragmentation, I'll probably skip D and 
 pick Go or maybe (hmmm...) even Java because their GCs have had 
 a lot of engineering effort.


Writing a server is quite narrow compared to the "programmers who 
are comfortable working in a GC-ed language" that I was 
responding to.


 I wonder what percentage of Ruby programmers have thought 
 about garbage collection ever.


 Why would a Ruby or Python programmer unconcerned with 
 performance want to switch to D? I'm sure there are some who 
 would, but I'd imagine they're rare.


Maybe some prefer D as a language? The same argument could be 
used against any language. Performance is far from the only 
reason to use D.
Dec 06 2016
prev sibling next sibling parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Tuesday, December 06, 2016 22:13:54 bpr via Digitalmars-d-learn wrote:

 On Tuesday, 6 December 2016 at 17:00:35 UTC, Jonathan M Davis

 wrote:

 So, while there are certainly folks who would prefer using D as
 a better C without druntime or Phobos, I think that you're
 seriously overestimating how many folks would be interested in
 that. Certainly, all of the C++ programmers that I've worked
 with professionally would have _zero_ interest in D as a better
 C.


 I would guess that the vast majority of interest shown in Rust is
 from people who essentially want a better C or C++, with no
 runtime/GC. So, I think Ilya's point is very plausible. D with no
 GC, but with modules, templates, overloading, CTFE, and some
 other features might have been more tempting to the no-GC crowd,
 which includes many hardcore C++ programmers.


Sure, there are folks who would prefer not to have to deal with the GC but
throw out the runtime and std lib? You lose out on too much for it to be at
all worth it for many folks. At that point, C++11/14/17 looks far more
appealing, especially as it continues to improve. And  nogc and sane memory
use largely solves the GC problem for many programs. There are some places
where we need to improve the situation (like with lambdas and the GC), but
for most programs, it's totally workable as-is without giving up on all of
the features provided by the runtime and Phobos.

If you really need absolute pedal-to-the-metal performance and can't afford
to ever have the GC stop the world, you still don't need to actually throw
away the runtime and std lib. You're just a lot more restricted in what you
can do with them. So, tossing out druntime and Phobos entirely seems rather
extreme. It may very well make really good sense for a subset of D programs,
but I have a hard time believing that it's anything more than a small
subset.


 Those programmers who are comfortable working in a GC-ed language
 will likely eschew D because D's GC is really not that great.


We get plenty of folks who aren't big C/C++ programmers who are interested
in D. Yes, the majority seem to have a C++ background, but we also get folks


- Jonathan M Davis
Dec 06 2016
parent reply bpr <brogoff gmail.com> writes:
On Tuesday, 6 December 2016 at 22:47:34 UTC, Jonathan M Davis 
wrote:

 On Tuesday, December 06, 2016 22:13:54 bpr via 
 Digitalmars-d-learn wrote:

 On Tuesday, 6 December 2016 at 17:00:35 UTC, Jonathan M Davis

 wrote:


 Sure, there are folks who would prefer not to have to deal with 
 the GC but throw out the runtime and std lib? You lose out on 
 too much for it to be at all worth it for many folks. At that 
 point, C++11/14/17 looks far more appealing, especially as it 
 continues to improve.


It's a counterfactual at this point, but I would guess that if D 
had left out the GC in 2010 when D2 came out it would have been 
ahead of C++ in many ways and perhaps would have been able to 
peel off more C++ programmers and achieve the momentum that Rust 
appears to have now. Yes, it would be missing some features on 
account of omitting GC, but D2 -GC in 2010 is still much better 
than C++ 2011. As C++ absorbs D features, the case for D seems 
weaker.


 We get plenty of folks who aren't big C/C++ programmers who are 
 interested in D. Yes, the majority seem to have a C++ 



It would be nice to see a breakdown. From where I sit, it appears 
that most of the interest in D is from C++ users, and it doesn't 
appear that D popularity is rising so much. Any data that belies 
that sad assessment?
Dec 06 2016
next sibling parent Jonathan M Davis via Digitalmars-d-learn writes:
On Wednesday, December 07, 2016 02:38:50 bpr via Digitalmars-d-learn wrote:

 On Tuesday, 6 December 2016 at 22:47:34 UTC, Jonathan M Davis

 We get plenty of folks who aren't big C/C++ programmers who are
 interested in D. Yes, the majority seem to have a C++



 It would be nice to see a breakdown. From where I sit, it appears
 that most of the interest in D is from C++ users, and it doesn't
 appear that D popularity is rising so much. Any data that belies
 that sad assessment?


As I understand it, the downloads have been increasing year over year. At
least some years, Andrei has given some statistics on the state of D in his
dconf talk. And per his stats, forum/newsgroup activity was going up too,
though I get the impression that at least in the main newsgroup, it may have
actually dropped off (whereas Learn seems like it's been growing). That's
just my impression though. I'm sure github activity has gone up over time
though.

It's my understanding that D's usage has continued to grow but that it isn't
growing super fast, whereas languages such as Go and Rust do seem to have
grown very quickly (probably at least in part due to the companies behind
them). But other languages have taken a long time to catch on and still
ended up being very successful with large user bases (e.g. that's what
happened with python).

It's also hard to gauge how much D is really being used. The number of
companies saying that they're using D seems to have increased, but there are
who-knows how many folks using D who haven't said anything, and we really
don't have much to go on besides the downloads, which only capture a portion
of the D's users and even then only tells you how often dmd was downloaded,
not how many people it was or if they're new users or whatnot. And
downloading dmd from dlang.org is not the only way to get it.

There are definitely things that we can be and should be doing to improve
D's traction (like better supporting  nogc in Phobos), but I don't think
that we're doing badly. And often, the problem seems to be more of a PR one
than anything technical (e.g. I think that we're finally pretty much beyond
the issues caused by the confusion over Tango vs Phobos in D1, but it took a
long time). And honestly, much as there are technical problems related to
the GC, the far bigger problem seems to be the PR issues related to it.
Sadly, the simple fact that we _have_ a GC has been a PR problem, regardless
of the actual state of things. But regardless, we do seem to be gaining
traction, even if it's not as quickly as we might like.

- Jonathan M Davis
Dec 06 2016
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 7 December 2016 at 02:38:50 UTC, bpr wrote:

 It's a counterfactual at this point, but I would guess that if 
 D had left out the GC in 2010 when D2 came out it would have 
 been ahead of C++ in many ways and perhaps would have been able 
 to peel off more C++ programmers


c++ programmers want c++. anything that is not c++ will be bashed 
to death. there is absolutely no reason to kill one of the key D 
features only to attract 2.5 c++ coders. actually, we already 
have That One C++ Programmer We Need onboard -- Andrei. ;-)
Dec 06 2016
parent reply Andrey <avraliov gmail.com> writes:
On Wednesday, 7 December 2016 at 07:27:53 UTC, ketmar wrote:

 On Wednesday, 7 December 2016 at 02:38:50 UTC, bpr wrote:

 It's a counterfactual at this point, but I would guess that if 
 D had left out the GC in 2010 when D2 came out it would have 
 been ahead of C++ in many ways and perhaps would have been 
 able to peel off more C++ programmers


 c++ programmers want c++. anything that is not c++ will be 
 bashed to death. there is absolutely no reason to kill one of 
 the key D features only to attract 2.5 c++ coders. actually, we 
 already have That One C++ Programmer We Need onboard -- Andrei. 
 ;-)


Let me put My 2 cents too: the goal is not only attracting 2.5 
c++ coders, but to expand Dlang using. I like D, and I want to 
use it wide. And I believe Dlang adepts too. So we must make D to 
be usefull for small, metal-bare (important for me), embedded 
things to whatever... We can't do it now with GC.

I'am learning Ada lang now, and understood, that many usefull 
things Walter took from there.

I think, a good way to step up for Dlang is to be C++ like Ada 
variant, with possibility to work without GC. And with GC too, to 
make life easier, if someone wants.
IMO )
Dec 07 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 7 December 2016 at 09:45:39 UTC, Andrey wrote:

 I think, a good way to step up for Dlang is to be C++ like Ada 
 variant, with possibility to work without GC.


you do know that you *can* use D without GC even now, do you?
Dec 07 2016
parent Andrey <avraliov gmail.com> writes:
On Wednesday, 7 December 2016 at 09:56:20 UTC, ketmar wrote:

 On Wednesday, 7 December 2016 at 09:45:39 UTC, Andrey wrote:

 I think, a good way to step up for Dlang is to be C++ like Ada 
 variant, with possibility to work without GC.


 you do know that you *can* use D without GC even now, do you?


Yes, I do. But it is like C++ without stdlib. And no volatile 
access, if I didn't miss something. I agree with Ilya, must be a 
way to use runtime-free D lib.
Dec 07 2016
prev sibling parent reply aberba <karabutaworld gmail.com> writes:
On Tuesday, 6 December 2016 at 22:13:54 UTC, bpr wrote:

 On Tuesday, 6 December 2016 at 17:00:35 UTC, Jonathan M Davis



 I would guess that the vast majority of interest shown in Rust 
 is from people who essentially want a better C or C++, with no 
 runtime/GC. So, I think Ilya's point is very plausible. D with 
 no GC, but with modules, templates, overloading, CTFE, and some 
 other features might have been more tempting to the no-GC 
 crowd, which includes many hardcore C++ programmers.

 Those programmers who are comfortable working in a GC-ed 
 language will likely eschew D because D's GC is really not that 
 great.



I don't really get the issue with D's GC, Phobos and DRuntime. 
JavaScript is really popular and getting really popular everyday 
(I mean Nodejs). Same as Python, PHP, Ruby (startups), etc. But 
they are not exactly betterC. Most of them don't even give native 
code speed.

When using D, I just want to get my app working and running. That 
is why more packages (vibe.d, mail, request, mysql-lited, etc) 
matter to me. The level you are trying to raise D is way 
over-kill IMO :). It's good though for those who need it. But 
most of us don't judge languages that way.
Dec 06 2016
parent Timothee Cour via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
My 2 cents: for most applications, hotspots tend to be in a tiny percentage
of the code (ie 90/10 rule where 10% of code accounts for 90% execution
time, although my experience in large projects is even more unbalanced) ;
throwing away druntime or GC for the whole codebase based on performance
concerns amounts to (evil) early optimization.

It's far more productive to use a profiler and carefully optimize only the
parts that need to be (possibly using betterc,  nogc, ldc and optimized
compiler flags for those hotspots only).

What could be done better would be to remove friction when linking in
shared objects produced by dmd and ldc (eg, extern(D) functions have
different number of underscores in dmd vs ldc).

On that note, even if dmd is 50x slower than ldc for certain blas mir
routines, it's still valuable to have mir supported by dmd as we can always
swap in the slow parts during production runs, but we'd benefit with fast
compile time during development time,



On Tue, Dec 6, 2016 at 3:08 PM, aberba via Digitalmars-d-learn <
digitalmars-d-learn puremagic.com> wrote:


 On Tuesday, 6 December 2016 at 22:13:54 UTC, bpr wrote:


 On Tuesday, 6 December 2016 at 17:00:35 UTC, Jonathan M Davis


 I would guess that the vast majority of interest shown in Rust is from

 people who essentially want a better C or C++, with no runtime/GC. So, I
 think Ilya's point is very plausible. D with no GC, but with modules,
 templates, overloading, CTFE, and some other features might have been more
 tempting to the no-GC crowd, which includes many hardcore C++ programmers.

 Those programmers who are comfortable working in a GC-ed language will
 likely eschew D because D's GC is really not that great.



 I don't really get the issue with D's GC, Phobos and DRuntime. JavaScript
 is really popular and getting really popular everyday (I mean Nodejs). Same
 as Python, PHP, Ruby (startups), etc. But they are not exactly betterC.
 Most of them don't even give native code speed.

 When using D, I just want to get my app working and running. That is why
 more packages (vibe.d, mail, request, mysql-lited, etc) matter to me. The
 level you are trying to raise D is way over-kill IMO :). It's good though
 for those who need it. But most of us don't judge languages that way.
Dec 06 2016
prev sibling parent reply Picaud Vincent <picaud.vincent gmail.com> writes:
On Tuesday, 6 December 2016 at 17:00:35 UTC, Jonathan M Davis 
wrote:

 So, while there are certainly folks who would prefer using D as 
 a better C without druntime or Phobos, I think that you're 
 seriously overestimating how many folks would be interested in 
 that. Certainly, all of the C++ programmers that I've worked 
 with professionally would have _zero_ interest in D as a better 
 C.

 - Jonathan M Davis


Considering scientific/numerical applications, I do agree with 
Ilya: it is mandatory to have zero overhead and a 
straightforward/direct interoperability with C. I am impressed by 
the Mir lib results and I think "BetterC" is very 
attractive/important.

-- Vincent
Dec 06 2016
parent reply bachmeier <no spam.net> writes:
On Wednesday, 7 December 2016 at 06:17:17 UTC, Picaud Vincent 
wrote:

 Considering scientific/numerical applications, I do agree with 
 Ilya: it is mandatory to have zero overhead and a 
 straightforward/direct interoperability with C. I am impressed 
 by the Mir lib results and I think "BetterC" is very 
 attractive/important.


As always, it depends on what you are doing. It is mandatory for 
some numerical applications. R, Matlab, Python, Mathematica, 
Gauss, and Julia are used all the time and they are not zero 
overhead. A fast way to kill their usage would be to force their 
users to think about those issues. What matters is the available 
libraries, first and foremost, and whatever is second most 
important, it is a distant second.

I write D code all the time for my research. I want to write 
correct code quickly. My time is too valuable to spend weeks 
writing code to cut the running time by a few minutes. That might 
be fun for some people, but it doesn't pay the bills. It's close 
enough to optimized C performance out of the box. But ultimately 
I need a tool that provides fast code, has libraries to do what I 
want, and allows me to write a correct program with a limited 
budget.

This is, of course, not universal, but zero overhead is not 
important for most of the numerical code that is written.
Dec 07 2016
next sibling parent reply Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Wednesday, 7 December 2016 at 11:48:32 UTC, bachmeier wrote:

 On Wednesday, 7 December 2016 at 06:17:17 UTC, Picaud Vincent 
 wrote:

 Considering scientific/numerical applications, I do agree with 
 Ilya: it is mandatory to have zero overhead and a 
 straightforward/direct interoperability with C. I am impressed 
 by the Mir lib results and I think "BetterC" is very 
 attractive/important.


 As always, it depends on what you are doing. It is mandatory 
 for some numerical applications. R, Matlab, Python, 
 Mathematica, Gauss, and Julia are used all the time and they 
 are not zero overhead. A fast way to kill their usage would be 
 to force their users to think about those issues. What matters 
 is the available libraries, first and foremost, and whatever is 
 second most important, it is a distant second.

 I write D code all the time for my research. I want to write 
 correct code quickly. My time is too valuable to spend weeks 
 writing code to cut the running time by a few minutes. That 
 might be fun for some people, but it doesn't pay the bills. 
 It's close enough to optimized C performance out of the box. 
 But ultimately I need a tool that provides fast code, has 
 libraries to do what I want, and allows me to write a correct 
 program with a limited budget.

 This is, of course, not universal, but zero overhead is not 
 important for most of the numerical code that is written.


R, Matlab, Python, Mathematica, Gauss, and Julia use C libs. 
--Ilya
Dec 07 2016
next sibling parent reply bachmeier <no spam.net> writes:
On Wednesday, 7 December 2016 at 12:12:56 UTC, Ilya Yaroshenko 
wrote:


 R, Matlab, Python, Mathematica, Gauss, and Julia use C libs. 
 --Ilya


You can call into those same C libs using D. Only if you want a 
pure D solution do you need to be able to rewrite those libraries 
and get the same performance. D is a fine solution for the 
academic or the working statistician that is doing day-to-day 
analysis. The GC and runtime are not going to be an obstacle for 
most of them (and most won't even know anything about them).
Dec 07 2016
parent reply Jon Degenhardt <jond noreply.com> writes:
On Wednesday, 7 December 2016 at 16:33:03 UTC, bachmeier wrote:

 On Wednesday, 7 December 2016 at 12:12:56 UTC, Ilya Yaroshenko 
 wrote:


 R, Matlab, Python, Mathematica, Gauss, and Julia use C libs. 
 --Ilya


 You can call into those same C libs using D. Only if you want a 
 pure D solution do you need to be able to rewrite those 
 libraries and get the same performance. D is a fine solution 
 for the academic or the working statistician that is doing 
 day-to-day analysis. The GC and runtime are not going to be an 
 obstacle for most of them (and most won't even know anything 
 about them).


A cycle I think is common is for a researcher (industry or 
academic) to write functionality in native R code, then when 
trying to scale it, finds native R code is too slow, and switches 
to C/C++ to create a library used in R. C/C++ is chosen not 
because it the preferred choice, but because it is the common 
choice.

In such situations, the performance need is often to be quite a 
bit faster than native R code, not that it reach zero overhead. 
My personal opinion, but I do think D would be a very good choice 
here, run-time, phobos, gc, etc., included. The larger barrier to 
entry is more about ease of getting started, community (are 
others using this approach), etc., and less about having the 
absolutely most optimal performance. (There are obviously areas 
where the most optimal performance is critical, Mir seems to be 
targeting a number of them.)

For D to compete directly with R, Python, Julia, in these 
communities then some additional capabilities are probably 
needed, like a repl, standard scientific packages, etc.
Dec 07 2016
parent bachmeier <no spam.net> writes:
On Thursday, 8 December 2016 at 02:10:35 UTC, Jon Degenhardt 
wrote:

 A cycle I think is common is for a researcher (industry or 
 academic) to write functionality in native R code, then when 
 trying to scale it, finds native R code is too slow, and 
 switches to C/C++ to create a library used in R. C/C++ is 
 chosen not because it the preferred choice, but because it is 
 the common choice.

 In such situations, the performance need is often to be quite a 
 bit faster than native R code, not that it reach zero overhead. 
 My personal opinion, but I do think D would be a very good 
 choice here, run-time, phobos, gc, etc., included. The larger 
 barrier to entry is more about ease of getting started, 
 community (are others using this approach), etc., and less 
 about having the absolutely most optimal performance. (There 
 are obviously areas where the most optimal performance is 
 critical, Mir seems to be targeting a number of them.)


Rcpp is the most common dependency for R packages on CRAN. (I 
actually contributed an example that Dirk went on to use quite 
often, including his book.[1]) That motivated me to do something 
similar for D.[2] I have created other packages, though they have 
less documentation.[3]

It will be important to keep the technical requirements low if 
others are going to adopt D. I use the R package manager for 
everything, because Dub would require them to learn something 
that they'd view as weird. And having to understand memory 
management, as with Rust, would definitely not work. To this 
point I have focused on adding functionality and ease of 
installation so as to get my coauthors to use it. Mir is a 
wonderful project, but those advanced developers are not the ones 
that would embed D inside an R program, and they would definitely 
not feel comfortable with the things a 
statistician/econometrician expects.

[1] http://dirk.eddelbuettel.com/blog/2011/04/23/
[2] https://bitbucket.org/bachmeil/embedr
[3] For example, https://bitbucket.org/bachmeil/dmdgretl, 
https://bitbucket.org/bachmeil/dmdquadprog, 
https://bitbucket.org/bachmeil/dmdoptim
Dec 07 2016
prev sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Wednesday, 7 December 2016 at 12:12:56 UTC, Ilya Yaroshenko 
wrote:

 R, Matlab, Python, Mathematica, Gauss, and Julia use C libs. 
 --Ilya


As a C lib, you have the possibility of not initializing the 
runtime, which leaves usable a part of phobos+druntime and it's 
only a matter of avoiding TLS/globals and global ctor/dtor. No 
need to rewrite druntime this way.
https://www.auburnsounds.com/blog/2016-11-10_Running-D-without-its-runtime.html

-betterC is cleaner (link errors) but give more work.
Dec 08 2016
parent Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Thursday, 8 December 2016 at 09:57:21 UTC, Guillaume Piolat 
wrote:

 On Wednesday, 7 December 2016 at 12:12:56 UTC, Ilya Yaroshenko 
 wrote:

 R, Matlab, Python, Mathematica, Gauss, and Julia use C libs. 
 --Ilya


 As a C lib, you have the possibility of not initializing the 
 runtime, which leaves usable a part of phobos+druntime and it's 
 only a matter of avoiding TLS/globals and global ctor/dtor. No 
 need to rewrite druntime this way.
 https://www.auburnsounds.com/blog/2016-11-10_Running-D-without-its-runtime.html

 -betterC is cleaner (link errors) but give more work.


Link requirement is problem too. A numeric library for the 
language list above will never be accepted if this library 
depends on huge non portable runtime like D has. --Ilya
Dec 08 2016
prev sibling parent reply Picaud Vincent <picaud.vincent gmail.com> writes:
On Wednesday, 7 December 2016 at 11:48:32 UTC, bachmeier wrote:


 I write D code all the time for my research. I want to write 
 correct code quickly. My time is too valuable to spend weeks 
 writing code to cut the running time by a few minutes. That 
 might be fun for some people, but it doesn't pay the bills. 
 It's close enough to optimized C performance out of the box. 
 But ultimately I need a tool that provides fast code, has 
 libraries to do what I want, and allows me to write a correct 
 program with a limited budget.

 This is, of course, not universal, but zero overhead is not 
 important for most of the numerical code that is written.


I understand and I do agree with these points, honestly. These 
points are also the reason why I will maybe try to use D for my 
own codes (D is really much better than C++ concerning template, 
meta programming syntax, embedded unit tests etc...).

However I think that to popularize/attract people to use D, it is 
very important, to have a mechanism/feature that allows you to be 
close to the "zero overhead" situation.

If you have two concurrent libraries (even in different 
languages), people will adopt the fastest one... As an example, 
look at the BLAS lib, people do not try to read/understand the 
code to see how nice it is, they just look at benchmarks and take 
the fastest implementation for their architecture. IMHO that is 
the reason why D must let the opportunity, for those who want 
(library developers for instance) of coding down to the metal: 
the goal is to have visibility in benchmarks and to attract users.

At least it is my point of view.

-- Vincent
Dec 07 2016
next sibling parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 7 December 2016 at 15:17:21 UTC, Picaud Vincent 
wrote:

 On Wednesday, 7 December 2016 at 11:48:32 UTC, bachmeier wrote:


 [...]


 I understand and I do agree with these points, honestly. These 
 points are also the reason why I will maybe try to use D for my 
 own codes (D is really much better than C++ concerning 
 template, meta programming syntax, embedded unit tests etc...).

 However I think that to popularize/attract people to use D, it 
 is very important, to have a mechanism/feature that allows you 
 to be close to the "zero overhead" situation.

 If you have two concurrent libraries (even in different 
 languages), people will adopt the fastest one... As an example, 
 look at the BLAS lib, people do not try to read/understand the 
 code to see how nice it is, they just look at benchmarks and 
 take the fastest implementation for their architecture. IMHO 
 that is the reason why D must let the opportunity, for those 
 who want (library developers for instance) of coding down to 
 the metal: the goal is to have visibility in benchmarks and to 
 attract users.

 At least it is my point of view.

 -- Vincent


I don't understand this discussion at all. Why not have both? I 
don't need bare metal stuff at the moment but I might one day, 
and I perfectly understand that people may need it. At the same 
time, there are people who are happy with runtime/Phobos/GC. In 
my opinion it's not a question of "either or" but of "both and".
Dec 07 2016
next sibling parent Picaud Vincent <picaud.vincent gmail.com> writes:
On Wednesday, 7 December 2016 at 16:15:32 UTC, Chris wrote:


 I don't understand this discussion at all. Why not have both? I 
 don't need bare metal stuff at the moment but I might one day, 
 and I perfectly understand that people may need it. At the same 
 time, there are people who are happy with runtime/Phobos/GC. In 
 my opinion it's not a question of "either or" but of "both and".


Yes, I do agree, that is not exclusive. I only said that IMHO it 
would be very useful to have a clear "mechanism" (pragma, 
compiler flags...) to generate code close to what can be done 
with C. The goal being to have appealing (= fast & low memory 
footprint) libraries to attract people. That said, D with all its 
features GC, ... is great, but maybe that is not the feature that 
catches potential user attention the most.

-- Vincent
Dec 07 2016
prev sibling parent reply bachmeier <no spam.net> writes:
On Wednesday, 7 December 2016 at 16:15:32 UTC, Chris wrote:

 I don't understand this discussion at all. Why not have both? I 
 don't need bare metal stuff at the moment but I might one day, 
 and I perfectly understand that people may need it. At the same 
 time, there are people who are happy with runtime/Phobos/GC. In 
 my opinion it's not a question of "either or" but of "both and".


I can only speak for myself, but the concern is that we'll move 
in the direction of Rust, where you're supposed to read a 
dissertation on memory management before writing "Hello, World". 
The current state of affairs should be the default. Those with 
more advanced uses in mind should be able to do what they need, 
but it should be done without pushing away non-hard core 
developers.
Dec 07 2016
parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 7 December 2016 at 16:43:54 UTC, bachmeier wrote:

 On Wednesday, 7 December 2016 at 16:15:32 UTC, Chris wrote:

 I don't understand this discussion at all. Why not have both? 
 I don't need bare metal stuff at the moment but I might one 
 day, and I perfectly understand that people may need it. At 
 the same time, there are people who are happy with 
 runtime/Phobos/GC. In my opinion it's not a question of 
 "either or" but of "both and".


 I can only speak for myself, but the concern is that we'll move 
 in the direction of Rust, where you're supposed to read a 
 dissertation on memory management before writing "Hello, 
 World". The current state of affairs should be the default. 
 Those with more advanced uses in mind should be able to do what 
 they need, but it should be done without pushing away non-hard 
 core developers.


The "hard way" (no runtime/Phobos/GC) should not be the default 
and I hope that nobody is seriously suggesting this. It should be 
available in case anyone needs it. I dare doubt, however, that 
C/C++ programmers will take to D like ducks take to water because 
of it. It's been said time and time again that D's mission is no 
longer to convert C/C++ programmers ("a better C++") but to 
provide a good tool for programming. I think D still suffers from 
the slogan that it's "a better C++". Bad marketing, because 
you'll always be compared to C++. Imagine you date a woman and 
tell her "I'm a better your ex-boyfriend/ex-husband".
Dec 08 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Thursday, 8 December 2016 at 10:49:40 UTC, Chris wrote:

 The "hard way" (no runtime/Phobos/GC) should not be the default 
 and I hope that nobody is seriously suggesting this. It should 
 be available in case anyone needs it. I dare doubt, however, 
 that C/C++ programmers will take to D like ducks take to water 
 because of it.


especially considering that nobody in c++ land really talking 
about "we should drop c++ runtime". yes, in case somebody doesn't 
know, c++ also has runtime. and c too, by the way.

some people in c++ land avoiding using c++ features that require 
runtime (stl, rtti, etc.), but majority of programmers are ok 
with runtime. the very same is true for D. saying that "D will be 
more attractive to C++ programmers if we will remove runtime" 
is... i can't even find a word to describe it.

what can be done, tho, is article (or series of articles) 
describing what exactly druntime is, how it is compared to libc 
and libc++, why it doesn't hurt at all, how to do "bare metal" 
with custom runtime, why GC is handy (and how to limit GC impact 
if that is necessary), and so on. that is something D Foundation 
should do, i believe.
Dec 08 2016
next sibling parent reply Paolo Invernizzi <paolo.invernizzi no.address> writes:
On Thursday, 8 December 2016 at 11:09:12 UTC, ketmar wrote:


 what can be done, tho, is article (or series of articles) 
 describing what exactly druntime is, how it is compared to libc 
 and libc++, why it doesn't hurt at all, how to do "bare metal" 
 with custom runtime, why GC is handy (and how to limit GC 
 impact if that is necessary), and so on. that is something D 
 Foundation should do, i believe.


+1

/Paolo
Dec 08 2016
parent Guillaume Piolat <first.last gmail.com> writes:
On Thursday, 8 December 2016 at 11:32:56 UTC, Paolo Invernizzi 
wrote:

 On Thursday, 8 December 2016 at 11:09:12 UTC, ketmar wrote:


 what can be done, tho, is article (or series of articles) 
 describing what exactly druntime is, how it is compared to 
 libc and libc++, why it doesn't hurt at all, how to do "bare 
 metal" with custom runtime, why GC is handy (and how to limit 
 GC impact if that is necessary), and so on. that is something 
 D Foundation should do, i believe.


 +1

 /Paolo


+1

This is what technical domination is about :) not apologize for 
everything
Dec 08 2016
prev sibling next sibling parent Chris <wendlec tcd.ie> writes:
On Thursday, 8 December 2016 at 11:09:12 UTC, ketmar wrote:

 [...]

 what can be done, tho, is article (or series of articles) 
 describing what exactly druntime is, how it is compared to libc 
 and libc++, why it doesn't hurt at all, how to do "bare metal" 
 with custom runtime, why GC is handy (and how to limit GC 
 impact if that is necessary), and so on. that is something D 
 Foundation should do, i believe.


Amen. Features should never become a religion (else you'll get 
Java :).
Dec 08 2016
prev sibling next sibling parent reply Andrey <avraliov gmail.com> writes:
On Thursday, 8 December 2016 at 11:09:12 UTC, ketmar wrote:

 

 what can be done, tho, is article (or series of articles) 
 describing what exactly druntime is, how it is compared to libc 
 and libc++, why it doesn't hurt at all, how to do "bare metal" 
 with custom runtime, why GC is handy (and how to limit GC 
 impact if that is necessary), and so on. that is something D 
 Foundation should do, i believe.


+1
Dec 08 2016
parent Patric Dexheimer <patric.dexheimer gmail.com> writes:
On Thursday, 8 December 2016 at 12:10:55 UTC, Andrey wrote:

 On Thursday, 8 December 2016 at 11:09:12 UTC, ketmar wrote:

 

 what can be done, tho, is article (or series of articles) 
 describing what exactly druntime is, how it is compared to 
 libc and libc++, why it doesn't hurt at all, how to do "bare 
 metal" with custom runtime, why GC is handy (and how to limit 
 GC impact if that is necessary), and so on. that is something 
 D Foundation should do, i believe.


 +1


+1
Dec 08 2016
prev sibling parent Radu <void null.pt> writes:
On Thursday, 8 December 2016 at 11:09:12 UTC, ketmar wrote:

 what can be done, tho, is article (or series of articles) 
 describing what exactly druntime is, how it is compared to libc 
 and libc++, why it doesn't hurt at all, how to do "bare metal" 
 with custom runtime, why GC is handy (and how to limit GC 
 impact if that is necessary), and so on. that is something D 
 Foundation should do, i believe.


give the man a cigar!
Dec 08 2016
prev sibling parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Wednesday, December 07, 2016 15:17:21 Picaud Vincent via Digitalmars-d-
learn wrote:

 However I think that to popularize/attract people to use D, it is
 very important, to have a mechanism/feature that allows you to be
 close to the "zero overhead" situation.


You can do that without throwing away all of druntime and Phobos. You just
don't use the stuff with the overhead that you can't afford - e.g. if you
can't afford the GC, then don't use it.  nogc guarantees that for you. And
if you can't afford exceptions, then nothrow does that for you. IMHO, if you
ditch druntime and Phobos over GC concerns, you're throwing the baby out
with the bath water. Without druntime, you don't even get assertions or unit
tests or static constructors or array bounds checking or... I just can't
agree that throwing out druntime makes sense even in most really
performance-critical environments. Certain features would need to be
avoided, but it doesn't require throwing everything out.

That being said, if someone wants to make their life harder by insisting on
using D without even druntime, then that's their choice. I think that it's
an unnecessarily extreme approach even for really performance-centric code,
but they're free to do what they want.

- Jonathan M Davis
Dec 07 2016
parent Sebastien Alaiwan <ace17 free.fr> writes:
On Wednesday, 7 December 2016 at 21:52:22 UTC, Jonathan M Davis 
wrote:

 On Wednesday, December 07, 2016 15:17:21 Picaud Vincent via 
 Digitalmars-d- learn wrote:
 That being said, if someone wants to make their life harder by 
 insisting on using D without even druntime, then that's their 
 choice. I think that it's an unnecessarily extreme approach 
 even for really performance-centric code, but they're free to 
 do what they want.


It's not only a performance issue. Sometimes, your target 
platform simply doesn't have the runtime nor Phobos: Emscripten 
(asmjs), kernel mode code or bare metal embedded stuff.

I'm using D without druntime for my D-to-asmjs project. Avoid 
druntime certainly makes my life harder, but it makes the whole 
project possible.
Dec 07 2016
prev sibling next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko wrote:

 Good D code should be nothrow,  nogc, and betterC. BetterC 
 means that it must not require DRuntime to link and to start. I 
 started Mir as scientific/numeric project, but it is going to 
 be a replacement for Phobos to use D instead/with of C/C++.


Yes, perhaps it is so in your world...
In my world I have absolutely no need for this. In fact we are 
perfectly happy with Java runtime which is many times bigger than 
druntime!
Dec 07 2016
parent Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Wednesday, 7 December 2016 at 12:36:49 UTC, Dejan Lekic wrote:

 On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko 
 wrote:

 Good D code should be nothrow,  nogc, and betterC. BetterC 
 means that it must not require DRuntime to link and to start. 
 I started Mir as scientific/numeric project, but it is going 
 to be a replacement for Phobos to use D instead/with of C/C++.


 Yes, perhaps it is so in your world...
 In my world I have absolutely no need for this. In fact we are 
 perfectly happy with Java runtime which is many times bigger 
 than druntime!


Exactly, this is why D will never beat Java and Go. BTW, both 
languages has commercial support. Current D users are here 
because they are OK with current D runtime. The number of users 
is small. I don't expect/want that every one will agree.

I am targeting the ocean where we has not concurrents except 
C/C++.

GC for D is good as dub package or a compiler option.

Ilya
Dec 07 2016
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko wrote:

 Good D code should be nothrow,  nogc, and betterC. BetterC 
 means that it must not require DRuntime to link and to start.


Without runtime you won't have asserts (C has them), bounds 
checking, array casts, string switch. Doesn't sound good to me. 
And why is it a requirement at all? C and C++ already depend on 
their quite huge runtimes already. Why D shouldn't?
Dec 07 2016
parent Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Wednesday, 7 December 2016 at 13:14:52 UTC, Kagamin wrote:

 On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko 
 wrote:

 Good D code should be nothrow,  nogc, and betterC. BetterC 
 means that it must not require DRuntime to link and to start.


 Without runtime you won't have asserts (C has them), bounds 
 checking, array casts, string switch. Doesn't sound good to me.


All this can be done without runtime. It is weird that we need 
runtime for now for this features.


 And why is it a requirement at all? C and C++ already depend on 
 their quite huge runtimes already. Why D shouldn't?


Exactly, C already has a runtime. We can reuse it instead of 
maintaining our own.

I never said we must delete DRunime. I just need an 
infrastructure without runtime. And I am working on it.

Ilya
Dec 07 2016
prev sibling parent Igor Shirkalin <mathsoft inbox.ru> writes:
On Monday, 5 December 2016 at 20:25:00 UTC, Ilya Yaroshenko wrote:

 Hi e-y-e,

 The main problem with D for production is its runtime. GC, 
 DRuntime, Phobos is big constraint for real world software 
 production.


The almost only thing I do is real world software production 
(basically math and optimized math methods). D with it's GC, 
DRuntime and Phobos makes it what I really like and need for. I 
do my own libs for my own needs. Perhaps some day I will use Mir, 
but I don't care if it is with or without D's standard libs.

Igor Shirkalin.
Dec 10 2016
prev sibling next sibling parent sarn <sarn theartofmachinery.com> writes:
On Monday, 5 December 2016 at 17:18:25 UTC, e-y-e wrote:

 Currently I have been learning D for about a year and a half. 
 This may seem like a short time, but this is the longest I have 
 stuck with any language. I have only been learning for 4 years 
 and I am currently in university studying first year of 
 computer systems engineering.
 ...
 Does anyone have any advice for me?


Honestly, I recommend just learning C and C++.  Especially C if 
you're into low level stuff.  You won't just broaden your job 
market, you'll learn stuff that will help you use D more 
effectively.  You don't have to think of it as "leaving" the 
language.


 how can I replace some of the great things about D? Things like 
 built-in unittests, sane static if, painless CTFE, ranges, or 
 even just the DUB package manager/build tool.


You'll have to learn to do without them :)
Dec 05 2016
prev sibling parent aberba <karabutaworld gmail.com> writes:
On Monday, 5 December 2016 at 17:18:25 UTC, e-y-e wrote:

 Currently I have been learning D for about a year and a half. 
 This may seem like a short time, but this is the longest I have 
 stuck with any language. I have only been learning for 4 years 
 and I am currently in university studying first year of 
 computer systems engineering.

 My main problem is that now I am looking for industry 
 placements, it is clear that in this field C and C++ are highly 
 desired. I have used C++ prior to discovering D, but much of my 
 learning curve has occured while using D, and I feel quite 
 comfortable using it. Using D makes me look back at what a 
 great language it is compared to C++ (I know it can also be 
 compared to C but I haven't used C).

 Failing that, think of this as another one of those 'D is 
 great!' posts ;). And whatever happens, I'll certainly try and 
 convince my host company to use it...


"Those who will use D will use D". Tomorrow someone else will 
come and say "Oh, D is not picking up because of poor GC support 
to handle memory for large scale deployments".

To the comments above, let's have a prof on what you are saying. 
"Those who will use D will use D". Competition is bad. C++ did 
compeat with C and we now have a beast.

Set your goals and focus on that.
Dec 07 2016