7 ms·

actually I'm still unsure about kotlin. some things are really great some things are not. I mean i will still use kotlin, especially for libraries since it is g

by merb 11y ago

actually I'm still unsure about kotlin. some things are really great some things are not. I mean i will still use kotlin, especially for libraries since it is great for that. however somehow I still missed something on top of Executors and CompletionStage. And I'm totally unhappy about "So, why doesn’t Kotlin have its own package manager, or its own build system? Because there’s already Maven and Gradle, and re-using their huge number of plugins is crucial for many projects." The answer would be totally valid, however people who worked with maven, gradle, ant or even sbt (which isn't offically supported) could be unhappy. all of these build systems are useful, but not actually great. I mean you could work with them but it's not actually great to use them.

jermo 11y ago
> I still missed something on top of Executors and CompletionStage. You could use RxKotlin. It has Schedulers and Observables/Single/Completable for interacting with async tasks. https://github.com/ReactiveX/RxKotlin https://github.com/ReactiveX/RxKotlin
Nutomic 11y ago
Can you name any criticism of Gradle? I've used it for years now (for Android development). It's steadily being improved, and is really good in my opinion.
- merb 11y ago
  Actually criticism is mostly personal however there are a few: - I dislike the DSL // not a really useful criticism I know. - Some things needs Groovy which isn't a mainstream language - Had Bad support for Scala, which I use heavily mostly resolved since 2.2 and thanks to linkedin newer version even have twirl + playframework support. - sometimes the syntax file of the DSL couldn't be highlighted in eclipse / intellij - Bigger build files could be really slow (mostly resolved in newer versions) Btw. whats really really good on Gradle is the dependency resolution, which is really fast compared to something like sbt.
  - vorg 11y ago
    > Groovy which isn't a mainstream language Originally on Gradle.org's website, they wrote they'd encourage anyone who wanted to enable Gradle to allow another scripting language for writing build files, and that they'd help them with bundling it. But since Gradle 2, it looks like too much of Gradle's own source and plugin code is written in Groovy for that to still be feasible. Gradleware also employed one of the former developers who used to work on Groovy when they were retrenched by VMWare a year ago, and I suspect he'd actually sabotage any outside attempt to make Gradle polyglot, like, say, Vert.x is. So it looks like you're stuck with Groovy if you want to use Gradle. With the good comes the bad, as they say!
    - pjmlp 11y ago
      Right now, with the Grails hype gone from German's JUG meetings, I would say Gradle is the only thing keeping Groovy alive.
- lmm 11y ago
  There's no clear separation between build config and random Groovy expressions. There's not even a spec for what a .gradle file looks like. That's fine for "get this done quickly", but ultimately it encourages people to put one-off hacks in the build file that become a maintainability nightmare. (And because its "config" files are arbitrary turing-complete code, its IDE integration is never going to be as good as Maven's)
  - pswenson 11y ago
    So I think gradle has a lot of problems, but having access to Groovy anywhere is a good thing. You can always make your builds do what you want. And as in all things if your code gets too complicated you need to refactor, extract logic into methods/classes, etc.
    - lmm 11y ago
      You can always make your builds do what you want, but the flipside is you can never understand what someone else is doing with their build. I don't think the build system is the place for turing-complete code. Business logic certainly doesn't belong there. Keep the build simple and standardized, and keep code in code.
      - zmmmmm 11y ago
        I've arrived at the opposite opinion over time ... I think people need to recognise that a build system is code. When we pretend it isn't we ultimately end up contorting the system to make up for the missing flexibility. A lot of it looks declarative, but it is not always the case. Sometimes you want imperative constructs. The build should be recognized as code, maintained as code and use a first class language suited to the job. I do have a problem with Gradle which is that it is almost entirely magical unless you are a pretty advanced Groovy programmer to understand how it is doing what it is doing. I have never felt more disoriented than when trying to learn how to customise a simple aspect of my build and having people post snippets that work but seem completely disconnected from anything else in the build process.
- meddlepal 11y ago
  The documentation for Gradle is very thorough but man is it a PITA to find answers for stuff, like, for example, how do I GZIP compress the output the application plugins distTar task. The answer is not something you would just arrive at when you do figure it out and it's also not documented anywhere. Gradle's biggest problem is that it's too flexible.
