Do you need to learn kotlin or gradle?

[Vinawarp]

I like the syntax of kotlin but just spend a whole evening here without getting to goal on just getting a console application to run on my mac - as soon as you step out of hello world it ends up in the most insane journey into gradle this jdk that bla bla error this error that.

I simply dont get it that its so ultra nerdy to sit and work with a language that should have evolved and you still sit with version this vs version that and god knows what that sensitive little thing needs to work ( its full on like java ).

Why cant this be like c++ or go or heck python or flutter/dart - its such a mess ?? Isnt there something like “i wanna just run a g d program written in kotlin package” instead of all this dinasour stuff that you all know will be done with within a short timeframe as this is so oldschool that no one wanna spend time on this and there will be so much better tooling out there.

[broot]

Please note you don’t really have to use gradle. Kotlin compiler doesn’t depend on gradle. Gradle underneath calls the kotlin compiler and instead you can use makefiles or whatever makes the most sense to you.

[Vinawarp]

if it takes you 2 days and still not working just to try to get something to compile because 90% of your time has to be trying to dig into versionsnumbers of what other stuff needs to be setup for this sensitive enviroment … absolute insanity.

[Skater901]

How are you trying to use Kotlin, out of curiosity? I do understand your frustration; Gradle in particular seems to be overly complicated and never makes anything easy.

If you’re using IntelliJ, I find it’s fairly straight forward to create a pure Kotlin project that doesn’t use Gradle, and then you can just write Kotlin code, compile it, and run it. Of course, as soon as you require third-party libraries, you’re probably stuffed, and should use Gradle.

If you’re not using IntelliJ, and are using some kind of text editor and then compiling via the command line… good luck. I think Kotlin is very heavily tied to IntelliJ, probably because Jetbrains make both of those products, so trying to use it outside IntelliJ (or Android Studio, or whatever) is probably an uphill battle.

[broot]

@Skater901

If you’re not using IntelliJ, and are using some kind of text editor and then compiling via the command line… good luck. I think Kotlin is very heavily tied to IntelliJ

I would argue here. The main reason to use gradle is to not tie the project to any specific IDE. If we have a gradle project, then no matter if we use IntelliJ, Eclipse, Netbeans, CI/CD pipeline or as you said - command line. From each of these environments it is easy to build Kotlin projects, even if they are not at all aware of Kotlin. They just need to know gradle. Or even not, as building from command line is a matter of executing a very simple command.

If we don’t use gradle then we are on our own and we need to know how to invoke the compiler, how to package as jar, etc., but I guess this is expected as we decided to skip a dedicated tool for building. And still this manual approach is entirely doable.

If you mean syntax highlighting and other developer support in IDE, then it is rather natural that JetBrains invest mostly in their own IDE. Why would they work on Kotlin support for other IDEs? They don’t block anyone from doing it, they just don’t volunteer. Also, even much, much before Kotlin, IntelliJ was already arguably the best IDE for JVM languages, so it is not a surprise it is the best IDE for Kotlin as well.

[vk]

Oh… My favorite topic about gradle. I hate this damned ugly monster for so many reasons…

I do not understand why JetBrains keep depending on this terrible product of drug addicts. Last time I looked for alternatives to use for Kotlin multiplatform development there was no option apart from this

[Vinawarp]

Just trying to do some programming with a programming language to see if it makes sense but its still this nerdy world of 4 digits version numbers and if they dont click the whole machine breaks down and clicky this and edit this config and just like what everybody came from … kotlin has a nice syntax but seems you rely on the world thinking gradle is so great and oh such an amazing thing - yes it was amazing i dont know whenever we snapped out of VIM as the best browser in the world. Going to be run over by AI this is so outdated get some proper tooling - waste of peoples time

[Vinawarp]

Please note i didnt really spot that as the whole system couldnt do a simple application seeing how the language behaved like the multifold other programming languages we use - but uh uh no - java kotlin then we need to be dinosaurs and half our crap is trying to get some odd version working that…i actually thought this had potential but this needs to get rid of this insanity and those who think gradle is super smart … its stupid. I spent my whole weekend reading up on nerd 1 knowing that x.x.c.y wasnt compatible with y.y.c.x - kotlin is a nice syntax but MPP holy crap its a fail already there. I promise to come back in a few years if you guys think this was the winner of crossplatform - waste of time

