> I suspect though that like Go took Python more than C folk, Kotlin Native will take more Java that C++, Go and Rust folks. But speculation rarely turn out quite as speculated.

In Java development there is almost no C or C++ and no Rust or D at all. Memory is no problem. Some server needs 256 GB RAM or maybe 512 GB? That's not an issue anywhere. As long as you get the performance through parallelisation there is no need for C or C++.

You won't meet any Java EE archtitecture that will do anything else than fight against calling C, C++ routines from Java. That is only done in some very exceptional cases.

The days of languages for systems programming are over. There are only very few people that need such a language. That is why D really needs a decent GC, otherwise it won't find any users that would do production systems with it.

On Thursday, 22 June 2017 at 07:15:26 UTC, Bienlein wrote:
> In Java development there is almost no C or C++ and no Rust or D at all. Memory is no problem. Some server needs 256 GB RAM or maybe 512 GB?

That is just sloppy... There is this bad trend in the industry, it has been going on for years. Performance issue, trow more hardware at the problem. Optimizations? Trow more hardware at the issue.

The problem being that it has becomes a constantly lowering expectations bar. Hire some basic programmers, use php/ruby/python and performance issues are simply overlooked as part of the job.

In my daily job seeing php import scripts that suck up a GB just for some basic work, is considered almost normal. Let the client pay for more performing servers. Our developers need to write more code, faster, be ready before the deadline so we can bill the client for the fast work.

> That's not an issue anywhere. As long as you get the performance through parallelisation there is no need for C or C++.

And while this works on a local server, the moment you start with clusters, master-slave configurations etc, things get complicated fast. Especially with latency issues.

> You won't meet any Java EE archtitecture that will do anything else than fight against calling C, C++ routines from Java. That is only done in some very exceptional cases.

That same applies to just about every other language. Native will always be prioritized before external calls.

> The days of languages for systems programming are over. There are only very few people that need such a language. That is why D really needs a decent GC, otherwise it won't find any users that would do production systems with it.

Technically, with Go, Rust, Crystal etc more about those high performing languages, then before. Before it was all about scripting languages, slowly you see a trend backing away from them.

On Thursday, 22 June 2017 at 07:32:51 UTC, Wulfklaue wrote:
> On Thursday, 22 June 2017 at 07:15:26 UTC, Bienlein wrote:
>> In Java development there is almost no C or C++ and no Rust or D at all. Memory is no problem. Some server needs 256 GB RAM or maybe 512 GB?
>
> That is just sloppy... There is this bad trend in the industry, it has been going on for years. Performance issue, trow more hardware at the problem. Optimizations? Trow more hardware at the issue.
>
> The problem being that it has becomes a constantly lowering expectations bar. Hire some basic programmers, use php/ruby/python and performance issues are simply overlooked as part of the job.
>
> In my daily job seeing php import scripts that suck up a GB just for some basic work, is considered almost normal. Let the client pay for more performing servers. Our developers need to write more code, faster, be ready before the deadline so we can bill the client for the fast work.
>
>> That's not an issue anywhere. As long as you get the performance through parallelisation there is no need for C or C++.
>
> And while this works on a local server, the moment you start with clusters, master-slave configurations etc, things get complicated fast. Especially with latency issues.
>
>> You won't meet any Java EE archtitecture that will do anything else than fight against calling C, C++ routines from Java. That is only done in some very exceptional cases.
>
> That same applies to just about every other language. Native will always be prioritized before external calls.
>
>> The days of languages for systems programming are over. There are only very few people that need such a language. That is why D really needs a decent GC, otherwise it won't find any users that would do production systems with it.
>
> Technically, with Go, Rust, Crystal etc more about those high performing languages, then before. Before it was all about scripting languages, slowly you see a trend backing away from them.

Massive relative price shocks can be important in shaping trends in the use of technology.  Storage prices drop 40% annually, Moore'a Law isn't what it was, and dram latency isn't improving nearly as fast as data sets are increasing in size.  Intel non volatile storage technology upsets all our assumptions about where the bottlenecks are, and there seems a decent chance that as you say the tilt away from slow languages is only just beginning.

https://www.quora.com/Why-is-Python-so-popular-despite-being-so-slow/answer/Laeeth-Isharc?share=5ebdf91a&srid=35gE

Acam paper linked at the end of this.

On Thu, 2017-06-22 at 07:15 +0000, Bienlein via Digitalmars-d wrote:
> > 
[…]
> In Java development there is almost no C or C++ and no Rust or D at all. Memory is no problem. Some server needs 256 GB RAM or maybe 512 GB? That's not an issue anywhere. As long as you get the performance through parallelisation there is no need for C or C++.

The whole "Just add more memory" approach of JVM installations leads to some really crap programs and programming. And what is worse, they do not even do parallelism properly. Whenever I did Java workshops, I was always dreadfully disappointed how bad at programming the lower 50% of programmers were. I.e. the average Java programmer is really not very good.

A fairly good metric in the UK is, if a supposed Java programmer hasn't heard of DevoxxUK or JAXLondon or has heard of them but doesn't want to go, then they are not a Java programmer, they are just robots turning out Java code, disinterested in their profession..

> You won't meet any Java EE archtitecture that will do anything else than fight against calling C, C++ routines from Java. That is only done in some very exceptional cases.

