On Friday, 23 June 2017 at 06:41:26 UTC, Bienlein wrote:
>> Java, Kotlin, C# are still Jit compiled languages, with the memory footprint to prove it :)
>
> The memory footprint doesn't matter. Those times are OVER :-).

Here are some references:

http://benchmarksgame.alioth.debian.org/u64q/go.html
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=gcc

There you can see how little memory Go uses compared to C and Java. Java will also get better as it will also get value types in some upcoming JDK.

On Friday, 23 June 2017 at 06:41:26 UTC, Bienlein wrote:
>> Java, Kotlin, C# are still Jit compiled languages, with the memory footprint to prove it :)
>
> The memory footprint doesn't matter. Those times are OVER :-).

People said that 30 years ago too... It is still an issue, though. Not as much as it was, but still relevant.

Programmers seem to be able to suck up whatever RAM is available on the low-end by adding frameworks, bloated libraries and runtimes, or just bugs…

On Friday, 23 June 2017 at 08:57:04 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 23 June 2017 at 06:41:26 UTC, Bienlein wrote:
>>> Java, Kotlin, C# are still Jit compiled languages, with the memory footprint to prove it :)
>>
>> The memory footprint doesn't matter. Those times are OVER :-).
>
> People said that 30 years ago too... It is still an issue, though. Not as much as it was, but still relevant.
>
> Programmers seem to be able to suck up whatever RAM is available on the low-end by adding frameworks, bloated libraries and runtimes, or just bugs…

I have not done any manual memory management at work for the last 25 years. Did some C++ programming at college and a bit at home where I had to take care of memory myself. That was it. Till I retire in 20 years I will also not have been doing any manual memory management. That kind of stuff only survives in very special areas where 0.1% of all software developers work.

That being said let me repeat that D needs a decent GC for being able to create any traction, because those 99.9% of the share are the far bigger market.

On Monday, 19 June 2017 at 16:13:20 UTC, Russel Winder wrote:
> I'd be more bothered by Kotlin native that Scala native.

Well, Kotlin/Native just came out with version 0.3. And it includes Windows support. Take that Apple/Swift ;)

Its impressive how fast things are being developer by Jetbrain.

There first release ( 0.1 ) on 31 March 2017.
Then Coroutines ( 0.2 ) on 11 May 2017.
Now Windows support ( 0.3 ) on June 23 2017.

On Friday, 23 June 2017 at 11:15:40 UTC, Bienlein wrote:
> I have not done any manual memory management at work for the last 25 years.

But are you doing any programming for the low end of the hardware spectrum? It has been the low end hardware limitations that have the standard for memory consumption…

On Friday, 23 June 2017 at 14:07:09 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 23 June 2017 at 11:15:40 UTC, Bienlein wrote:
>> I have not done any manual memory management at work for the last 25 years.
>
> But are you doing any programming for the low end of the hardware spectrum? It has been the low end hardware limitations that have the standard for memory consumption…

I'm assuming that D is for general purpose programming as well.

On Fri, 2017-06-23 at 13:14 +0000, Wulfklaue via Digitalmars-d wrote:
> On Monday, 19 June 2017 at 16:13:20 UTC, Russel Winder wrote:
> > I'd be more bothered by Kotlin native that Scala native.
> 
> Well, Kotlin/Native just came out with version 0.3. And it includes Windows support. Take that Apple/Swift ;)
> 
> Its impressive how fast things are being developer by Jetbrain.
> 
> There first release ( 0.1 ) on 31 March 2017.
> Then Coroutines ( 0.2 ) on 11 May 2017.
> Now Windows support ( 0.3 ) on June 23 2017.

I suspect this is a tribute to LLVM as well as the Kotlin Native team. Like LDC takes DMD frontend and injects into the LLVM backend, so Kotlin Native takes the Kotlin frontend and injects into LLVM.

Sadly they currently just use the GTK C API directly, rather than having a Kotlin idiomatic binding. Not competition for D in the GTK GStreamer arena just yet. I have however put in issues.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Friday, 23 June 2017 at 06:41:26 UTC, Bienlein wrote:
>> Java, Kotlin, C# are still Jit compiled languages, with the memory footprint to prove it :)
>
> The memory footprint doesn't matter. Those times are OVER :-).