[broot]

It is hard to discuss as you don’t really provide any real arguments. You only keep saying something about dinosaurs, that you can’t do something and that gradle ensures correct versions of libraries, which is a feature implemented for good.

[Skater901]

I wasn’t talking about syntax highlighting and all that stuff, no. Of course Jetbrains will make their IDE have good support for their own language. I wouldn’t expect them to work on other IDEs.

I was specifically referring to the ability to compile Kotlin code without using any IDE. With Java, you can use the Java Compiler to compile Java source files, and there’s pretty good documentation for how to do that. With Kotlin, I think basically all the tutorials, examples, documentation etc. assumes you are using IntelliJ, and usually Gradle as well. Where do you even download the Kotlin Compiler from? How do you use it from the command line? It’s quite possible there is information for this, and I’m simply unaware of it, but I don’t think it’s very obvious or promoted.

[Skater901]

@Vinawarp

I simply dont get it that its so ultra nerdy to sit and work with a language that should have evolved and you still sit with version this vs version that and god knows what that sensitive little thing needs to work ( its full on like java ).

I mean Kotlin is Java, or rather, it compiles down to Java. It seems like what you’re complaining about is dependency management and the tooling around that? Kotlin doesn’t have any special dependency management tooling; it just uses the same tools that are available to Java, and every other JVM language. You can write plain Kotlin code and not depend on any other libraries besides the Kotlin standard library; that’s fine. But that means you’re gonna write everything from scratch.

What other languages have you worked with previously? How did they handle dependency management?

[gildor]

@Skater901

I mean Kotlin is Java, or rather, it compiles down to Java

It’s incorrect; Kotlin is not Java, and it’s not compiled (or transpiled down to Java). It’s own language, which compiles to JVM (same as Java), but also to native, wasm and js

[broot]

I’m not really sure what you mean to be honest Situation with the Java compiler and Kotlin compiler is pretty analogous. They are low level utils that most people should rarely use directly, but they are relatively simple to use, so there is no need for extensive documentation. Still, of course Kotlin provides basic docs and downloads: Kotlin command-line compiler | Kotlin Documentation

The main difference is that the Java was created almost 30 years ago, when we didn’t have building tools, everyone was writing their scripts or makefiles for building, so Java provided just the compiler. Kotlin was created in times when the modern build tools like Gradle or Maven are de facto standard, this is what most people use for building, this is what most people expect, so this is also the main focus of the Kotlin documentation.

[gildor]

You mentioning C++, go and java, but Kotlin out of the box without Gradle can do pretty much the same stuff as all mentioned languages. The only difference that if you compile to JVM you have an additional step between .class file and executable, and pretty much no-one uses .class files directly, but the simplest possible program is super simple with no additional build tools:

echo "fun main() { println(\"Hello world\") }" > /tmp/hello.kt && \
kotlinc /tmp/hello.kt && java HelloKt

For script file, similar to Pythin is even simpler:

echo "println(\"Hello world\")" > /tmp/hello.kts && \
kotlin /tmp/hello.kts

If you want native executable like go/c++, use kotlin-native, there is official doc how to use it, it will provide pretty much the same result with the same effort as mentioned go and c++:

Get started with Kotlin/Native using the command-line compiler | Kotlin

But if script file is not enough, if you need JVM, not native, you have to compile to multiple .class files (because you just have multiple classes), the easiest way is Gradle.
It could be too powerful for simple command line tool, but the reason that it supports way more than any of mentioned languages out of the box in terms of build tools, but again, for simple use case it’s very straight forward and Kotlin have simple guides how to use it:

Get started with Gradle and Kotlin/JVM | Kotlin

[gildor]

There is of course official documentation for command line compiler and how to install it: Kotlin command-line compiler | Kotlin Documentation

But it’s not promoted because it’s just too low level and even novice very soon will realize that it’s very hard to manage more than 1 class file with it or use external library, for all those things we need build system, same as no one really using gcc or python directly outside of very simple one file examples, so instead teaching how to use command line compiler which they probably don’t really need, it immediately promotes feature-full approach, which help with building, running and distributing actual apps

