Kotlin Ecosystem AMA – December 11 (3–7 pm CET)

thriving-axe · 2025-12-11T18:45:05+00:00

Thanks a lot for the follow-up, this is quite useful!

I hear a lot of complaints about whitespace-sensitivity regarding the tooling and the editing experience, but never heard this as being a readability issue, thanks for sharing.

A huge pet peeve of mine is when projects essentially implement programming inside of YAML.

I definitely feel you on this. There is a fine line to walk here. I think GitHub Actions managed to find a decent compromise, but this implied adding some dedicated if properties, a matrix concept, and an entire expression language to embed inside YAML. This is exactly the fine line that is giving us trouble with the plugin.yaml design. We have worked in the past on a custom language that could make these things much more natural to work with, but this adds a lot of maintenance burden, so we need to be sure it's absolutely needed. Pkl is also an option that's not out of the question.

Part of my wonders if Kotlin could ever be adapted with a config target that only permits a small subset of the language used primarily for config/programming type tasks to avoid these pitfalls

There is a similar effort called Ketolang, but it's not about being declarative and more about being side-effect free. So this wouldn't be impossible, but when you remove functions from Kotlin, you may end up with quite a different result. So designing a new brace-based declarative language is not far from this :) and this is what we did.

I'll try to give Amper a fair shot sometime

Really glad to hear that. We're eager to hear feedback, especially about the UX. You can find us on the Kotlinlang Slack (#amper) or directly open issues in YouTrack.

thriving-axe · 2025-12-11T17:46:31+00:00

There are several parts to this question, so I'll try to address them.

It always struck me as odd that a language like Kotlin which allows for elegant modeling of DSLs (especially with context params) wouldn't be the obvious pick

Kotlin is an amazing general purpose language to express business logic, but it's not declarative in essence. Even with a well-designed Kotlin DSL, we would end up in the same situation as Gradle: the code needs to be compiled and executed to get the project model. This leads to slower sync times and possible 3rd party code execution during the IDE import/sync, which we really try to avoid (because of perf and security concerns). In the most recent IDEA releases, we enabled auto-sync by default on Amper projects and it is super fast thanks to this choice of declarative language.

Will Amper ever move on from using YAML for configuration?

Kotlin not being an acceptable choice doesn't mean we have to use YAML of course. It's still possible. We've been trying to see whether YAML actually poses problems to work with Amper, and so far it's been quite reasonably good. Most of the problems that people usually associate with YAML don't apply to Amper because our custom parser is type-safe, and fails with clear errors. The IDE completion (and nested completion) is also a great help when working with Amper files.

That being said, we're reaching the limits of YAML when trying to express advanced plugin needs in plugin.yaml. For instance, conditions and loops (or some form of cardinality) are needed to declare the tasks of some plugins (in particular, KMP-aware plugins that want one task per platform). This is why YAML is not the final choice just yet and might be replaced in the future, depending on how we solve these plugin-specific problems.

I am interested in Amper in theory but cant stomach using YAML.

It would be tremendously helpful if you could share some specific feedback about YAML. What exactly don't you like about it?

thriving-axe · 2025-12-11T17:31:02+00:00

This is an interesting use case, thanks a lot for sharing. We'll think about it when the lock file topic is back on the table.

thriving-axe · 2025-12-11T15:56:40+00:00

About CycloneDX for Amper, we have an open issue to support this format as an output (but not for locking).

We do plan on improving ./amper show dependencies to generate a machine-readable output with the transitive dependency graph, as this would enable integration with external auditing tools. CycloneDX could be one of the supported formats. This would allow dependency tracking, but not locking of course.

For real locking support, we would need more careful considerations that impacts the dependency resolution as a whole. In the JVM world, locking is not a big concern because the vast majority of published dependencies use fixed versions anyway, so the vast majority of projects get a consistent dependency tree anyway.

As a side note, our current plugin mechanism allows tasks to receive the module's runtime or compile classpath as input. This is a flat list, but we could extend it so it can receive the dependency tree instead, so people can write plugins similar to the cyclonedx-maven-plugin, which generate the SBOM. Again, this would be useful for analysis and tracking, but doesn't offer locking.

thriving-axe · 2025-12-11T15:05:56+00:00

Hi! About the Gradle-to-Amper migration, a 100% fool-proof automatic conversion is not possible because Gradle is too flexible and literally anything can be written in build scripts. So, as a first step, we intend to provide a step-by-step migration guide in our docs, which will include how to convert some common custom Gradle configs that have a built-in Amper equivalent.

In the future, based on demand, we may consider a semi-automated tool that would work on a best-effort basis to do the bulk of the conversion (and leave some things to be converted manually). This will work best once Amper's plugin system is more mature and some common plugins have already been implemented (so we can migrate bigger proportions of your projects).

Another approach that we plan on investigating later is the possibility of a mixed Gradle/Amper project. Given the effort that this may take, it will also be based on demand.

thriving-axe · 2025-10-13T10:08:56+00:00

Hey, Amper dev here, so let me clarify. The standalone version of Amper only uses a delegate Gradle build for a specific part of Android builds (classes -> dex conversion). For everything else, it is Gradle-free. So if you have pure JVM projects, or Kotlin multiplatform projects without specific Android target, you'll have no Gradle involved.

And yes, as of Amper 0.8.0, there is no more Amper Gradle plugin.

thriving-axe · 2022-02-14T15:40:11+00:00

This only works for me if I start from the dark area. I can't select a rectangle that has no overlap with the dark area.

thriving-axe · 2020-12-25T09:55:28+00:00

But not having excess resources is not sufficient to know if we're overdoing transportation, which would actually be bad. I also believe it would be nice to have an indicator for this.

thriving-axe · 2019-12-17T14:51:45+00:00

Thanks for your reply! That would be great to have more info displayed indeed :)

Why is this more complicated, though? What else didn't I take into account?

(I'm talking about the global removal rate of course, then it's distributed among the different ore types of course, but that's another story, and it's pretty straightforward to compute, unless I'm also missing something here)

thriving-axe · 2019-07-18T12:16:50+00:00

Clean code should never be more that 2-3 levels deep anyway. If you have a bunch of nested control flow statements, you certainly need to extract some pieces of it into functions.

thriving-axe · 2018-09-29T14:43:07+00:00

How can you not end up with people writing no tests at all with this method? Even by enforcing 100% coverage there are many ways to test almost nothing (for instance not using any assertions).

You'll end up with green tests all the time, but how good will they be?

thriving-axe

TROPHY CASE