The core functionality of this container is written in Bash. The benefit of this is that many people have some experience with bash and the threshold for contributing has therefore hopefully been lowered.
Maintaining it is not always fun though. This might just be me, but even if I've scripted a lot of bash over the years I don't feel "safe" doing it. There are so many different versions of it, and what works on my Mac doesn't always play well in a Linux container, etc. I also feel that the control flow of a Bash script is harder to read.
In short. I wanted to experiment with rewriting it to a more modern language with better tooling and maybe even type safety and compiler support to reduce the "guessing my way in bash"-driven development that often comes of trying scripts until it works.
I'm a developer with a lot of experience with Java and the ecosystem around the JVM in general. So when I started playing with Kotlin Scripts I figured it was worth a shot to rewrite this project using Kotlin. I will push a beta branch containing the Kotlin code and then I'll update with a section here on what features are in it and what still needs to be migrated.
Before going all the way with this I want to run it by whoever is interested in discussing it.
Personally, while I agree with your sentiments on Bash, I think it's one of the better choices for this kind of functionality. It keeps the container dependencies minimal and runs with minimal overhead. It's just enough to do everything that needs to be done.
If moving to a more ergonomic language is inevitable though, maybe something that compiles down to a static binary (Go, Rust, ...?) instead of a JVM language that then requires all that runtime overhead and bloats the container?
BTW thanks for all your work on this project! :slightly_smiling_face: In the end, as an end-user, as long as it works I'll be happy - regardless of how we get there.
Thanks for the feedback @rbtr. I agree there is a stink to the JVM when it comes to overhead.
For this project it would be limited to the image size though, as the scripts are only run before startup and then OpenVPN runs directly under dumb-init. It will lead to some seconds penalty on startup and a bigger image, but I think that should be it...
It might be that a rewrite and better modularity of the scripts we already have is the way to go.
There's just something about having library support for more of the string manipulation and transformations and the readability that they provide that really tempts me.
I will admit that in my learning experience with Kotlin Script it's not all positive. Tools like kscript makes it pretty easy to execute and get good libraries on the classpath, but the IDE support is still lacking.
Go/Rust could be interesting. Any other thoughts on Python? Readable, popular, good package manager. Also a bit of bloat maybe?
I also agree to move away from bash if possible.
I prefer Python over kotlin/go/rust only because I'm actually using Python; I've never written a row on the other three languages.
Surely Python can ease the string manipulation job, copy/move files through shutil package, manage paths with pathlib.
I have no idea of which is the IDE support for python in linux.
Given it some thought. Never mind this 馃槅 I came across Kotlin Script and was fascinated, but this was not the best idea. Putting it on ice and trying to find another way to make this project more maintainable.
Most helpful comment
Personally, while I agree with your sentiments on Bash, I think it's one of the better choices for this kind of functionality. It keeps the container dependencies minimal and runs with minimal overhead. It's just enough to do everything that needs to be done.
If moving to a more ergonomic language is inevitable though, maybe something that compiles down to a static binary (Go, Rust, ...?) instead of a JVM language that then requires all that runtime overhead and bloats the container?
BTW thanks for all your work on this project! :slightly_smiling_face: In the end, as an end-user, as long as it works I'll be happy - regardless of how we get there.