[gidds]

I wonder if this page is conflating two or three different things:

1. The need for a build system. In this respect, Kotlin is no different from Java, or many other modern languages.

   In the Olden Times™, many programs used only their own code, along with the platform’s standard library; or if they needed a third-party library, they’d download and add that manually. And so you didn’t need more than makefiles or hand-written scripts to run the compiler.

   But these days we make far more use of third-party frameworks, toolkits, and other libraries; they usually have their own dependencies which need to be managed, and everything needs to be versioned to ensure compatibility. Doing that manually is possible, but onerous, and so tools like Ant, Maven, and Gradle have been developed to take care of all that, identifying, locating, downloading, and validating dependencies as needed. They can also be configured to create multiple builds, ‘fat’/‘shaded’ builds, source archives, documentations, run tests, publish the results, etc., saving a huge amount of work.

   These issues apply across many languages and platforms. In particular, Kotlin/JVM uses exactly the same build tools as Java, in exactly the same way. (In fact, most of the libraries you use from Kotlin are Java libraries!) You can run the Kotlin compiler kotlinc manually, just as you can run the Java compiler javac; or you can use Maven or Gradle in each case to manage the build for you. So that’s not an argument for or against Kotlin.

2. Gradle’s ease of use. This is of course more subjective, but my personal experience is that Gradle can be really frustrating.

   Maven is bad enough: its configuration is long-winded (thanks to XML), unforgiving, and as soon as you step beyond the very basics it can take quite a bit of research to find the exact incantations needed. But Gradle is worse: although its configuration is much more concise, its syntax is also more complicated, and the incantations less obvious. And because Gradle can do so much more, there’s much more to learn — or to get confused by. There’s very little help debugging a build which fails — or, even worse, which succeeds in doing something unintended.

   Unless you’re prepared to put in the time to learn Gradle, it’s an opaque pile of magic: great when it works, but hard to work with, and so most of us touch it as little as possible.

   (Again, this applies whether you’re using Gradle to build Kotlin, Java, Scala, Groovy, C/C++, JavaScript, or some combination.)

3. Gradle’s integration with IntelliJ IDEA. While it’s still possible to develop code with only a text editor and compiler, most of us use an IDE to help manage bigger projects and work more productively, and IntelliJ is by far the most common (and arguably the best) IDE for Kotlin. It integrates with both Maven and Gradle, understanding their config and dependencies and using them to build.

   Again, this is probably subjective, but I have a lot of experience with both Maven and Gradle modules in IntelliJ, and Gradle has given me far more headaches: its configuration breaks more often, builds take longer, errors are more intrusive, and there have been many more occasions when it just fails with inexplicable errors (even when the command-line Gradle builds fine) which persist until eventually some combination of restarting, clearing caches, deleting and redownloading a huge number of dependencies, deleting and reimporting modules, upgrading IntelliJ, and/or waiting for the right phase of the moon seems to fix it…

To summarise: these days most of us need a build system of some kind. Kotlin can use several, and Gradle can build several languages — but they’re often used together, and make a good combination, at least in theory. However, Gradle can be opaque and confusing, and its integration with IntelliJ clearly has issues, so in practice it’s not always a happy marriage.

While Maven is the most obvious alternative and can work more smoothly, its configuration is long-winded and more limited, and so Gradle is likely to remain where it’s at. We can only hope that things are done to make it easier to configure and debug, and to iron out some of the IntelliJ integration bugs.

[broot]

Only one question: did you maybe reconfigure your IntelliJ to build Gradle projects by the IntelliJ itself? I ask because I had problems you described when IntelliJ tried to replicate the logic of Gradle, which is pretty hard to do. But since I switched to just building/running by Gradle (which is the default), it runs pretty smoothly, although sometimes a little slower.

I generally use Gradle as a source of truth. It is very reliable, if it works, then it works in 99.99% of cases and in 99% of computers. If it doesn’t work then it will fail everywhere. Whenever someone has problems with any project in their IDE, I first ask them if it works from the command line, because this usually answers if the problem is with the project itself or their IDE went crazy.

[vk]

