[echelon]

That's wrong! Those fall squarely in the application domain.

By your argument Ruby and Python are also systems languages because they can be used to write servers and job queues.

You're not doing real time programming with Go. Don't make systems programming lose its meaning by promulgating this myth.

[sl1ck731]

Real-time programming can be done in any language, Java for example.

I think you're conflating writing device drivers/kernels with systems programming, which includes those things but is not limited by them.

Regardless, the term's meaning can't be lost if its apparently this hazy.

[zepolen]

I don't think you understand what real time programming is.

[sl1ck731]

Enlighten me, please.

https://www.aicas.com/cms/rtsj

http://blogs.windriver.com/wind_river_blog/2017/05/java-on-v...

[zepolen]

Real time programming requires you to be able to make hard guarantees about how long a certain piece of code can run and what resources it uses.

This is literally impossible with a GC because you can only bound one resource (time or memory) at a time.

The best RTS languages are a pain in the ass to use because the compiler will complain about every single thing - cases that could go wrong with your code

They are used in mission critical (in all sense of the word) systems like spaceships - where a tiny bit of lag will send it thousands of miles in the wrong direction.

Those links you provided, one is a draft for a spec, it's not even implemented yet - and the other has nothing to do with real time languages.

[echelon]

This is swapping out the JVM. It's not even the same language at that point.

[sl1ck731]

Maybe it would be easier for both of us if you wrote the definition for real-time or systems programming, rather than just saying something isn't one or the other.

[crimsonalucard]

Look, a good systems language should have predictable assembly instructions that the code compiles into. You should be able to literally with your eye map from code to asm and jump back and forth in a systems level language. GC enabled languages don't have this property as the assembly would be littered with GC code to clean up things. You won't be able to map back and forth.

You will note that rust advertises themselves as a systems level language and it is deliberately designed with the term zero cost abstraction. All this means is predictable asm from code. No black magic. Rust is advertised as systems level and this is the property that enables it. I hope that allows you to understand what it means to be systems level.

I truly believe that you are completely wrong and only few languages nowadays are system languages without a GC. C++, C, D (when used without the GC) and rust are examples. All the other languages you listed aren't.