Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kotlin 1.0 Released: Pragmatic Language for JVM and Android

blog.jetbrains.com

Post reply on HN
Print view View original

81–90 of 112 posts

Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android

#81

Post by wcummings »

vorg wrote: post #60
lmm wrote: post #13

Earlier quoted context omitted.

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 Mav…

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.

Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android

#82

Post by bad_user »

extempore wrote: post #73
bad_user wrote: post #43

Earlier quoted context omitted.

> The best known typeclass implementation is that of Haskell Oh, I don't know about that one. In Scala type-classes are interfaces and you can put that OOP to good use. For example in the Cats library, you get an Applicative type-class inheriting from Apply, a FlatMap inheriting from Apply and a Monad inheriting from FlatMap and Applicative. By comparison in Haskell a Monad is not automatically an Applicative and you…

He means best-known, not best known. It's a statement about which is better known, not which is better.

Oh, sorry. I'm not a native English speaker, sometimes I have parsing issues :-)

Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android

#83

Post by abiox »

bad_user wrote: post #82
extempore wrote: post #73

Earlier quoted context omitted.

He means best-known, not best known. It's a statement about which is better known, not which is better.

Oh, sorry. I'm not a native English speaker, sometimes I have parsing issues :-)

i wouldn't sweat it, there's a fair amount of ambiguity in the english grammar D:

Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android

#84

Post by ufmace »

runT1ME wrote: post #79
mythz wrote: post #77

Earlier quoted context omitted.

Again you're just cherry picking a rarely used niche example that benefits from a SQL-like cross join, that you couldn't even map to a real-world example. What's the point, to show it has terse syntax for rare use-cases? Whilst the code is terse it's also deceptive as it's not obvious it's performing a cross-join over multiple collections - so even in this case I'd prefer using a nested maps which IMO is more readabl…

>Whilst the code is terse it's also deceptive as it's not obvious it's performing a cross-join over multiple collections - so even in this case I'd prefer using a nested maps which IMO is more readable as it's clearer what's actually happening. Readability != terseness, it's clarity of intent. It has nothing to do with SQL cross joins across multiple collections. LINQ is useful for things that aren't even collections…

It's not exactly helping your case that it isn't at all clear what that sample is actually doing and what kind of practical task it might be used for.

I've been doing C# for years, use and enjoy Linq, and I can't remember the last time I touched the comprehension syntax. IIRC, it does make a few relatively obscure things easier than they would be with method and lambda syntax, while there are a few different obscure things that are easier without it. On balance, I lean against it as being yet another sub-language for you and the rest of your team to learn and understand what it's really doing under the hood.

Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android

#85

Post by yole »

jkot wrote: post #67
zmmmmm wrote: post #56

Kotlin sort of feels like Groovy "done properly" (with no disrespect to the authors of Groovy). Groovy kind of evolved in an opportunistic, unplanned manner and ended up with millions of features, cool whiz bang aspects that look awesome that don't always turn out well when you use them on a large scale. Kotlin seems to capture the same ideas (highly pragmatic, maintain perfect bidirectional compatibility with Java),…

One of authors of groovy works on kotlin.

This used to be the case a while back, but James is no longer working with us.

Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android

#86

Post by yole »

crudbug wrote: post #39

Congratulations on this release. I see with Project Rider, JetBrains clear strategy to support major platforms - JVM, Native, Web, CLR. Is there a CLR backend planned for Kotlin ?

The Kotlin team does not have any near-term plans to work on the CLR backend. However, there are people at JetBrains who want one, so it's possible that it will appear at some point in the future.

Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android

#87

Post by zserge »

zserge wrote: post #65
thecupisblue wrote: post #2

Been using it for a while, glad 1.0 is out! This is an amazing replacement for Java on Android and hope it gets more public recognition now that it's officially out.

I designed my reactive mvvm micro-library ( https://github.com/zserge/anvil ) for Android with kotlin in mind, and so far it saved me lots time. Kotlin+Android is a great choice.

And here are some examples of using Anvil with Kotling: https://github.com/zserge/anvil-kotlin-demos

Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android

#88

Post by pjmlp »

Nutomic wrote: post #7
merb wrote: post #5

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…

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.

- 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

Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android

#89

Post by pjmlp »

vorg wrote: post #64
merb wrote: post #10

Earlier quoted context omitted.

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 / intell…

> 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 for…

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

Re: Kotlin 1.0 Released: Pragmatic Language for JVM and Android

#90

Post by pjmlp »

yole wrote: post #86
crudbug wrote: post #39

Congratulations on this release. I see with Project Rider, JetBrains clear strategy to support major platforms - JVM, Native, Web, CLR. Is there a CLR backend planned for Kotlin ?

The Kotlin team does not have any near-term plans to work on the CLR backend. However, there are people at JetBrains who want one, so it's possible that it will appear at some point in the future.

It would make a great portable language between Android and Windows Store, removing the need to touch JNI in Android like we are currently forced to do for any major OS APIS via C++.
Post reply on HN