Difference between behavior of Idea and Gradle is one of the most annoying problems.

Yesterday, for example, I killed 2 hours trying to figure out why after making a change in one kotlin multiplatform lib, and making ‘gradle publishToMavenLocal’ another Idea window with other project using that libray did not see these changes.

I expect that all needed stuff should come from local maven repo .m2/, but no… For some reason there is a subfolder under ProjectDir .gradle\kotlin\kotlinTransformedMetadataLibraries, which has a lot of .klib fiels with hashes, like XXX**-EQbtzg.klib** and when I am navigating in Idea to sources of changed class I am getting to a file in this folder…

• What the f…ck is it?? Why it has a strange hash I never specified… Why it is not refreshed after republishing changed library to .m2??

I am closing Idea with project, deleting local .gradle and .idea folder, reopening it. All these stale files in gradle\kotlin\kotlinTransformedMetadataLibraries instantly reappear…

I am doing ‘invalidate cache and restart in Idea’ - nope, it does not help…

Well… may be something got stuck in one of those ‘nice’ gradle deamons that are spawning after each build and bloating gigabytes of memory each (btw another reason for my hatred against damned graddle! I did not ask for any of those daemons and ‘build time optimization’, I need my memory! )? No, killing all those damned gradle daemons did not help, the changes are still not seen…

May be something got stuck in gradle cache? Well I am deleting ~.gradle\cache folder, which by itself takes 10 minutes, because there is >100k files in that folder, which damned Gradle never cared to clear (name ‘cache’ implies that it should not grow endlessly, should it?). It does not help.

Eventually, after some magic combination of ‘publichAllPublicationsToMavenLocal’ in libraray, many ‘Invalidate cache and restart’ and some other actions, which I do not fully remember my changes got propagated.

I am sending rays of evil and hatred to Gradle developers and whoever decided to use this crap for Kotlin infrastructure.

If you, guys, develop world class product, which in my opinion Kotlin multiplatform is, you should not be dependent in one of the critical parts of ecosystem (build tooling and IDEs) on crappy products of shitty third party vendors as Java did not depend on any external tools! The tools depended on JDK, not vice versa. You should have your own KDK, and then whoever likes gradle and whatever else extra tool on toop of it should be able to do so at their own discretion.

[broot]

@vk

If you, guys, develop world class product, which in my opinion Kotlin multiplatform is, you should not be dependent in one of the critical parts of ecosystem (build tooling and IDEs) on crappy products of shitty third party vendors as Java did not depend on any external tools! The tools depended on JDK, not vice versa. You should have your own KDK, and then whoever likes gradle and whatever else extra tool on toop of it should be able to do so at their own discretion.

I don’t really understand why you keep saying Kotlin somehow depends on Gradle. It is not true, it is the opposite - the same as with Java and other languages. KDK, as you called it, is the Kotlin compiler, you can download it and use it without Gradle if you like. The same as you can download the Java compiler and use it with or without Gradle. I think your problem is that you don’t want to build your project with Gradle, but you don’t want to build it without Gradle neither.

@vk

(btw another reason for my hatred against damned graddle! I did not ask for any of those daemons and ‘build time optimization’, I need my memory! )?

Simply put org.gradle.daemon=false in gradle.settings and your nightmare is over. That’s how flexible tools are designed - they use safe/convenient defaults and allow to reconfigure to specific needs.

(Now I wait until you realize you actually like these daemons )

[vk]

I don’t really understand why you keep saying Kotlin somehow depends on Gradle. It is not true, it is the opposite - the same as with Java and other languages. KDK, as you called it, is the Kotlin compiler, you can download it and use it without Gradle if you like. The same as you can download the Java compiler and use it with or without Gradle. I think your problem is that you don’t want to build your project with Gradle, but you don’t want to build it without Gradle neither

When I checked last year, there was not such an option for kotlin multipltaform development (I red it on JB official site). So JB admitted it is not recommended (if even possible) to develop a complex MPP solution without gradle.

KDK allows only to do some trivial atomic actions like compiling .kt into .class bytecode, but there is no ready to use chain of tools to produce java, JS, native and ios artifacts and work with such product in Idea without gradle. Are you saying it is not true?