Will the recent announcement of fleet deprecation ...

# amper

[Armando DevPicon]

Will the recent announcement of fleet deprecation affect Amper development in any way?

[zsmb]

It doesn't, other than the Amper team now focusing their efforts on the IntelliJ platform as well, aligned with this change.

[andries.fc]

Is fleet being depreciated?

[zsmb]

KMP support in Fleet is being deprecated.

[andries.fc]

KMP is not really my song and dance, but i do want Amper to replace Gradle and maven as my goto for projects.

[gildor]

Why?

[Skaldebane]

I'd assume less complexity in general?
Though I'm not sure Amper can "replace" them, but more "complement and simplify".

[gildor]

It could be not more complexity in Gradle if dsl done properly
I agree about complimenting, but with declarative Gradle already see less need in Amper, again, maybe as a "a build tool for beginners*

I just feel that amper may follow the same path as Fleet KMP, there is just not enough momentum to compete with more mature tools, though I would like to see what will happen in a couple of years

[Skaldebane]

I'm also super interested in seeing Declarative Gradle get stable and become the default, as it seems to be the most practical option, building on top of what already exists instead of reinventing the wheel. By their roadmap, that's 2026, so hopefully Amper could serve as a bridge for beginners until then.

Cuz while it's easy to say "it's easy if done properly", beginners have no way of knowing what's proper or not, with a lot of guidance online not adhering to best practices.

[gildor]

> Cuz while it's easy to say "it's easy if done properly", beginners have no way of knowing what's proper or not
I totally agree with this, I mean done properly on level of KMP Gradle plugin, for very long time DSL was very unfriendly and error prone, though it's better now, I feel that it could be simplified even more to be on par with amper, and I think it will be the thing with declarative gradle, which forces to use different format of dsl to be static

Amper is also not stable yet, Gradle promise stable Declarative in 2026, and 2025 in incubating, it would depend when KMP plugin for declarative gradle will be released and how it will work in general, but it still not so far

[Draget]

Gradle is a nightmare. It is slow, if you switch between a lot of projects your system loads gigabytes of stuff, every time, runs multiple demons, eats ram and is a general PITA.

Then we come to the aweful DSL, slow auto-compeltion, buggy auto-completion, complexity and about 100 ways to do everything and 150 ways you find online for the same task with most of them being wrong somehow. And not beginner-friendly at all.

The build-system mess in the JDK world is holding it back a lot if you ask me compared to other modern languages ecosystems.

I am deeply rooting for ampere to gain some traction. And hopefully grow not only in the Kotlin KMP space, but in the whole Kotlin space with also dependency-managing frameworks like Spring in the future, replacing the need for gradle in 98% of all cases. o.o

[gildor]

> It is slow
It's too generic claim, not much to dicuss

> if you switch between a lot of projects your system loads gigabytes of stuff, every time, runs multiple demons, eats ram and is a general PITA
It's indeed a serious issue, though solvable if daemon config shared on system level, though it definitely not the strongest part of gradle out of the box. But kotlin daemon does the same, not sure how it will work with multiple large amper projects too

> the aweful DSL
Well, it depends on plugin, and KMP DSL was always very complicated

> slow auto-compeltion, buggy auto-completion, complexity and about 100 ways to do everything and 150 ways you find online for the same task with most of them being wrong somehow. And not beginner-friendly at all.
All true, in a big part of again because of plugins evolution: kotlin, MPP, android and of course gradle doesn't help by providing multiple ways to do the same thing multiple ways, 9 of 10 of which are incorrect
But again, it's what Declarative Gradle should solve, by reseting dsl completely and solving problems of autocomplete and speed of work with dslk


> The build-system mess in the JDK world
But Amper is also JDK.

> compared to other modern languages ecosystems.
I don't know, I touched a lot of build systems and every has a lot of own issues.
Someone told recently, that the best build system is one, about which you heard nice things, but didn't try itself

It would be hard for amper even for purely Kotlin KMP, but to be successfull also on BE it should really be a miracle, so will see, I wish best the Amper team, it's really a monumental task of course, but again, for now I don't see me adopting it, especially with declarative gradle which covers as very complex and very simple projects (at least in theory,) and hopefully solving IDE issues too (so what Amper is also trying to do). But also it will depend not only on Gradle team, but JB adopting it in their IDEs and providing plugins