Hacker News Reader

We had a few places where we had some headscratchers.

First, it took a little time to get the hang of json manipulation. We got to a solution we liked, but a dynamically typed language like groovy has some advantages there.

Closed classes by default can make some testing a little more difficult. We have continued using Spock rather than moving our tests to Kotlin, and there are a few places where we compromise our design until we can figure out a better way. (Yes. Dependency Injection and less coupling is the answer, alongside adding a level of abstraction in between third parties. The devil is in the details.)

In general, we like it and are planning on expanding our use, but conversion has had its challenges.

> First, it took a little time to get the hang of json manipulation. We got to a solution we liked, but a dynamically typed language like groovy has some advantages there.

Does it? I really prefer JSON.NET's approach, which involves declaring models that represent your JSON, over dynamic "hope it's there" approaches.

False equivalence. You can static check this until you ate blue in the face but you still 'hope its there'. You would specify the contract for runtime checking like any sane engineer

Yes, but I don't have to worry about something like unintentionally spelling it differently on different lines, and in the case where I'm controlling both ends it is truly taken care of for me.

What trouble did you run into with JSON? I just make Jackson objects as data classes and I'm done with it. Mucking with ObjectNode/ArrayNode is a bit annoying but not too bad, especially when you can map and collect.

Was gonna say what you did about testing, but you have it, so, yeah. ;)

Short answer is the presence or absence of a field can drive us to different paths in the code base. That can lead to code littered with !! and @JsonIgnoreProperties(ignoreUnknown=true), or multiple intermediary data classes, or similar solutions. For much of our problem space, an extra val or two and some well placed ifs get us out of it.

