Hello everyone
I am just curious (learning what Kotlin should and should not be used for).
I wanted to hear opinions of Kotlin Native candidate target applications will include.
I understand it will include low end devices like IoT, iOS devices, robots, etc. As I read it - Kotlin Native will not target systems programming tasks (OS and DBMS kernels) and will not target graphically intensive gaming, leaving this all to C++, Rust, Go, C, etc.
Traditionally C++ has been used for time critical apps like HFT (High Frequency Trading) and other time and performance critical low latency applications - which are neither systems programming nor gaming. Basically anywhere where virtual machines like JVM, .Net with their automatic garbage collection and JIT overheads were not acceptable - C++ won “by default”.
Hence my question of whether Kotlin Native will address/target the performance critical low latency applications needs where C++ is currently used.
Thank you.
It is question of tradition, not features. JIT does not anything to do with HFT problems, it affects program only during start and is problematic only for lightweight console applications. The GC pauses were considered problematic for those applications, but with arrival of low pause-GCs, it also should be solved. So people do not use JVM for those tasks not because the can’t, but because they are not used to.
Kotlin Native is not released yet, but when it will emerge, it will probably be a good competitor in this field. The overhead for reference counting is still will be higher than in Rust borrowing mechanics, but won’t have stop-the-world problem (I still believe, it is not that problematic in modern JVM). What is more important, it is much more safe and concise than C++ and it is a “new language”, meaning you can sell it to Java-haters.
1 Like
Thank you for your thoughts.
Why is Kotlin Native not being aimed at Systems Programming (OS and DBMS kernels, etc) tasks?
Is it mostly because it lacks direct memory access, which both C and C++ do have ?
Any other reasons?
I am sure any missing language features for systems programming could be added (and properly annotated so that work in specific environments).
Kotlin native does have direct memory access through memory scopes and pointers. I think it will have some uses in system programming in not quite near future, because it will need to be stabilized, optimized and tested first. Still, I do not think it is a good idea to use it in some critical system applications. It is still a general purpose language and could replace C++ in most places, but Rust is probably just better in this field, so no need to create a tool that is best everywhere. Probably better to focus on interop features.
1 Like
Yes, I agree re interop being the key more that systems programming at current time.
Python is very successful today in AI/ML and PySpark use space because it provides easy access to AI/ML libraries which are largely written in C/C++. Python provides easy access to Apache Spark too via PySpark, jpype, etc.
So if Kotlin could provide comparably easy access to the C/C++ ecosystem (i.e. AI/ML libraries) then I see it being able to, dare I say, replace Python there - which opens another vast area of use, namely - JVM, JavaScript and Python/AI/ML/PySpark traditional area and other C/C++ libraries too.
Kotlin can already work on Apache Spark due to its JVM/Java interop but it needs a lot of code samples, documentation, etc which PySpark, Scala and Java all do have.
Now C#. Net Core has Apache Spark support too, it just went into Preview Mode recently.
I think Kotlin deserves a large chunk of Apache Spark users, as it combines best of Scala/Java and Python in a single language. Just my opinion.
We have a lot of those discussions on kotlin slack in science channels family. You are welcome to join.