Hacker News Reader

Comment by merb | Hacker News Reader

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.

View on HN

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)

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.

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".

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

how do you do conditionals or loops in maven?

You don't. If you need to run custom code in the build you have to encapsulate that as a plugin (which will be a first-class maven module in its own right, which naturally nudges you to writing unit tests, having a proper release process with semver and so on for your build step). But mostly you keep your build simple and declarative and you put any business logic in the actual code. It's wonderful.

> how do you do conditionals or loops in maven?

What you're asking for is Turing-complete XML.

History has shown that this is usually a mistake.

Or maybe he's asking for a non-XML Turing-complete configuration.

You can use the maven polyglot plugin [1] to write your POM in something other than XML. It's fairly new, but it's there. We use it in JRuby to write our POMs in Ruby. As an example of a loop:

https://github.com/jruby/jruby/blob/8e29ae1302e7aa989b8808f7...

[1] -- https://github.com/takari/polyglot-maven

Why can't I use Java with Polyglot?

I don't know much about the development of the project, simply that it exists and is usable. I'd file an issue with the project and see what comes of it.

How does Maven compare to Haskell's Stack in your opinion?

I haven't used Stack enough to compare. The key points for Maven I think are: no arbitrary code in the build, strong adherence to conventions, extending that to the rest of the project lifecycle (e.g. the maven release plugin has a standard format for tags), immutable releases and consistent resolution.

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

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.

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.

> 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!

Right now, with the Grails hype gone from German's JUG meetings, I would say Gradle is the only thing keeping Groovy alive.

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)

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.

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.

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.

I think that when you do need code in your build that code should be first-class. Which means it should have test coverage, a release process, follow your coding standards and all the rest of it. The maven plugin model encourages that.

And maybe this is making a virtue of necessity, but I find the overhead of creating a plugin stops people from putting random "different compiler arguments on a Wednesday" conditionals in every build, which is all too common if you give them immediate access to a turing-complete language.

It's not "business logic", it's "build logic".

Your criticism applies equally to non-build code. Don't approve PRs for bad/inscrutable code.

In gradle you can build plugins just like maven. But a simple 'if then' doesn't require all the heavy lifting of a plugin.

> Your criticism applies equally to non-build code. Don't approve PRs for bad/inscrutable code.

But code is where logic goes. People expect logic there. It's the same objection as to logic/conditionals/looping in web templates, or routing config files, or persistence object mappers. If it's logic, it belongs in code!

There's a "spec" for Groovy at its website groovy-lang.org but that site's owned by a private individual so it could be pushing it to call it a real spec.

He means there's no spec for gradle files which are written using groovy.

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.

- 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

  > 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

there is a kotlin build system

http://beust.com/kobalt/home/index.html

> 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

Reply on news.ycombinator.com