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.

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

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.

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

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.

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.

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".

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.

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

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