On Thursday, 8 October 2015 at 17:56:57 UTC, Freddy wrote:
> 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.

Currently effective garbage collection is not possible since you cannot scan the stack. I think GC features are planned for some future version of WebAssembly.

However, you can generate asm.js like Javascript for gc code.

Or just require nogc.

asm.js also don't have exceptions and goto, neither does it have umul, udiv or 64 bit integers.

Non of those are show stoppers, but efficient code gen requires using what asm.js does well...

On Thursday, 8 October 2015 at 14:02:58 UTC, Chris wrote:
> 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.

Look at Adam Ruppe's D to JavaScript compiler.  It hasn't been maintained, but it was a very interesting experiment.

I wish there were more interest in having LDC generate JS via LLVM a la emscripten.  Some serious people think it's not that difficult.

On Thursday, 8 October 2015 at 18:29:00 UTC, Laeeth Isharc wrote:

>>
>> It'd be nice to have asm.js or even JS.
>
> Look at Adam Ruppe's D to JavaScript compiler.  It hasn't been maintained, but it was a very interesting experiment.
>
> I wish there were more interest in having LDC generate JS via LLVM a la emscripten.  Some serious people think it's not that difficult.

To be honest, rather than having IDEs and all the bells and whistles (which started this thread), I'd prefer D to cater for things like asm.js and ARM processors. Nim got it right in the sense that it allows developers to write code and ship it to web browsers and everything else that understands JS. Writing JS is a pain in the "sit upon", being able to write code in a decent language and have it output as JS is great. There's no way around the web, i.e. JS.

@Ola

That said one has to be careful when looking at other languages such as Go and Rust. I remember the VM fashion a couple of years back (mainly Java and C#), but still languages that compile to native code kept coming up and now everyone goes native, including the VM supporters. Why? Cos it didn't work and everybody working with Java realized that, it's too fookin slow. How can we tell that Go is the way to go (pardon the pun)? Maybe in a few years' time the thing to do will be library based memory management. One of D's strengths is to be impervious to fashion and to try to do what's right and what works. Ironically enough, C++ is playing catch up with D. D might not get the credit that's due, but D proves that certain concepts work better than others. But who ever gives credit to the lab rats? :-)

On Friday, 9 October 2015 at 10:13:07 UTC, Chris wrote:
> such as Go and Rust. I remember the VM fashion a couple of years back (mainly Java and C#), but still languages that compile to native code kept coming up and now everyone goes native, including the VM supporters. Why? Cos it didn't work and everybody working with Java realized that, it's too fookin slow.

VMs and JIT compilation works well for things that aren't engine level, like most of the application level code. I think sluggish performance for has more to do with static typing and memory layout than codegen (sans SIMD).

So maybe just compiling to JIT friendly Javascript with typed arrays is good enough. The problem is that you need to know all the JITs and runtimes in order to figure out what kind of Javascript constructs you need to use. Basically figuring out what "templates" the JITs translate into efficient machine code.

> How can we tell that Go is the way to go (pardon the pun)?

Go is not the way to go in general, but it is currently the best option for ahead of time compiled web services that are I/O bound. But for me it is _primarily_ an infrastructure issue. Infrastructure issues makes it difficult to compete with languages like Go, Java and Python for web servers.

> Maybe in a few years' time the thing to do will be library based memory management.

I think that is unlikely given all the research on pointer analysis etc.

> One of D's strengths is to be impervious to fashion and to try to do what's right and what works. Ironically enough, C++ is playing catch up with D.

C++ is under pressure from Rust, Go and perhaps also D. Mostly because it takes years (or decades) to get new features into C++, so they have to start working on new features early. I am not even sure we would have seen the C++ guidelines/GSL initiative without Rust. They basically bypassed the standard process in order to "add features" faster by pushing it at CppCon...

On Friday, 9 October 2015 at 12:05:13 UTC, Ola Fosheim Grøstad wrote:
> C++ is under pressure from Rust, Go and perhaps also D. Mostly because it takes years (or decades) to get new features into C++, so they have to start working on new features early. I am not even sure we would have seen the C++ guidelines/GSL initiative without Rust. They basically bypassed the standard process in order to "add features" faster by pushing it at CppCon...

and in typical C++ fashion, it's going to just be a gigantic ugly hack

On Friday, 9 October 2015 at 12:06:40 UTC, rsw0x wrote:
> On Friday, 9 October 2015 at 12:05:13 UTC, Ola Fosheim Grøstad wrote:
>> C++ is under pressure from Rust, Go and perhaps also D. Mostly because it takes years (or decades) to get new features into C++, so they have to start working on new features early. I am not even sure we would have seen the C++ guidelines/GSL initiative without Rust. They basically bypassed the standard process in order to "add features" faster by pushing it at CppCon...
>
> and in typical C++ fashion, it's going to just be a gigantic ugly hack

But never mind, it's gonna be _the_ innovation and C++ people will say "Why use D, we have it in C++! D is outdated! C++ is modern!" There gonna be books like "Modern programming in C++" for $68+. It's so boring, so predictable.

On Thursday, 8 October 2015 at 16:47:44 UTC, Ola Fosheim Grøstad wrote:
> 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.

So D as a language is better than C for engine development, it's just tools and libraries, that get the boring work done, are not written in it yet?

On Thursday, 8 October 2015 at 16:43:12 UTC, Ola Fosheim Grøstad wrote:
>> Pointers are of little use for a type that is always reference type.
>
> You can have many different types of references.

You can have class references in D.

>> Make them not compile? @nogc does exactly that.
>
> No, make the features work well without GC or change them.

What @nogc features don't work without GC?

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

Reduction of GC usage is a work on phobos to make its algorithms usable without GC. But you can think of phobos as an extension to the language, there's a word that libraries are DSLs extending the core language, to improve range implementation in phobos you don't need to create 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.

If emscripten backend is not good enough for you, how it is related to D?

On Friday, 25 September 2015 at 08:59:17 UTC, Jonathan M Davis wrote:
> On Friday, 25 September 2015 at 08:53:41 UTC, John Colvin wrote:
>> On Friday, 25 September 2015 at 07:26:13 UTC, rumbu wrote:
>>> Starting Visual Studio on my machine takes 2 seconds,
>>
>> What magic are you doing to achieve this? It has always taken
>> >30 seconds on mine.
>
> LOL. On my work computer (which is no slouch), it takes something like two or three minutes to actually be usable, where it's frozen, saying "not responding." gvim, on the other hand, starts instantly.
>
> - Jonathan M Davis

vs starts is usable in about 2 second for me also.  Try using a computer from the modern era with an SSD.

On Friday, 9 October 2015 at 21:17:16 UTC, Dogbreath wrote:
> On Friday, 25 September 2015 at 08:59:17 UTC, Jonathan M Davis wrote:
>> On Friday, 25 September 2015 at 08:53:41 UTC, John Colvin wrote:
>>> On Friday, 25 September 2015 at 07:26:13 UTC, rumbu wrote:
>>>> Starting Visual Studio on my machine takes 2 seconds,
>>>
>>> What magic are you doing to achieve this? It has always taken
>>> >30 seconds on mine.
>>
>> LOL. On my work computer (which is no slouch), it takes something like two or three minutes to actually be usable, where it's frozen, saying "not responding." gvim, on the other hand, starts instantly.
>>
>> - Jonathan M Davis
>
> vs starts is usable in about 2 second for me also.  Try using a computer from the modern era with an SSD.

LOL. I _do_ use a computer with an SSD.

- Jonathan M Davis