Aggrivet: Go or not to go?

Go or not to go? After 10 years of C++ software development, and sometimes spending more time with writing make files and adjusting build configurations, 'discussing' advantages of build systems (cmake vs bjam), than with programming; and without a platform independent dependency management for C++, as part of the language standard on the horizon, spending more time in setting up dependencies than I wish I would, it's time to have a look at alternatives.

What criteria to use to evaluate the suitability of a programming ecosystem for scientific computing?

Some requirements (*** - very important, **-important, *- nice to have) :

Simplicity ***
Dependency management as part of the language standard ***
Build system implicit - preferably by convention - NO makefiles, CMaklists.txt, bjam etc ***

But if implicit how does it support integration of platform specific third party C API libraries (i.e. windows specific dll for hardware)?

Are compiler options part of the language standard ***
Is the documentation format part of the standard?*
Compile time. **
Runtime performance. * (as long as it is factor 10 for 99.9 of the use cases compared with C it's fine).
Threading support
Ease to integrate legacy C and C++ code (i.e. ffi - java project Panama, better late than never) *
extern "C"; C linkage - be able to expose C interface, so integration in other languages through an C interface possible. Creating lib's with C interface possible. *
Support in deploying applications (preferably and ideally statically linked executable).
Tooling support (java eclipse, intellij) **

interactive debugger **
lint tool
test runner
test coverage tool **

Std library - support for logging, testing, serialization to text formats.
Language - "fits into a single developers mind". **
Platform independence (linux and windows suffices) **
Coding style guidelines part of the language standard. **
Modern syntax (python) **.

Add 8. and 9. It is a must have, but since C and C++ does not have a dependency management and you cant just specify a dependency to some C++, just to have the dll as a dependency, not speaking about linking to it, is a pain already -> see C and C++ lack of package manger...

Summary

Python has it to a large extend, and although it does not make the cut in point 7 and 8 (although one could argue that cython has it) it's anyway in. I use it everyday but as a platform independent bash. Compared with bash it's a huge step forward ;-).

I am going to more closely evaluate : JVM and java in particular (with groovy or kotlin as goodies), Go and D.

JVM

Java or rather the JVM with modern languages such as Kotlin or Groovy, with its huge code base, and popularity exceeding since many years that of C++ and matching that of C in programming language rankings, is by far the strongest contender.

Some new features planned for java 9 (module system - Jigsaw - which will reduce startup times and memory footprint) and java 9+ such as Java project Valhalla (especially value objects) or Panama are exciting.

So why at all to consider anything else:
- JVM not a default on many architectures/machines
- memory footprint (see value objects which aren't there yet and who knows if they arrive and when).

- you can't just run it on the command line as a native binary. You will need some executable wrapper.
- Actually 2 Javas - Oracle java and Android Java 6 and the housekeepers have a fight about it since many years although according to news from http://www.heise.de/developer/meldung/Android-N-Googles-Mobilsystem-wird-auf-Open-Source-Java-OpenJDK-aufsetzen-3057453.html Google seems to be moving to OpenJDK.

Ad 2. there is no standard although maven is the "semi standard". Still the mvn files are sometimes 1000 lines long, support by the IDE's is mixed, and each IDE has it's own build system in addition.

Pros:
- community and 3 party libraries with spark, hadoop, weka an imagj etc etc.

GO

General introduction:
https://talks.golang.org/2012/splash.article

ad 5: https://golang.org/cmd/cgo/
ad 9.1 : https://blog.cloudflare.com/go-has-a-debugger-and-its-awesome/

ad 1: There are not there yet although they recognized it as essential