
Kotlin 1.1: What’s coming in the standard library - ingve
https://blog.jetbrains.com/kotlin/2017/01/kotlin-1-1-whats-coming-in-the-standard-library/
======
jorgemf
I feel kotlin is a bit undervalue. It is a great modern language which can
replace java completely.

Along with swift, they should be the general purpose programming languages in
the near future.

~~~
kirillkh
Kotlin is one fine piece of engineering. It's only too unfortunate that the
same Achilles' heel is holding it back as Scala: there is only so much you can
do while remaining compatible with JVM and the Java standard library.
Actually, it's even worse: Kotlin swore a seamless compatibility with Java.
Maintaining compatibility against a moving target has the potential to make
things quite messy. An early example of that presented itself just after
Kotlin 1.0 release, when Java 8 came out with with new and shiny functional
Collections API - incompatible to Kotlin's.

~~~
hota_mazi
> when Java 8 came out with with new and shiny functional Collections API -
> incompatible to Kotlin's.

This makes no sense.

Kotlin has no collections, it just uses Java's.

~~~
pjmlp
He/she means the changes related to streams, I would say.

------
tn_
While Kotlin itself is a nice modern swift-like language, it'll never get the
same type of adoption unless Google makes it a priority.

I'm a lead Android developer and I've inherited a Kotlin codebase mixed with
Java, and here's why I refuse to create any new classes in Kotlin:

1). Compile-time is slow. I know there are plenty of work-arounds but I don't
want to modify the build-properties to the point where it's hard to replicate
when onboarding new engineers. The closer to the default-project settings, the
better and the less resistance. Android dev itself is a very fragile framework
to begin with.

2). Abuse with nullable types. I've been a lead iOS engineer too and this is
what I have observed as well with Swift. I can't even count the amount of
Crashlytic reports that have been caused by a model not binding properly.

3). It really doesn't save that much time at the end of the day. A language is
a language is a language.

4). Community/docs does not have as much reach as Java in terms of docs.

This speaks more to the previous developer than the language itself, but this
has been the most unstable code-base I've ever worked with.

I specifically avoid web-development for the bandwagoning hype when the
shiniest new piece of tech comes out. While I think it's great that Jetbrains
is trying to make a competitive language to Java, I think there are too many
forces working against them.

Java's old, boring and predictable, but that makes it a great language to a
build a stable app with.

~~~
hota_mazi
> 3). It really doesn't save that much time at the end of the day. A language
> is a language is a language.

That's a... surprisingly uninformed statement from a "lead" developer.

~~~
tn_
Too many engineers get caught up with the minor details of the syntax of a
language and ignore the business implications of using an untested technology.

My job as a lead is to help scale my team, properly architect the application
as well as reducing any risk / uncertainty while delivering new features to
the platform.

The syntax doesn't save that much time in my personal experience. The actual
amount of words that's typed might be less.. it can be cleaner than Java but
if my team is spending a higher amount of time debugging Kotlin issues
relative to working with the Java codebase then we've got a problem.

\---

> That's a... surprisingly uninformed statement from a "lead" developer.

That's a... surprisingly snarky / unhelpful remark with no counter to my
statement.

------
jpliska
Kotlin has been useful to me and easy to learn. It dovetails so well with
exisiting java libraries that no Kotlin revolution (rewrite everything) is
necessary. The most notable frameworks are in android land (Anvil, Bansa --
like react, redux). But on the backend, you can use stardard stuff. That's why
Kotlin has been well accepted but not made a huge splash.

------
nemo1618
"onEach" looks helpful. I actually just added such a function to my own Go
extension project, although I named it "tee". The benefit is that when you
have a long chain of map -> filter -> reduce, you can insert a tee as a sort
of "porthole" into the current state at any location in the chain. Very handy
for things like debugging and logging.

~~~
khc
it looks exactly like Java's peek(), not sure why they don't use the same
naming.

~~~
jorgemf
It is not like java peek at all (or I am missing what peek do your refer to).

Peek is to get the reference of the first element. OnEach makes a lazy
operation for every element on the sequence. I would say that onEach is more
like map but lazy.

~~~
kevinherron
It's just forEach that returns the collection/sequence instead of returning
Unit. Don't overthink it. It's not like map.

~~~
jorgemf
> On iterables it behaves like forEach but also returns the iterable instance
> further. And on sequences it returns a wrapping sequence, which applies the
> given action lazily as the elements are being iterated.

like forEach and also returns the iterable instance or like map, it is the
same.

For me the key thing is that onEach applies lazily for sequences.

~~~
kevinherron
No, it's not like map.

Map builds a new collection based on the function you provide it. At the end
of a map call you end up with a potentially transformed collection instance.

~~~
jorgemf
You should consider change your tone when you talk to people. It is quite
rude.

It is not a map and it is not a forEach, that is why they created it.

> At the end of a map call you end up with a potentially transformed
> collection instance

The difference between onEach and map is that map returns a new collection
that can have different type of elements. But onEach can modify the internal
state of the objects when applied. Also onEach is lazy and map is not lazy in
kotlin (as far as I know).

Why did I make the comparison with map and not with forEach? Because forEach
is basically a translation of a for and map is a functional function and
onEach it is also a functional function. You can agree or disagree with my way
of trying to explain things, but being rude in your comments saying you are
not right (when I know) and them providing another solution that you also know
it isn't right, feels like a troll comment.

------
dimillian
Can I use it to code full featured modern Android application without Java?

~~~
norswap
Yes. Just one example I have in mind:
[https://github.com/yshrsmz/monotweety](https://github.com/yshrsmz/monotweety)

~~~
dimillian
Really interesting, thanks!