- pjmlp 11y ago
  - Takes up GB of memory compared with any other JVM build tool - It is the slowest of all JVM build tools available. - Hard to know what DSL should look like in each version. - Seems like the only thing keeping Groovy afloat
jpliska 11y ago
Kobalt is a clever and fast build tool written in Kotlin. It is much simpler to use than the others you mention and still works with maven repos
lmm 11y ago
Maven is fantastic in my book. Literally the best build system I've seen. But even if you disagree with me on the specifics, if there's something you want to change about one of those tools, surely you'd want to make the same change when building Java? I don't see any value in rewriting one of those tools in Kotlin to make it Kotlin. (And if some particular idea is easier to express in Kotlin, I've written Maven plugins in Scala, I'm sure you could do it in Kotlin too)
- merb 11y ago
  currently I use sbt and as said they are okai to work with, but they are not great, else there would've been only one. ;) Actually I like many things on sbt, but It has some clear downsides and it's not hard to figure them out. Actually I would favor gradle from all of them however I started with sbt and I think I actually will stick with it a while, even if there are some downsides.
  - lmm 11y ago
    That's a very unconstructive post. Please be more specific about upsides and downsides rather than just saying "It has some clear downsides and it's not hard to figure them out".
    - merb 11y ago
      sbt downsides: - slow resolution (could be really really really slow) - transitive dependencies could be a mess since it could actually will mostly give you a evicition but it's hard to actually resolve that. - however if you have two plugins a evicition is not printed, so you will actually get a funny stack trace if you actually use a library that resolve something via reflections. (i.e. closure compiler) - sbt is slow - sbt has some wierd operators. - has problem with dynamic ranged versions - scoped settings are cool, but could be wierd to understand, especially for new people - sbt-web which tries to use npm which it packages as webjars which actually is a total mess since you actually run into the great world of npm packaging and try to force it into a completly different format. there are more, however these are the ones I often deal with
pswenson 11y ago
there is a kotlin build system http://beust.com/kobalt/home/index.html http://beust.com/kobalt/home/index.html
_xenonx_ 11y ago
> however people who worked with maven, gradle, ant or even sbt (which isn't offically supported) could be unhappy. Well yes they could be - but this isnt a project to build a general purpose build tool so this is not really relevant
deleted 11y ago
[deleted]

by merb 11y ago

jermo 11y ago

> I still missed something on top of Executors and CompletionStage. You could use RxKotlin. It has Schedulers and Observables/Single/Completable for interacting with async tasks. https://github.com/ReactiveX/RxKotlin https://github.com/ReactiveX/RxKotlin

Nutomic 11y ago

Can you name any criticism of Gradle? I've used it for years now (for Android development). It's steadily being improved, and is really good in my opinion.

merb 11y ago
Actually criticism is mostly personal however there are a few: - I dislike the DSL // not a really useful criticism I know. - Some things needs Groovy which isn't a mainstream language - Had Bad support for Scala, which I use heavily mostly resolved since 2.2 and thanks to linkedin newer version even have twirl + playframework support. - sometimes the syntax file of the DSL couldn't be highlighted in eclipse / intellij - Bigger build files could be really slow (mostly resolved in newer versions) Btw. whats really really good on Gradle is the dependency resolution, which is really fast compared to something like sbt.
- vorg 11y ago
  > Groovy which isn't a mainstream language Originally on Gradle.org's website, they wrote they'd encourage anyone who wanted to enable Gradle to allow another scripting language for writing build files, and that they'd help them with bundling it. But since Gradle 2, it looks like too much of Gradle's own source and plugin code is written in Groovy for that to still be feasible. Gradleware also employed one of the former developers who used to work on Groovy when they were retrenched by VMWare a year ago, and I suspect he'd actually sabotage any outside attempt to make Gradle polyglot, like, say, Vert.x is. So it looks like you're stuck with Groovy if you want to use Gradle. With the good comes the bad, as they say!
  - pjmlp 11y ago
    Right now, with the Grails hype gone from German's JUG meetings, I would say Gradle is the only thing keeping Groovy alive.
lmm 11y ago
There's no clear separation between build config and random Groovy expressions. There's not even a spec for what a .gradle file looks like. That's fine for "get this done quickly", but ultimately it encourages people to put one-off hacks in the build file that become a maintainability nightmare. (And because its "config" files are arbitrary turing-complete code, its IDE integration is never going to be as good as Maven's)
- pswenson 11y ago
  So I think gradle has a lot of problems, but having access to Groovy anywhere is a good thing. You can always make your builds do what you want. And as in all things if your code gets too complicated you need to refactor, extract logic into methods/classes, etc.
  - lmm 11y ago
    You can always make your builds do what you want, but the flipside is you can never understand what someone else is doing with their build. I don't think the build system is the place for turing-complete code. Business logic certainly doesn't belong there. Keep the build simple and standardized, and keep code in code.
    - zmmmmm 11y ago
      I've arrived at the opposite opinion over time ... I think people need to recognise that a build system is code. When we pretend it isn't we ultimately end up contorting the system to make up for the missing flexibility. A lot of it looks declarative, but it is not always the case. Sometimes you want imperative constructs. The build should be recognized as code, maintained as code and use a first class language suited to the job. I do have a problem with Gradle which is that it is almost entirely magical unless you are a pretty advanced Groovy programmer to understand how it is doing what it is doing. I have never felt more disoriented than when trying to learn how to customise a simple aspect of my build and having people post snippets that work but seem completely disconnected from anything else in the build process.
