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.

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!

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

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?

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

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.

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

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

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

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