Meta Joins Kotlin Foundation
47 points
1 day ago
| 3 comments
| engineering.fb.com
| HN
grizzles
5 hours ago
[-]
I use kotlin at work every day and I'm suprised it (and particular Kotlin/Compose Multiplatform) are not more popular. It's a true alternative to javascript that lets you share native ui code across web,ios,android,desktop and more (eg. watchOS).
reply
Apofis
1 day ago
[-]
Kotlin is awesome, good on Meta.
reply
ksec
1 day ago
[-]
I am not sure if it has something to do with age. But I found both Kotlin and Swift share pretty much the same thing. Over Complexity. Objective C and Java works.

I am also wondering if Meta still uses PHP or Hack.

reply
ckwalsh
1 day ago
[-]
> I am also wondering if Meta still uses PHP or Hack

Meta’s WWW codebase is its oldest, and still written in Hacklang. Lots of internal tooling is also written in Hack.

I wouldn’t be surprised if there are more committed lines of Hacklang than any other language (although, a good chunk of that is codegen, vs other core languages where codegen is part of the build process).

reply
ameliaquining
17 hours ago
[-]
Why don't they do codegen at build time in Hack?
reply
paxys
16 hours ago
[-]
Hack does JIT compilation.

Even otherwise, at the scale the company operates it's much better to run codegen once at commit time rather than recreate the entire codebase on every deploy (several times a day) which would take forever.

reply
ameliaquining
14 hours ago
[-]
Why don't they do the same in other languages, then?
reply
elcapitan
19 hours ago
[-]
I never worked with Kotlin, but have kept it in the back of my head as the simpler alternative to Java if I had to target the JVM. What makes it more complex?
reply
dagw
19 hours ago
[-]
Disclaimer. Last time I seriously used Java, I was using Java 8, and I've only used Kotlin for screwing around with Android development on my own time. So what follows might be way off.

Kotlin provides a lot of 'clever' syntactic sugar and features that makes certain things that are quite verbose in Java, nice and compact in Kotlin. It also means that there are many way to achieve the same thing in Kotlin. Once you've learned everything it allows you to do things that would take a lot of Java in much fewer lines of code. But there is also just more 'stuff' to learn in the Kotlin language.

Java is a much simpler language than Kotlin with relatively few features, but this simplicity means you sometimes have to build quite verbose structures to achieve what you want.

So which is 'simpler' very much comes down to how you define 'simple'.

reply
jfengel
16 hours ago
[-]
Since then, Java has incorporated a lot of the syntactic sugar from Kotlin. Not all of it; they're still very judicious about trying to keep the language tight. But things like the lambda features have even made it down into the JVM (which is actually incredibly stable).

Kotlin's one big advantage is having avoided the "billion dollar mistake" of null pointers. Or at least, mitigated it. But in my opinion it's not sufficient to install a whole new language into your stack.

reply
vips7L
15 hours ago
[-]
One day we’ll get nullable types: https://openjdk.org/jeps/8303099

I believe I read on the mailing list it’s implemented here: https://github.com/openjdk/valhalla/tree/lw5

reply
elcapitan
18 hours ago
[-]
Oh I see, so this is kind of like with Ruby, where people build a lot of magic that looks simple but hides complexity that you still need to understand.
reply
ackfoobar
12 hours ago
[-]
I'd say the magic of Kotlin comes down to a few syntactic constructs that compose very well. Also, a decent type system helps with understanding any magic, even those not tastefully created.
reply
Tainnor
12 hours ago
[-]
No. Unlike Ruby, Kotlin is compiled and you can't monkeypatch things, so unless you go out of your way to do reflection magic (something that is unfortunately common in the Java community), you won't get weird runtime surprises like not knowing where a method comes from.
reply
Tainnor
12 hours ago
[-]
Java also has to maintain backwards compatibility at (almost) all cost, so it has a lot of warts that it can't or won't remove. For example, I think there are like 4 or 5 different types of switch statements/expressions.

I also think that checked exceptions are a major flaw (particularly because they don't work well with lambdas) but I don't foresee them getting removed anytime soon.

reply
mystified5016
14 hours ago
[-]
IME, it's sort of like the difference between C and C#.

Kotlin is incredibly expressive and can get quite complicated. Java is a bit more brutally simple (and obviously more verbose).

As a C# dev primarily, I love Kotlin, and I've always hated Java despite it being the very first language I learned.

I wouldn't call Kotlin simple by any stretch of the imagination. It's just a very high-level language.

reply
arein3
23 hours ago
[-]
I really miss Kotlin's null safety in Java
reply
vips7L
20 hours ago
[-]
I really miss Java’s exception safety in Kotlin.

If Java ever ships Valhalla we might get null restricted types: https://openjdk.org/jeps/8316779

reply
ameliaquining
17 hours ago
[-]
Note that you can get null safety in Java today from third-party static analysis tools: https://jspecify.dev/docs/whether/#nullness-checker-support-...

Additionally, the above-linked JEP only proposes to make a small subset of types potentially null-safe. The goal there is performance, not correctness.

reply
vips7L
15 hours ago
[-]
I linked the wrong JEP because I was tired. The goal is correctness: https://openjdk.org/jeps/8303099

> Enhance Java's reference types to let programmers express whether null references are expected as values of the type

reply
ameliaquining
14 hours ago
[-]
> It is not a goal (at this time) to apply the language enhancements to the standard libraries

That seems really very limiting and like it would make the feature not very useful in practice.

reply
vips7L
14 hours ago
[-]
> (at this time)

It will eventually be a goal. Java does things in steps. First will be introducing the syntax, then another JEP will take care of the standard library. Just like they introduced virtual threads and then introduced structured concurrency. Or like introducing records and then introducing pattern matching over records. Baby steps.

reply
throwaway_20357
16 hours ago
[-]
I prefer Scala's Option over Kotlin's nulls.
reply
tengbretson
16 hours ago
[-]
Coming from Scala and TypeScript, I always thought Kotlin had under complexity.
reply