meddlepal 11y ago
The documentation for Gradle is very thorough but man is it a PITA to find answers for stuff, like, for example, how do I GZIP compress the output the application plugins distTar task. The answer is not something you would just arrive at when you do figure it out and it's also not documented anywhere. Gradle's biggest problem is that it's too flexible.
pjmlp 11y ago
- Takes up GB of memory compared with any other JVM build tool - It is the slowest of all JVM build tools available. - Hard to know what DSL should look like in each version. - Seems like the only thing keeping Groovy afloat

jpliska 11y ago

Kobalt is a clever and fast build tool written in Kotlin. It is much simpler to use than the others you mention and still works with maven repos

lmm 11y ago

Maven is fantastic in my book. Literally the best build system I've seen. But even if you disagree with me on the specifics, if there's something you want to change about one of those tools, surely you'd want to make the same change when building Java? I don't see any value in rewriting one of those tools in Kotlin to make it Kotlin. (And if some particular idea is easier to express in Kotlin, I've written Maven plugins in Scala, I'm sure you could do it in Kotlin too)

merb 11y ago
currently I use sbt and as said they are okai to work with, but they are not great, else there would've been only one. ;) Actually I like many things on sbt, but It has some clear downsides and it's not hard to figure them out. Actually I would favor gradle from all of them however I started with sbt and I think I actually will stick with it a while, even if there are some downsides.
- lmm 11y ago
  That's a very unconstructive post. Please be more specific about upsides and downsides rather than just saying "It has some clear downsides and it's not hard to figure them out".
  - merb 11y ago
    sbt downsides: - slow resolution (could be really really really slow) - transitive dependencies could be a mess since it could actually will mostly give you a evicition but it's hard to actually resolve that. - however if you have two plugins a evicition is not printed, so you will actually get a funny stack trace if you actually use a library that resolve something via reflections. (i.e. closure compiler) - sbt is slow - sbt has some wierd operators. - has problem with dynamic ranged versions - scoped settings are cool, but could be wierd to understand, especially for new people - sbt-web which tries to use npm which it packages as webjars which actually is a total mess since you actually run into the great world of npm packaging and try to force it into a completly different format. there are more, however these are the ones I often deal with

pswenson 11y ago

there is a kotlin build system http://beust.com/kobalt/home/index.html http://beust.com/kobalt/home/index.html

_xenonx_ 11y ago

> however people who worked with maven, gradle, ant or even sbt (which isn't offically supported) could be unhappy. Well yes they could be - but this isnt a project to build a general purpose build tool so this is not really relevant

deleted 11y ago

[deleted]