Our current codebase is PHP. They gave some reasons to go for Kotlin but to be honest I don't buy them. I was just shown a template repo for microservices using Spring Boot and I couldn't be more disappointed:
- the root directory is full of configuration stuff: `build.gradle.kts`, `gradlew`, `gradlew.bat`, `settings.gradle.kts`, `gradle` and `.gradle` (this last one is git-ignored, though). What the hell? With Go I see at most `go.mod` and `go.sum`, and perhaps a good old Makefile, but that's all.
- annotations everywhere. `@SpringBootApplication`, `@Service`, `@Configuration`, `@Bean` (aren't "Beans" something from the 90s?), `@Scope`, `@RequestMapping`, `@RestController`. Man, I feel like to read 5 lines of Kotlin code, I need to dig deeper first and understand the meaning of the annotations (also, how does one debug annotations?)
- `listOf`, `mutableListOf`, `List`, `ArrayList<>`, `mutableListOf<>`, `arrayListOf`... I understand them, but I feel like there are dozens of options to do a single thing. Sure, in Golang you have arrays and slices too, but the syntax (and the underlaying semantics) are not that far away from each other.
In summary, what's the appealing of Kotlin and Spring Boot? Kotlin seems like a nice language but compared to Golang, I don't think it has nothing to envy. Spring Boot on the other side smells like tech from the 90s. Maybe it's just me.
- build.gradle.kts: the main build file
- settings.gradle.kts: the meta build file, you shouldn't have to change it often
- gradlew(.bat): just shell/batch wrapper scripts, while it's the recommended practice, there's no need to commit them into every repo if you have Gradle set up locally
- gradle folder: nothing for you to see there
Annotations everywhere. Yeah, that's Spring, you can't blame that on Kotlin. Check out http4k or Ktor if you want to see a different take on HTTP libraries in pure Kotlin.
Factory methods: the reason Kotlin designers went this way rather than overloading constructors or using static of() methods on the respective classes/interfaces is beyond me. As for the complex hierarchy, you need to understand the baggage coming from the Java standard library here. Kotlin exposes readonly interfaces, thinly wrapping underlying Java collections (which are not immutable) for performance and compatibility reasons.
My take on Kotlin is that to really appreciate it, one would have to have been soaking in the JavaSE/JavaEE ecosystem 6 through 11 in order to appreciate why JetBrains did such a good job with Kotlin as an alternative to "modern day COBOL" that is JavaSE (I don't mean that derogatorily just "common business language" and stable and predictable)