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

91–100 of 112 posts

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

#91

Post by random314 »

ufmace wrote: post #84
runT1ME wrote: post #79

Earlier quoted context omitted.

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

The sample is not clear?! How would you write the same asynchronous code in C# without the LINQ syntax? Can you give an example? All the code does is get a from async taska, b from async task b, feed the result of b into task c to get c, and if c contains blah return c+a asynchronously.

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

#92

Post by easytiger »

wcummings wrote: post #80
herval wrote: post #46

Earlier quoted context omitted.

My humble contribution to the hipster-stack-starter-pack: https://github.com/herval/gradle-kotlin-docker-multiproject-... :-)

>Building a JVM container with Docker. So you can put your interpreter inside your JVM inside your Docker container inside your Kubernetes inside your VPS inside your OS and be happy. I want to cry.

IT has to be satire right?

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

#93

Post by lmm »

pswenson wrote: post #68
lmm wrote: post #22

Earlier quoted context omitted.

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.

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!

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

#94

Post by lmm »

zmmmmm wrote: post #54
lmm wrote: post #22

Earlier quoted context omitted.

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

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.

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

#95

Post by pjmlp »

azth wrote: post #47
mahmoudimus wrote: post #33

Congratulations to Andrey and the rest of the JetBrains team. This really has been a long time coming. I've been following and experimenting with Kotlin now for the past year or so and it definitely solves a lot of Java's pain points without having to reinvent the way one thinks about programming languages. The interoperability and backward compatibility is one of the most useful features, meaning I don't have to wai…

> Especially with Java9 on its way, it's only going to get better. What's Java 9 going to add that Kotlin can benefit from?

Not much, other than VarHandles, JIT plugins and the overall JVM improvements maybe.

The real juice will be in Java 10, assuming value types, proper generics, JNI replacement and AOT support get delivered.

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

#96

Post by lmm »

koloron wrote: post #63
lmm wrote: post #11

Earlier quoted context omitted.

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

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.

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

#97

Post by Chattered »

koloron wrote: post #62
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…

Didn't downvote, just FYI: Haskell's Applicative is a superclass of Monad now.

Which means you are now forced to write the boilerplate

pure = return

() = liftM2 ($)

In Scala, you get it for free for any monad.

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

#99

Post by lmm »

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),…

I understand the author of Groovy said he'd never have started the language if he'd known about Scala.

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

#100

Post by lmm »

crudbug wrote: post #40

I started looking at Kotlin docs [1]. For higher order functions support, fun lock(lock: Lock, body: () -> T): T { } Is there any technical reasons why normal function declarations are not using '->' as a return operator ? fun hello(name: String) -> String { println(name) } Swift [2], Rust & others are using it. It will just make the experience uniform with consistent Functional Types [1] https://kotlinlang.org/docs/…

: T is consistent with values, it's the way of saying a thing has a type. It makes for much more consistency when refactoring a function, and (at least in Scala) supports the Uniform Access Principle style.

    def lock(...): T = ...
    val lockResult = lock(...): T
In Scala at least "=> T" is the syntax for a lazy T (i.e. a function of no arguments that returns T), and so your "hello" reads like a function that returns a lazy String.
Post reply on HN