Do you want D to compete in enterprise domain? Of 16 programs running on my machine 13 are native.

On Thursday, 22 June 2017 at 11:27:47 UTC, Paulo Pinto wrote:
> Java is AOT compiled to native code via Excelsior JET, IBM J9, IBM Websphere RealTime, JamaicaVM, SubstrateVM, Android ART and eventually Java 10.
>

Have you used one of these products? How do they deal with dynamic class loading? I know how JamaicaVM does it, no thanks.

>
> C# is AOT compiled to native code since day 1, via NGEN, althouth it isn't an optimizing compiler and only supports dynamic linking.
>

From https://docs.microsoft.com/en-us/dotnet/framework/net-native/net-native-and-compilation

"Because the .NET Native tool chain links implementation code into your app only if it knows that your app actually invokes that code, either the metadata or the implementation code required in the following scenarios may not be included with your app:

* Reflection.
* Dynamic or late-bound invocation.
* Serialization and deserialization.
* COM interop.

If the necessary metadata or implementation code is absent at runtime, the .NET Native runtime throws an exception. You can prevent these exceptions, and ensure that the .NET Native tool chain includes the required metadata and implementation code, by using a runtime directives file, an XML file that designates the program elements whose metadata or implementation code must be available at runtime and assigns a runtime policy to them. The following is the default runtime directives file that is added to a Windows Store project that is compiled by the .NET Native tool chain: ..."

> Better learn what the competition is actually doing.

Reflection and dynamic class loading are essential parts of C# and Java and do not work well with AOT compilation and never will. Money can't patch over design mistakes.

On Friday, 23 June 2017 at 19:27:56 UTC, Araq wrote:
> On Thursday, 22 June 2017 at 11:27:47 UTC, Paulo Pinto wrote:
>> Java is AOT compiled to native code via Excelsior JET, IBM J9, IBM Websphere RealTime, JamaicaVM, SubstrateVM, Android ART and eventually Java 10.
>>
>
> Have you used one of these products? How do they deal with dynamic class loading? I know how JamaicaVM does it, no thanks.

ExcelsiorJET is quite easy to figure out, you can download their open source version.

Some products go the static linking way, others map .jars into shared libraries.

>
>>
>> C# is AOT compiled to native code since day 1, via NGEN, althouth it isn't an optimizing compiler and only supports dynamic linking.
>>
>
> From https://docs.microsoft.com/en-us/dotnet/framework/net-native/net-native-and-compilation
>
> "Because the .NET Native tool chain links implementation code into your app only if it knows that your app actually invokes that code, either the metadata or the implementation code required in the following scenarios may not be included with your app:
>
> * Reflection.
> * Dynamic or late-bound invocation.
> * Serialization and deserialization.
> * COM interop.
>
> If the necessary metadata or implementation code is absent at runtime, the .NET Native runtime throws an exception. You can prevent these exceptions, and ensure that the .NET Native tool chain includes the required metadata and implementation code, by using a runtime directives file, an XML file that designates the program elements whose metadata or implementation code must be available at runtime and assigns a runtime policy to them. The following is the default runtime directives file that is added to a Windows Store project that is compiled by the .NET Native tool chain: ..."
>
>> Better learn what the competition is actually doing.
>
> Reflection and dynamic class loading are essential parts of C# and Java and do not work well with AOT compilation and never will. Money can't patch over design mistakes.

Nice how you overlook the fact that .NET Native requires static linking, hence why there are such issues.

AOT compiling to native code with either NGEN or Windows 8 MDIL compiler doesn't have such issues, because dynamic linking is used instead.

Also .NET Native is still kind of work in progress, as they still try to bring more features from System C# into regular .NET toolchain. With every Windows 10 SDK release there are new improvement made to it.

In any case, even if native compilation toolchains for Java and C# aren't perfect, they make it less appealing to try out D if you don't come up with a solid history to go against them, that make people actually curious to try out D.