Kotlin is a very interesting language, especially because its syntax is highly suited for declarative DSLs. In some ways it makes JSignal component code much easier to read and write. Specifically, it gives node building and component composition a more concise and cohesive syntax, and there is no need to write create custom builders for components because of named arguments and default values. For these reasons, I migrated some of the initial standard component prototypes to Kotlin. While this was an interesting experiment, ultimately, I think it is best that the component library be written in Java; the main reasons are enumerated below:
Less limited usage - From the outset, my desire was for this library to have a Java core, that is the reactive system and core UI internals (jsignal and jsigui). This was so that the library could have good performance on the JVM and leave open the ability to use it from other JVM language. Writing the standard component library (sigwig) in Kotlin means that the standard component library will not lend itself well to Java or other JVM languages, besides Kotlin.
Streamlined codebase - Having the entire project use Java, makes it much easier to maintain and contribute too. Not having to rely on Kotlin tooling makes the build process simpler and faster. Using a single language removes the need to mentally context switch when working on different modules. It also makes the codebase more approachable for contributors as they only need to know Java.
Anticipating the future - While this is more of a conjecture than the previous reasons, it seems to me that Java and Kotlin are moving along separate trajectories and I do not wish to bring the overhead of those broader issues into this project. On the micro scale this is apparent in Kotlin's lack of support for Java ergonomics. Using AutoClosable or standard functional interfaces from java.util.function in Kotlin feels clumsy and overly verbose. In my eyes, the only way to remedy many of the assorted ergonomic mismatches would be to almost always create Kotlin wrappers around Java code, which would consume a lot of energy from what is already a fairly ambitious personal project. Another example looking forward is the mismatch in concurrency models. I think that Kotlin's co-routines are almost perfect in their design, but I'm not optimistic about how well it will mesh with Java's virtual threads or developing structured concurrency API. On a macro scale, JetBrains seems to be focused on developing Kotlin's own multi-platform capabilities, whereas Oracle seems to be focused on improving Java's capabilities via the GraalVM platform.
In conclusion, Kotlin is a really great technology, but it simply does not align with my vision for this project. In the future, if/when the API for this library is significantly more stable, I would like to add first class Kotlin support via wrapper modules.
Kotlin is a very interesting language, especially because its syntax is highly suited for declarative DSLs. In some ways it makes JSignal component code much easier to read and write. Specifically, it gives node building and component composition a more concise and cohesive syntax, and there is no need to write create custom builders for components because of named arguments and default values. For these reasons, I migrated some of the initial standard component prototypes to Kotlin. While this was an interesting experiment, ultimately, I think it is best that the component library be written in Java; the main reasons are enumerated below:
AutoClosableor standard functional interfaces fromjava.util.functionin Kotlin feels clumsy and overly verbose. In my eyes, the only way to remedy many of the assorted ergonomic mismatches would be to almost always create Kotlin wrappers around Java code, which would consume a lot of energy from what is already a fairly ambitious personal project. Another example looking forward is the mismatch in concurrency models. I think that Kotlin's co-routines are almost perfect in their design, but I'm not optimistic about how well it will mesh with Java's virtual threads or developing structured concurrency API. On a macro scale, JetBrains seems to be focused on developing Kotlin's own multi-platform capabilities, whereas Oracle seems to be focused on improving Java's capabilities via the GraalVM platform.In conclusion, Kotlin is a really great technology, but it simply does not align with my vision for this project. In the future, if/when the API for this library is significantly more stable, I would like to add first class Kotlin support via wrapper modules.