Same goes for people sensibly avoiding Java EE and using Springboot or container-base system, even those using Tomcat. JNI is horrible, to be used only if absolutely necessary. Hence JNA, JNR, etc. all designed to make FFI easier with the JVM. The next round of Charlie Nutter's assault on JVM FFI may make things a lot better.

> The days of languages for systems programming are over. There are only very few people that need such a language. That is why D really needs a decent GC, otherwise it won't find any users that would do production systems with it.

It depends what you mean by systems programming. Go folk for example seems to thing anything to do with The Web is systems programming.

Whilst many people see The Web as the only thing that programmers do, I bet that most software has nothing to do with it. JVM-based system account for a lot, but it is nearly all Web oriented. Python has hegemony currently (but not for long I'll wager) in AI and machine learning. Many, including some Scala and Kotlin folk see the constraints of the JVM (that containers, Docker, and Kubernetes have quite nicely highlighted) – native code is resurgent.

But yes, there are different forms of native code, and I agree, there
are places where a GC cannot be used (hard real time currently, but
people are working on that, again cf. Go folk), and the rest where GC
is a good thing. But only a good GC is a good thing – this lesson comes
from 20 years of JVM. The JVM has encouraged research and
implementation of GCs.

-- 
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 Thursday, 22 June 2017 at 07:15:26 UTC, Bienlein wrote:
>> I suspect though that like Go took Python more than C folk, Kotlin Native will take more Java that C++, Go and Rust folks. But speculation rarely turn out quite as speculated.
>
> In Java development there is almost no C or C++ and no Rust or D at all. Memory is no problem. Some server needs 256 GB RAM or maybe 512 GB? That's not an issue anywhere. As long as you get the performance through parallelisation there is no need for C or C++.
>
> You won't meet any Java EE archtitecture that will do anything else than fight against calling C, C++ routines from Java. That is only done in some very exceptional cases.

This includes how Android developers see the use of the NDK, and I
quote:

"""
Squeeze extra performance out of a device to achieve low latency or run computationally intensive applications, such as games or physics simulations.

Reuse your own or other developers' C or C++ libraries.
"""

https://developer.android.com/ndk/guides/index.html

Anything else is frowned upon and only available to Java, requiring JNI calls to access the features from C and C++.

They even pivoted Brillo from a being a simplified Android with C++ Framework, to a simplified Android where even user space drivers can be written in Java.

https://developer.android.com/things/sdk/drivers/index.html

>
> The days of languages for systems programming are over. There are only very few people that need such a language. That is why D really needs a decent GC, otherwise it won't find any users that would do production systems with it.

This was quite visible at this year's WWDC, Google IO and BUILD.

They were all about Swift, Java, Kotlin, C#.

There were hardly any meaningful talks with C or C++ content related to actual software development on their OSes, other than to share the latest improvements in compiler/IDE tooling and ANSI C++ compliance.

On Thu, 2017-06-22 at 10:00 +0000, Paulo Pinto via Digitalmars-d wrote:
> […]
> 
> They were all about Swift, Java, Kotlin, C#.
> 
Isn't Swift a native code language?
> 
-- 
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 Thursday, 22 June 2017 at 10:23:37 UTC, Russel Winder wrote:
> On Thu, 2017-06-22 at 10:00 +0000, Paulo Pinto via Digitalmars-d wrote:
>> […]
>> 
>> They were all about Swift, Java, Kotlin, C#.

Those are also the major players in the market. C# Microsoft, Swift Apple, Java Oracle... so there is more focus on them naturally.

> Isn't Swift a native code language?

Yep ... Its it uses LLVM.

Java, Kotlin, C# are still Jit compiled languages, with the memory footprint to prove it :)

C# may change to a native compiled language with CoreRT ( This translates C# to C++ code and then compiles it. A bit like Haxe (C++ target) or Nim(C target) ).

On Thursday, 22 June 2017 at 11:11:01 UTC, Wulfklaue wrote:
> On Thursday, 22 June 2017 at 10:23:37 UTC, Russel Winder wrote:
>> On Thu, 2017-06-22 at 10:00 +0000, Paulo Pinto via Digitalmars-d wrote:
>>> […]
>>> 
>>> They were all about Swift, Java, Kotlin, C#.
>
> Those are also the major players in the market. C# Microsoft, Swift Apple, Java Oracle... so there is more focus on them naturally.
>
>> Isn't Swift a native code language?
>
> Yep ... Its it uses LLVM.
>
> Java, Kotlin, C# are still Jit compiled languages, with the memory footprint to prove it :)
>

Java is AOT compiled to native code via Excelsior JET, IBM J9, IBM Websphere RealTime, JamaicaVM, SubstrateVM, Android ART and eventually Java 10.

Sun was the only one religilous against any kind of AOT support, all major commercial JDKs always supported AOT compilation.

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

C# and VB.NET for Windows 8 and Windows 8.1 only support AOT compilation to native code via a format called MDIL (Machine Dependent Intermediate Language), basically native code with symbolic labels, linked on the devices at installation time.

C# and VB.NET for UWP are always AOT compiled to native code and static linking is used.

Better learn what the competition is actually doing.

On Thursday, 22 June 2017 at 10:23:37 UTC, Russel Winder wrote:
> On Thu, 2017-06-22 at 10:00 +0000, Paulo Pinto via Digitalmars-d wrote:
>> […]
>> 
>> They were all about Swift, Java, Kotlin, C#.
>> 
> Isn't Swift a native code language?

Just like Java when one uses any commercial JDK or C# when targeting UWP or Windows 8.x devices.

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