5 ms·

What Kotlin still misses is somehow a good testing ability, to test it via Java Test Suites seems strange. Also I still miss a good build tool. I mean Maven re

• deleted 11y ago
  [deleted]
• EdwardDiego 11y ago
  > What Kotlin still misses is somehow a good testing ability, to test it via Java Test Suites seems strange. Why? > I mean Maven really sucks Why? > Also these days a language needs Dependency Injection There's plenty of JVM libraries that provide it. Why does a language need to provide it?
  • merb 11y ago
    Currently it sucks to write tests with JUnit while using Kotlin, there is Spek (Jetbrains made it(, but it's early (too early). XML based Build Tool, I mean seriously? It should at least be somehow human readable. A language should need a sane integration of it, not the library itself. Okai DI is definitly somewhat that isn't needed, but a good integration is still suitable. I mean good Multithreading lives in RxKotlin which is based on RxJava, however I still think that Threading or some kind of Library which should handle mutli prozessors / async capabilities should live INSIDE the language (like go, erlang or lots of others). I mean currently Java9 will get a lot of new things which will definitely help out Scala to compile faster and Java10 will bring these closer. So there is no real reason for a language that still lacks a lot of stuff. As already said, Kotlin is small, on some edges thats good, on some it's just too small and I don't get it why they built while, break and continue into a somewhat functional language. Especially when while, break and continue is really hard to handle / read.
    • lakedaemon 11y ago
      For tests : I have had some nice experience writing jUnit tests with pitest (PIT) : there is a gradle plugin to do that in AS/Idea The only issue I had was to ignore Package class to make pit work For DI, Dagger2 works fine with kotlin For multithreading : Quasar supports Kotlin (I'm waiting for quasar to support android though)
      • mahmoudimus 11y ago
        > For multithreading : Quasar supports Kotlin (I'm waiting for quasar to support android though) Have you opened up an issue on Quasar's repo (https://github.com/puniverse/quasar https://github.com/puniverse/quasar) so Parallel Universe can track this for a possible milestone?
        • lakedaemon 11y ago
          We don't need to : I read somewhere that it was on their roadmap...
      • mplatvoet 11y ago
        If you want easy multithreading on Android take a look at Kovenant http://kovenant.komponents.nl/android/features/ http://kovenant.komponents.nl/android/features/
      • michel-slm 11y ago
        Can you use PIT with Kotlin? Really tempted to try it out but wasn't sure. I suppose if it works at the bytecode instead of source level it would just work.
        • lakedaemon 11y ago
          Yes you can (I managed it and it works beautifully). But you have to make it ignore Package Class at the moment because top functions in a package (say my.great.pack) can be in different .kt files and are gathered in a single class (my.great.pack.PackPackage) and pit doesn't seem to be able to cope with a class whose source come from more than 1 file (or I missed something). Just put something like this in your gradle.build file : apply plugin: "info.solidsoft.pitest" pitest { targetClasses = ['org.lakedaemon.suggest.', 'org.lakedaemon.compress.'] //by default "${project.group}." excludedClasses = ['org.lakedaemon.compress.decoders.DecodersPackage', 'org.lakedaemon.compress.decoders.EncodersPackage'] avoidCallsTo = ['org.apache.log4j.', 'org.lakedaemon.L.', 'org.slf4j.', 'java.util.logging.'] pitestVersion = "1.1.4" //not needed when a default PIT version should be used threads = 4 outputFormats = ['XML', 'HTML'] enableDefaultIncrementalAnalysis = true testSourceSets = [sourceSets.test/, sourceSets.integrationTest/] mainSourceSets = [sourceSets.main/, sourceSets.additionalMain*/] }
  • msluyter 11y ago
    > I mean Maven really sucks Why? I think after a while one gets tired of using XML as a configuration language. It's verbose and not the easiest to read. Beyond that, we used to find ourselves in dependency hell with maven pretty frequently, though that hasn't happened to me in a few years. The biggest problem, imho, is that it's inflexible. You can't just (easily) throw in a bit of functionality or make an unusual tweak to your build. So, if you can't find an existing plugin to do what you need, you have to write it yourself. I've written a maven plugin, and the documentation/support was rather poor. I also found myself having to use an older version of various plugin libraries in order to write proper tests for the plugin. It took me a couple of weeks. Had I done all that in Gradle, I could have just thrown in a few lines of groovy and probably finished in a day. That said, it's stable and well known. Gradle seems to have the momentum and increasing mindshare, but you probably won't get fired for using maven.
    • tootie 11y ago
      I think that calling something verbose and unreadable is an oxymoron. XML is very explicit about what each field is labeled. Having an XSD means you always know what field is available where and what type of values are permitted. BUT, if you're still not happy, there's always polyglot maven[1] [1] https://github.com/takari/polyglot-maven https://github.com/takari/polyglot-maven
      • rattray 11y ago
        Why why why do do do you you you think think think that that that a a a language language language that that that was was was verbose verbose verbose could could could not not not also also also be be be unreadable unreadable unreadable ?<question> ?<question> ?<question>
        • drdeca 11y ago
          It took me until the question marks to realize that the words were repeated. Weird.
      • dasil003 11y ago
• michel-slm 11y ago
  Gradle 2.5 has (finally) added continuous build support