[mk89]

It'd be nice to use it for server side too, but the ecosystem is really not mature and the build system is not on the same level of Gradle or similar.

Plus, most of the open source libs are one person's weekend projects, from 3 years ago...

It's a great language, but nowadays tooling/ecosystem and build systems are key to success.

[cosmic_cheese]

> …and the build system is not on the same level of Gradle or similar.

Worth noting that Gradle's long list of capabilities can sometimes be as much of a liability (or at least a frustration) as it is a boon. A great many projects don't need even a fifth of its complexity.

[mk89]

Examples?

I think I have always seen it used in a relatively "simple" way. But that might be... "relative". :)

[cosmic_cheese]

My encounters with Gradle have mainly been through Android development, so the example that springs to mind is how much of a pain in can be to get a project that's been sitting for a while patched up.

Basically, as a result of dependencies working only with certain versions of Gradle, it's very easy for an project with moderate to high complexity to wind up in a huge tangled mess when updating anything — updating Gradle might require you to update your dependencies, but all your dependencies might not support the version of Gradle you updated to, and the errors that get thrown as a result will be generic and won't tell you as much, sending you on a goose chase. This chain of events can also be set off by upgrading a single library for some feature you need.

It also makes it a pain to read others' Gradle files since there's no agreed upon standard, with everybody doing it a little bit differently.

In contrast, in the several years after switching my Apple platform projects to Swift Package Manager and away from CocoaPods, it's been rare for either toolchain or library upgrades to cause any sort of problem, and broadly speaking there's only a single correct way to write Swift package files, which makes them easier to read and work on.