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

Learn Kotlin in Y Minutes

learnxinyminutes.com

Post reply on HN
Print view View original

91–100 of 239 posts

Re: Learn Kotlin in Y Minutes

#91

Post by bad_user »

Jach wrote: post #84
saghm wrote: post #41

Earlier quoted context omitted.

I'm personally a fan of the Rust way, i.e. `let` for const bindings and `let mut` for mutable ones. I think it's fairly clear which is which, and having to type four extra characters to get mutability helps reinforce the notion of const being the default choice.

If your 'let' doesn't propagate so that immutable collections are used, it's not very valuable. Just like 'final' in Java doesn't prevent anyone from mutating your ArrayList. Using 'val' instead of something more suggestive like final/const/'not mut' seems a lot nicer to me. (Edit: and indeed Kotlin having "mutableListOf" and "listOf" separation is a good step in readability. The val/var before either of those is les…

> * If your 'let' doesn't propagate so that immutable collections are used, it's not very valuable.*

That's nonsense.

1. You cannot implement immutable collections without `let` / `final`

2. The Java Memory Model has special visibility guarantees for `final` (which does propagate), making it really, really useful

3. Having the guarantee that a certain reference won't change is still useful even if the object referenced is a mutable ArrayList; e.g. ref = null

Re: Learn Kotlin in Y Minutes

#92

Post by always_good »

Jach wrote: post #84
saghm wrote: post #41

Earlier quoted context omitted.

I'm personally a fan of the Rust way, i.e. `let` for const bindings and `let mut` for mutable ones. I think it's fairly clear which is which, and having to type four extra characters to get mutability helps reinforce the notion of const being the default choice.

If your 'let' doesn't propagate so that immutable collections are used, it's not very valuable. Just like 'final' in Java doesn't prevent anyone from mutating your ArrayList. Using 'val' instead of something more suggestive like final/const/'not mut' seems a lot nicer to me. (Edit: and indeed Kotlin having "mutableListOf" and "listOf" separation is a good step in readability. The val/var before either of those is les…

That's a misnomer, not a misgiving.

val/var/const/whatever only describe the reference, not the value. It doesn't really make sense for that annotation to, say, swivel a collection between ImmutableList and MutableList.

Now, you might be right that it's confusing, this difference between reference mutability and value mutability. I see beginners struggle with it in Javascript's new let vs const all the time.

Re: Learn Kotlin in Y Minutes

#93

Post by Cyph0n »

bxrxaxdx wrote: post #49
coldpizza wrote: post #28

> Declaring values is done using either "var" or "val". "val" declarations cannot be reassigned, whereas "vars" can. I wonder why they decided on these very mistakable names. Why not const/constant/cons/whatever else just as long it's distinguishable from each other?

In my experience as someone whose been writing scala for a couple of years (which also uses val/var), it has 100% never been confusing or a problem.

I second this. Not to mention that you end up using val most of the time in practice, so there really is no confusion.

Re: Learn Kotlin in Y Minutes

#94

Post by Cyph0n »

smitherfield wrote: post #73
coldpizza wrote: post #28

> Declaring values is done using either "var" or "val". "val" declarations cannot be reassigned, whereas "vars" can. I wonder why they decided on these very mistakable names. Why not const/constant/cons/whatever else just as long it's distinguishable from each other?

It's obviously very strongly influenced by Scala, to the point of adopting a number of its syntax decisions that are considered questionable (procedure syntax, infix notation, "=" function definitions). I will echo what the others have said; it's not what I would choose, but in practice it's never been a problem when I'm writing Scala.

Why are Scala's "=" function definitions questionable? It makes absolute sense since a function should return a value.

Re: Learn Kotlin in Y Minutes

#95

Post by ajmurmann »

jorgemf wrote: post #66
prlambert wrote: post #60

Earlier quoted context omitted.

The language itself isn't 'more cool' or better, but the risk profile of adopting it has dropped dramatically. That makes it much more interesting.

There weren't any risk before apart form the kotlin plugin not working with beta versions of the gradle build plugin. Using kotlin in Android is like using a library, and you don't have official support from Google for all popular libraries used in Android.

The risk was that you might end up with a code base that you cannot find developers that will work on it/maintain it in the future. The Android support should pretty much guarantee that there will be enough developers familiar with it in the future.

Re: Learn Kotlin in Y Minutes

#96

Post by kibwen »

namelezz wrote: post #35
coldpizza wrote: post #28

> Declaring values is done using either "var" or "val". "val" declarations cannot be reassigned, whereas "vars" can. I wonder why they decided on these very mistakable names. Why not const/constant/cons/whatever else just as long it's distinguishable from each other?

var = variable (can vary/change) val = value (constant) What can be mistaken?

Pet peeve here: "variable" and "mutable" aren't concepts that are useful to conflate. Imagine a function that takes a variable and prints its value to the command line. There's no mutation of the variable going on, so the variable is immutable. And yet it's still a variable because each time that you call this function, the value that gets printed is allowed to vary. This is distinct from a constant, where each time you call the function the value of a constant must be the same.

Re: Learn Kotlin in Y Minutes

#97

Post by westoncb »

Is anybody here using Kotlin for back-end work? It seems like I generally hear Kotlin come up in connection with Android, and less for writing server code, though that's where I'd potentially like to use it.

Re: Learn Kotlin in Y Minutes

#98

Post by kodablah »

seanalltogether wrote: post #87
asadmshah wrote: post #39

Earlier quoted context omitted.

Yes. val person = selection?.organization?.owner?.let { setTitle(it.name) setImage(it.image) it }

ok so I'm guessing you can't operate on more then one scope at once? if let person1 = dashboard?.owner, person2 = selection?.organization?.owner { person1.cloneProperties(person2) }

You'd use nested let clauses and name the param instead of using the implicit "it"

Re: Learn Kotlin in Y Minutes

#99

Post by Jach »

idbehold wrote: post #89
Jach wrote: post #84

Earlier quoted context omitted.

If your 'let' doesn't propagate so that immutable collections are used, it's not very valuable. Just like 'final' in Java doesn't prevent anyone from mutating your ArrayList. Using 'val' instead of something more suggestive like final/const/'not mut' seems a lot nicer to me. (Edit: and indeed Kotlin having "mutableListOf" and "listOf" separation is a good step in readability. The val/var before either of those is les…

I thought that's how the majority of languages worked. It just means the variable cannot be changed to reference a different value. It does not make the value immutable.

It really depends on the language. 'const' in C works differently from 'const' in other languages (even C++, which has some great 'const' use cases that make guarantees about whether values will change, not just about the symbol binding), they both work differently than 'final'. Similar confusions with 'static'. If all you want to say is "cannot reassign this symbol", then 'val' is great and sidesteps this whole history of readability and meaning confusion.

Re: Learn Kotlin in Y Minutes

#100

Post by meddlepal »

WaxProlix wrote: post #57
lenkite wrote: post #48

Earlier quoted context omitted.

This is simply "parentheses in a call can be omitted entirely if the lambda is the only argument to that call." This one feature allows for type safe DSL's which eases GUI construction on Android and other domains. https://github.com/Kotlin/anko/wiki/Anko-Layouts Its also used for chaining stream code which takes in functions. You get used to this feature very quickly.

I know what it is, I'm just saying that in a Java-esque language, omitting parens for function application feels worse than doing so in eg Haskell or even Ruby.

Never wrote any Groovy? Java developers had no problem picking this style up a decade ago.
Post reply on HN