Regarding closed classes, the all-open plugin ( https://kotlinlang.org/docs/reference/compiler-plugins.html#... ) may be able to help somewhat, though you'll still need to add an annotation to your base classes.

> Kotlin is just Java!

Nobody cares.

I mean, look at JSX, which is just JavaScript. Coming from all the crap templating languages pulled off the last 10 years it is basically god sent. Still people hate around and they always will, that's what we do, we lern stuff and if it gets obsolete, we want to keep it because it fed us for years.

The JSX thing is because we (as an industry) teach "separate your concerns" as gospel and naturally you're going to get some pushback, specially from the very numerous group of "by the book" developers.

Scala was treated for a long time as "a better Java"; but Kotlin really is way more befitting of the title. There shouldn't be as much resistance.

I never considered Scala a better Java. Scala was attempting to be a better language on the JVM, but you'd have to be tripping on something seriously heavy to think Scala even remotely resembles Java. Scala was basically the unholy love child of OCaml, and Haskell, with a tiny sprinkle of Java on top to make it play nicer on the JVM. I had high hopes for Scala, I'm a huge fan of Haskell, but I just couldn't bring myself to like Scala, it's an ugly language that ruins everything good in Haskell by polluting it with OO.

Kotlin on the other hand, really is a better Java. If you take Java, remove all the biggest day to day headaches, change around the defaults to be sane (I.E. the default is what you want 90% of the time, instead of the other way around), and add in some functional inspired helpers, you basically arrive at Kotlin. The delegate system, the way they finally got rid of the need to make pointless getters and setters on the off chance you might some day want them and not want to refactor your entire codebase, making classes and methods public by default since that's what you want almost always, and making types non-nullable by default are all MAJOR improvements over Java, but not something completely alien to the Java way of doing things.

You know, there is a joke that 90% of the developers think that they're better than average. :)

you can thank that one guy who wrote a 10000 line php function to validate email addresses.

10000 lines might not be enough. I'm not sure that it's possible to determine whether something is a valid email address other than trying to send mail to it. If you haven't read the RFCs, they're pretty much a nightmare. The HTML5 spec has this little gem:

> This requirement is a willful violation of RFC 5322, which defines a syntax for e-mail addresses that is simultaneously too strict (before the "@" character), too vague (after the "@" character), and too lax (allowing comments, whitespace characters, and quoted strings in manners unfamiliar to most users) to be of practical use here.[0]

[0] https://www.w3.org/TR/html5/forms.html#e-mail-state-(type=em...

As an aside, if anyone has ever actually used comments, whitespace, or quoted strings in an email address, that would be be extremely interesting to hear about.

That's why I said "probably." ;)

Another way to think about it - 50% of programmers think they are better than average. And the other 50% are. [1]

[1] this assumes programmer skill is normally distributed, which I doubt.

Anecdotally my experience is that for every one really good developer there's about 25 or 30 mediocre ones, and 5 or so really terrible ones. This is based mostly around what I've seen conducting interviews in my area. That is also highly variable, I did some interviews for another office (in another country) and saw ratios more like for every three good developers there were two mediocre ones, and no terrible ones. Maybe we just had a much better recruiter feeding us candidates in the other country, or maybe they just have exceptional programmers living there.

Just symmetrically distributed, doesn't have to be Gaussian. I will crawl back into my hole of pedantry now.

"90% of the developers think that they're better than average"

Median. It can happen that 90% of programmers literally better than the average.

The few bad/worse developers are then 10% and would have to be really bad

Is that unbelievable?

This is part of the joke. It can be true but it's almost impossible to have this kind of distribution among developers.

> It can happen that 90% of programmers literally better than the average.

While mathematically true, in practice almost impossible

This comment is useless since you don't state anything, don't refute anything and add no value.

The other really important thing: You can have both in one project. [1] You can gradually convert your existing Java project to Kotlin; there's even a menu item in IntelliJ to straight up convert a Java file into Kotlin.

[1] https://kotlinlang.org/docs/tutorials/mixing-java-kotlin-int...

I'd be very interested to see if this works out well in practice.

We had the same hope for Scala - the idea being that the developers who were interested in using it functionally could do so in the more complicated parts of our application, but the 'rest' of the developers, many who were honestly either not capable or just not interested in picking it up, would be able to still use traditional Java.

Unfortunately, Scala just had too many incompatibilities: things like Options instead of null or to call a Scala method in Java would require some confusing method call like new Function0<String> because that is how Scala converts to bytecode.

And collections and immutable types never really worked back and forth very well.

The final straw was when we had Thrift interfaces that simply broke if a project moved from Scala 2.10 to 2.11 without recompiling all the dependencies.

But if Kotlin really is completely compatible with Java without too many show stoppers dragging down productivity, this could be helpful for a lot of larger enterprise shops which contain a small subset of engineers who want and can use the language to improve things (or simply don't want to work with old Java code and will jump ship if forced to do so), but still need to keep things simple enough so that the rest of the team can still be productive.

Kotlin is Java in a way that Scala isn't, so, yeah, it works a lot better. The edges can be a bit strange for the Java user but usually in positive ways--for example, passing a null parameter into a Kotlin method that does not accept a null parameter will cause an exception at the call site.

`val` in Kotlin creates an (inaccessible, except via reflection) backing field and a bean-compatible getter. `var` the same, but with a setter. Stuff like that. It works incredibly well.

I learnt Kotlin by taking an Android app which I had written in Java, and gradually converting it i to Kotlin, this was just after 1.0.

I'm a solo developer, and I use K and J together on most codebases (about 10), and at this point I only ever create K files.

Regarding interop, I think it's a valid claim that K is 100% J compatible.

I think instead of arbitrarily mixing the two, maybe start with a single module, or with testing.

I write a lot of JS, and have been planning on trying out Kotlin with JS, because at this point, taking a JS function and converting it to Kotlin results in code that's between 70-80% Kotlin (const to val, add return types, etc.)

I'm personally convinced that Kotlin is a good language to learn if you know Java.

By way of analogy I'll compare languages to languages, specifically spoken and programming. Going from Java to Kotlin is like going from French to Spanish. Going from Java to Scala, is like going from French to Klingon.

More concretely, Scala actually had very little in common with Java. Yes it ran on the JVM, but that was where the similarities stopped, its functional layer and type system were effectively incompatible with Java or the Java standard library. Actually Scala was so badly made, its functional pieces weren't even really compatible with its own OO pieces, if you tried to mix and match the two it caused all kinds of problems. Kotlin in contrast is almost entirely compatible with Java. There are a couple rough spots, mostly around when frameworks depend very heavily on reflection and bytecode manipulation (particularly around annotations), but those can be worked around from both sides without too much trouble, and the rest of the time it's pretty much completely transparent.

It's not that much harder for Android. In fact, with Anko, there's even more reason to pick it up for Android. The pain point in using Java is huge for Android because a lot of Android functionality adds more boilerplate.