This, of course, depends on your definition of "compete" and "system-level" (e.g. I have no problem competing with professional athletes too, I just have a very serious problem winning against them but the competition is no problem at all).
I write code that I consider system level (it talks to the hardware directly) and "tricky" is quite an understatement. Starting from the fact that there are half a dozen types of memory (not even talking about memory-mapped I/O) and just one "heap" in Java. Not to mention the hardware is not aware about the awesomeness of JVM and is trying to read/write actual memory pointers. I can imagine that you could get around this (as well as the lack of bit-fields and unsigned types) through some kind of memory-mapped-as-a-file trick but at this point you are not using the memory management at all. And IMHO this is very far from being "not any harder" than using pointers in C++.
When directly talking to hardware, C is enough. Noone is saying Java is fine doing low level stuff like device drivers (IMHO wrong tool for the job, and C++ is wrong, too). I was refering to database systems or other software that is very close to system, e.g. application- or web-servers. In this area Java is excellent choice and performance-wise it often beats C++ because of superior concurrency support. And you can always code the low-level pieces in C, if you really need those unsigned arithmetic or bitfields.
Nobody is talking about C's insufficiency for programming. When doing anything C is enough just like any other Turing-complete language.
You'd been saying that in your humble opinion system programming in Java is no harder than in C++, which is something very alien to my experience of actually programming on the system level (as same as your performance claims but I am not even going to get into this one. Last time I did a Java programmer told me that a Java program that is measuring as 4 times slower is running "on the same level", whatever that means).
Is Netty system-level enough? Or Cassandra? Or Tomcat? Or Apache Spark? Or Hadoop? Or Akka? For some reasons devs chose Java to implement them, not C++.
As of performance, they are doing extremely well. Last time I checked Netty vs Nginx was a tie; Tomcat vs Apache HTTP were also extremely close; Apache Spark (pure Java) is generally much faster than Impala (using C++); and Cassandra has no direct competitors written in C++ so far (not counting 1000 toy databases here), but it is definitely one of the top performant NoSQL stores out there.
Sorry, I don't know what any of these does. When I went to school it was common convention that system level is the OS kernel, drivers and anything else that talks to the hardware.
Right. Now show me some widely used OS kernel written in C++. No, not some research thing. Becaue I hear all the time C++ is a system level language, yet it is most widely used to write games and desktop apps, not systems.
Console games are just applications like any other PC game. They access hardware by communicating with OS services. The only difference is in consoles you exactly know your hardware and you can make better use of it and OS provides less than a full blown PC OS. But this is not related to Java vs C++ debate. Java is capable of accessing hardware directly. There is even some hardware that directly runs Java or some low-end embedded systems running Java.
As of XNU, it is mostly pure C. There are a few C++ files there but they are very far from what we call "modern C++". No templates, no use of standard library, no exceptions, const char* everywhere. Just C with classes.
It appears you are either trolling or simply don't know what are you talking about. Either way there is nothing to be gained from this discussion for either of us.
"many developers tend to forget that what makes C and C++ usable for systems programming are actually language extensions that are not part of the standard."
Excuse me but what??? Please give an example. Except for maybe setting up an isr vector table and the odd coprocessor command in assembler, all other peripheral functionality is usually memory mapped and perfectly accessible in C and C++.
All the hardware interface is through shared/mapped memory nowadays (there are CPUs with a dedicated I/O bus or fancy coprocessor interfaces too but even there the bulk of work is creating control structures in memory and then kicking them through a port or a coprocessor instruction). C/C++ are perfect for the memory manipulation even in their purest standard form. I imagine your concern is about deriving the addresses for register apertures or emitting specific opcodes?
For the concrete addresses you just link with the symbols defined outside of your C code. Special ops cannot be done in pure standard, but this is not an issue in practice as there are no pure standard compilers. Even for app development you want intrinsics just for the vector, cache and bit instructions.
No, the point being that without language extensions, a C++ AOT compiler is in the same ballpark as a Java AOT native compiler.
You need an external Assembler or OS APIs to provide the required functionality. The same way that a Java runtime library can provide bindings to Assembly or OS APIs.
There are commercial AOT native compilers for Java targeting systems programming, like the ones from Atego.
I guess it depends on the size of the ballpark. 99.99% of code I write is pure C++ as all I do is, essentially, moving data around memory. My wild guess is that using Java I had to put these 99.99% into some external library as Java does not support memory manipulation. Either way, we went quite far from the original point of managed memory being a good thing (almost always).
I was just playing devil's advocate a bit, because many developers tend to forget that what makes C and C++ usable for systems programming are actually language extensions that are not part of the standard.
Many mainstream languages, with AOT native compilers would be as usable.
Most developers never read the standard in the first place. I don't see how is this important though. We did not have a standard till 1998, yet somehow managed to use C++. Same as with C, which had been used very successfully standard-less for almost two decades.
> Most developers never read the standard in the first place. I don't see how is this important though.
Do you write portable code in C and C++ across disparate systems and OSs, using multiple compilers?
I used to do that between 1994 and 2001. Don't miss those days of hit-and-miss about compiler support.
> We did not have a standard till 1998, yet somehow managed to use C++.
Yes we did. It was called the Annotated Reference Manual, used as basis for the standard, coupled with articles from The C++ Report, The C Users Journal (latter The C/C++ Users Journal).
> Same as with C, which had been used very successfully standard-less for almost two decades.
It works if you only care about one specific compiler. On those days the standard was the AT&T UNIX compiler.
Obviously, you cannot write portable system code. You can do conditional compilation to target multiple platforms though. And when you do that you realize two things:
1. No compiler is fully compliant with any standard.
2. Every compiler has bugs so even the compliant parts can be unusable.
And then you realize it's not a big deal. Changes between platforms are greater than changes between compilers. When your targets have different endianness or, even better, mixed endianness between different PUs - the standard compliance of your code is the least of your worries.
>It works if you only care about one specific compiler.
Also works if you care about a finite number of specific compilers and architectures.
>On those days the standard was the AT&T UNIX compiler.
There were, probably, hundreds of compilers and C flavors even before the ANSI C. What one thought was "the standard" was very subjective.
I write code that I consider system level (it talks to the hardware directly) and "tricky" is quite an understatement. Starting from the fact that there are half a dozen types of memory (not even talking about memory-mapped I/O) and just one "heap" in Java. Not to mention the hardware is not aware about the awesomeness of JVM and is trying to read/write actual memory pointers. I can imagine that you could get around this (as well as the lack of bit-fields and unsigned types) through some kind of memory-mapped-as-a-file trick but at this point you are not using the memory management at all. And IMHO this is very far from being "not any harder" than using pointers in C++.