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:[email protected] 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
