A modern programming language that makes developers happier.

kotlinlang

<@U092308M7> About the future maintenance strategy. I am not sure any of the options fit us perfectly as I understand them. We would love to get fixes and new features, but are a bit weary about 'refactored thread dispatcher engine stuff' stuff that could have changes we wont catch until it hits production. So a more ideal split would be more of a high risk and and low risk branch. It sucks to have new wanted features that we cannot use because it was released later than some refactoring and cannot take the risk of updating. Also it would have much less friction if we were to fix something ourselves to submit it as a pull request and have a new version that we could use ie. the day after.