On Thursday, 8 October 2015 at 11:34:51 UTC, Chris wrote:
> in D. Then again, I don't know how Go and Rust will fare in a couple of years' time.

I think the C++ people are desperately trying to recapture the application market with some of the things that they propose for C++17/20. I think that market is dying fast for C++. I don't know about Rust, they seem to aim for high level programming. I think both C++ and Rust have too many syntax issues to be convenient for high level applications.

Go I think will do ok for focused web services with not too complicated logic. I don't think they will replace Java. I think Go will take the market where people have been using Java, but not really needed the feature set.

> The lines seem to blur over time, because any language is pretty useless without at least one powerful library to its name.

Applications benefit from frameworks, and then the desired frameworks dictate the language you use. So growth is difficult in that domain.

But you can implement you application model in an "engine language" and use a javascript framework for the UI with a browser engine in-between then the "engine language" can focus on efficient marshalling between that browser engine and the runtime.

So basically, break up the eco system so that you aren't locked into a small language (like D or Rust).

On Thursday, 8 October 2015 at 11:56:58 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 8 October 2015 at 11:34:51 UTC, Chris wrote:
>> in D. Then again, I don't know how Go and Rust will fare in a couple of years' time.
>
> I think the C++ people are desperately trying to recapture the application market with some of the things that they propose for C++17/20. I think that market is dying fast for C++. I don't know about Rust, they seem to aim for high level programming. I think both C++ and Rust have too many syntax issues to be convenient for high level applications.
>
> Go I think will do ok for focused web services with not too complicated logic. I don't think they will replace Java. I think Go will take the market where people have been using Java, but not really needed the feature set.

But a language like D that is already very feature rich cannot be dragged down to the level of Go anymore. D combines Go and Java, although in an incomplete way (as of now).

>> The lines seem to blur over time, because any language is pretty useless without at least one powerful library to its name.
>
> Applications benefit from frameworks, and then the desired frameworks dictate the language you use. So growth is difficult in that domain.
>
> But you can implement you application model in an "engine language" and use a javascript framework for the UI with a browser engine in-between then the "engine language" can focus on efficient marshalling between that browser engine and the runtime.
>
> So basically, break up the eco system so that you aren't locked into a small language (like D or Rust).

That's what I've been doing for 2-3 years now thanks to D. I use D as the core and everything else is glued onto the D core. D is actually pretty good at this. Since it's cross-platform, I can use the same code base everywhere. I don't need to worry about UIs or the like. On Windows, for example, I can compile the code into a dll and expose the functions that are needed. The UI can be in Python, Lua or whatever. I'm kinda using D as "C with high-level features". This is exactly what brought me to D, not having to worry about platforms anymore. Write once, connect to anything.

On Thursday, 8 October 2015 at 13:15:18 UTC, Chris wrote:
> That's what I've been doing for 2-3 years now thanks to D. I use D as the core and everything else is glued onto the D core. D is actually pretty good at this. Since it's cross-platform, I can use the same code base everywhere. I don't need to worry about UIs or the like.

Yes, I think this is the more scalable approach for both D, C++ and Rust.

For my use case (virtual world simulation) I'll probably end up using the first production level language that can provide tight asm.js codege, IEEE754-2008 support and guarantee reproducible results between client and server. But maybe I'll end up having to using a JIT on the server... I don't think there are any obvious alternatives at the moment. Maybe Rust will get there first.

On Thursday, 8 October 2015 at 13:45:43 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 8 October 2015 at 13:15:18 UTC, Chris wrote:
>> That's what I've been doing for 2-3 years now thanks to D. I use D as the core and everything else is glued onto the D core. D is actually pretty good at this. Since it's cross-platform, I can use the same code base everywhere. I don't need to worry about UIs or the like.
>
> Yes, I think this is the more scalable approach for both D, C++ and Rust.
>
> For my use case (virtual world simulation) I'll probably end up using the first production level language that can provide tight asm.js codege, IEEE754-2008 support and guarantee reproducible results between client and server. But maybe I'll end up having to using a JIT on the server... I don't think there are any obvious alternatives at the moment. Maybe Rust will get there first.

It'd be nice to have asm.js or even JS.

On Wednesday, 7 October 2015 at 13:15:38 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 7 October 2015 at 10:18:16 UTC, Kagamin wrote:
>> If you want to know what D is in details, see dlang.org for language spec.
>
> No, that is backwards. :-) The language spec is the product. What is needed is a definition of what the problem area is (e.g. use cases).
>
> problem area -> design -> language spec

Where do you think is a limit to applicability of a turing-complete language?

>> Semantic significance is that classes are polymorphic and hence reference types, structs are value types.
>
> Not real difference regarding pointers.

Pointers are of little use for a type that is always reference type.

>>> - Get rid of all gc-dependent language features.
>>
>> @nogc
>
> No, remove them from the language and replace them with library friendly constructs.

Make them not compile? @nogc does exactly that.
Reducing GC usage and emscripten backend are actionable if you want to work on them.

On Thursday, 8 October 2015 at 10:59:04 UTC, Ola Fosheim Grøstad wrote:
> I think D could do well if it focused on engine-level system programming and made sure it was absolutely top notch for that purpose. (Game engines, search engines, ray tracing engines, in memory database engines, business logic engines, etc).
>
> The current focus goes the other way. The current assumption is that engines are written in C/C++ and they are used to complete applications in D.

What D lacks in comparison to C w.r.t. to writing an engine?

On Thursday, 8 October 2015 at 16:25:09 UTC, Kagamin wrote:
> Where do you think is a limit to applicability of a turing-complete language?

?

> Pointers are of little use for a type that is always reference type.

You can have many different types of references.

> Make them not compile? @nogc does exactly that.

No, make the features work well without GC or change them.

> Reducing GC usage and emscripten backend are actionable if you want to work on them.

Changing the language is not "actionable" without creating a fork.

Regarding Emscripten, I don't see much value in spending so much work on getting something that isn't good enough to work. A higher level approach is needed for compact code gen. Possibly also language adjustments.

On Thursday, 8 October 2015 at 16:28:45 UTC, Kagamin wrote:
> What D lacks in comparison to C w.r.t. to writing an engine?

C is not really a comparable option language wise, C has not changed a lot since the 70s. But if you started to make a list of what the C eco system offers then you get a rather long list ranging from platform support to tooling and language extensions.

On Thursday, 8 October 2015 at 14:02:58 UTC, Chris wrote:
> It'd be nice to have asm.js or even JS.

The major ploblem I see right now with targeting asm.js is garbage collection. This can be worked around (I think) by having all pointers be fat pointers (size_t* stack_ref_count,T* data) and by having write barriers (that check for null for stack_ref_count) when coping pointers.

On Thursday, 8 October 2015 at 10:31:57 UTC, Chris wrote:
>> 2. Solid non-gc memory management and ownership.
>
> Any specific implementation in mind?

Well the first step to that should be implement a way to make sure pointers don't escape their scope.