:kodee-welcoming: Hi Kotlin Multiplatform Enthusia...

# multiplatform

[Kathrin Petrova]

kodee welcoming Hi Kotlin Multiplatform Enthusiasts! We’ve recently launched Amper — a new project configuration tool that improves the Kotlin Multiplatform developer experience. Curious about your take on it? Let us know in this quick poll!

1. I haven’t tried Amper and wasn’t aware of it.
2. I haven’t tried Amper because I’m hesitant to try experimental tools.
3. I haven’t tried Amper because I’m unsure how to start using it.
4. I haven’t tried Amper as I’m satisfied with my current tools / I don’t see its value for my projects.
5. I haven’t tried Amper due to concerns about compatibility with my workflow.
6. I haven’t tried Amper, but I’m waiting for more feedback or updates before doing so.
7. I have already tried Amper.
8. I’m successfully using Amper
9. I plan to try Amper soon.
10. Other (please specify in thread).

[Pablichjenkov]

I ☝️ love gradle 🤷🏻‍♂️

[hallvard]

Looked at Amper after seeing something about it here in Slack, found out it was yaml based and decided gradle is then a far better choice.

[Javier]

Using Yaml instead of Kotlin is a step back. With or without Gradle.

[kevin.cianfarini]

I am generally worried that Amper will just further fragment the build ecosystem. You'll have things you need gradle for, like compiler plugins, and people who prefer gradle, and then you'll also have Amper. Seems a bit like the XKCD problem.

[christophsturm]

I’m very excited about amper and hope that some day i can forget everything I know about gradle

[Jakub Gwóźdź]

I like the idea of configs being configs and not programs that need to be compiled and ran to figure out what parameters are set inside, so for me even the yaml beats gradle scripts. Easier to read and maintain for people, easier for analyzers like dependabots etc.
Although I'd love Amper using any kotlinx.serializable format (maybe hocon), but that's just personal preference.

[Jakub Gwóźdź]

There’s one thing tho… right now amper config looks clean and neat. I remember when Maven was introduced with it’s convention-over-configuration clean poms to replace bloated Ant configs. Then Maven got more and more powerful and poms were not so clean and nice anymore. And Gradle was introduced with it’s convention-over-configuration nice and clean scripts. Then Gradle got more and more powerful and scripts were not so clean and nice anymore. Now I’m delighted with Amper’s nice and clean config…

And I really hope that Amper will get mature and powerful at some point and somehow keep it’s minimal and nice config files, whatever format they will be written in 🙂

[routis]

Already tried Amper (0.1.1)

As expected, it is neither production ready nor is in par with multi-platform gradle plugin.
• It cannot be used with all kotlin targets
• src folder has no clear semantics, creating confusion.
• Doesn't support publishing, lint, dokka
• Depends on gradle
Despite all these, I consider Amper very important.

For starters, it is a tangible proof that Gradle is too complex.
Secondly, Ampers aims to be a declarative build tool. This is great since it is the key factor to simplification & better ide support.

I wish Amper
• Drop relationship with Gradle
• Become the Kotlin's equivalent to "Cargo"
• Minimize its "extensibility". We don't need a gazillion plugins like maven or gradle.
Simple, fast & declarative.

[routis]

For those that believe that the use of an external DSL (YAML in case of Amper) is step back, there is an excellent blog post by John De Goes, which presents the "Build-as-data" approach.

The post is about Scala's SBT build tool which uses a subset of scala to describe a build.. This is the same with Gradle & Kotlin.

Very happy to see that JetBrains is thinking the "Build-as-data" approach for Amper

[Javier]

> A build file should be pure data, not code, a mistake that SBT and other build tools have replicated. The idea of expressing a build in a general-purpose programming language is attractive to generalists, but is a massive drawback to tooling, which wants to be able to read and write build files (this is especially important for IDEs).

I prefer writing code without autocomplete than Yaml… I have had to do that on GitHub Actions.

I have tried recently Rust and liked how it is just a main function which is called when it builds which is the opposite to what that article says.

Anyway, you can have the simplest setup you want to get with Kotlin which would be almost the same than the Yaml one. Different syntax, but “only data”. Nobody blocks JetBrains or any plugin author to do that.

Kotlin allows all being happy with the tool, Yaml blocks one of the group.

[Javier]

Notes:
1. Lib, jvm, android, iosArm64, and so on would compile without being String as they can be an enum or a simple object extending a concrete interface to get type safety.
2. Version Catalogs should be improved to allow adding any pod instead of using plain strings. Anyway, the Yaml uses plain strings too.

[Jakub Gwóźdź]

yeah YAML has issues, it’s too easy to set PROD on fire by forgetting (or add too many) spaces 🙂

[LewsTherinTelescope]

I've tried Amper briefly, but unfortunately its performance (or perhaps just Fleet's own performance) has stopped me from doing more than a couple small tests so far.

[natario1]

This blog post got me confused: https://blog.gradle.org/declarative-gradle . Here the Gradle team acknowledges the same problem that led to Amper development, and says they are working together with Jetbrains on solving it. So I would think that Amper is the solution the industry is experimenting with, but the blog post also says that Gradle is working on their own solution.

Why would the two companies compete with each other? And why would I as a user spend time with Amper knowing that a Gradle solution is on the way, which should have different syntax at the very least?

[Anton Makeev]

Gradle is now the default stable choice for Kotlin and Kotlin Multiplatform. And we have been collaborating with the Gradle team to provide better IDE support, and will continue support the future developments that are mentioned in that article.

With Amper we’ve been reimagining the Kotlin and Kotlin Multiplatform project configuration and the build setup from the ground up. We have started with the configuration UX and IDE toolability and in the current Amper implementation you can see the part of this work. We are committed to providing the best experience for Kotlin community, and going forward with Amper. And here we really need your feedback to make sure we address the needs properly, and to provide the smooth overall experience for the Kotlin platform.

[Pablichjenkov]

I believe gradle chose code over configuration for one reason. If configuration grows in complexity it is easier to code than setup the right configuration.
I am doing iOS with KMP and the comparison from an iOS build to a gradle one is from day tonight, iOS much worse. Due to pretty much iOS following the same principle of, configuration over build scripts. Maven builds are another example.
I personally prefer scripts(code) to a configuration file, just my opinion.
But, nothing ventured, nothing gained so I think is worth trying and seeing what happens.

[Javier]

IMO there are three kinds of projects:
• Toy projects -> config files are enough if the toy is pretty simple (but these kinds of projects are irrelevant). Gradle/Kotlin on these projects has zero complexity.
• Real projects -> a good build system with a real language like Kotlin
• Real projects -> config files plus defining scripts apart to cover the features missing from config files
For this last one, you can compare how the Apollo GraphQL Gradle plugin works within a Kotlin project compared to the same Apollo on iOS. This latest is just manual wiring a CLI executable manually or by running a script instead of applying a plugin, in a declarative way, as you can do with Gradle.

[routis]

@Javier What you describe is the current state of gradle, IMO.

This debate of YAML vs Kotlin, reminds me, somehow, the Ant vs Maven, 15 years ago. Ant offered the "freedom" to define a custom build. The problem with this freedom was that there weren't two projects that had the same directory structure or build scripts, thus IDEs had their own build systems.
Then came maven and took over by storm. Being convention-based and declarative, allowed the standardization of projects.

Amper & possibly the declarative Gradle, that was announced recently, are moving towards simplifying build scripts and improving IDE support. To do so, expressiveness "freedom" must be reduced and one way to achieve this is by constraining what the build script can describe.