5 ms·

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 work

by ksec 1y 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.

ckwalsh 1y 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).
- ameliaquining 1y ago
  Why don't they do codegen at build time in Hack?
  - paxys 1y 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.
    - ameliaquining 1y ago
      Why don't they do the same in other languages, then?
arein3 1y ago
I really miss Kotlin's null safety in Java
- vips7L 1y 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 https://openjdk.org/jeps/8316779
  - Tainnor 1y ago
    > I really miss Java’s exception safety in Kotlin. Java is the only language that I'm aware of with checked exceptions (Swift has "throws" which I guess goes in that direction but is untyped) and it's in my experience not notably exception-safer than languages that use values for error handling (such as Rust, Haskell or Kotlin). Swallowing exceptions because of bad ergonomics or misuse by library authors is unfortunately fairly common in a lot of Java code that I've seen. By contrast, most Kotlin code that I've seen uses exceptions only for unrecoverable errors and otherwise uses some sort of sum type (Result, Either or some sealed class/interface). These can be handled ergonomically and in a very type-safe manner - and importantly they don't break when used with higher-order functions. In the future, Kotlin will have Rich Errors which will have even better ergonomics (I'm personally fine with Either, but I know some people dislike a heavily functional style, so this will be good for them).
    - vips7L 1y ago
      Swift has typed throws now. > Swallowing exceptions because of bad ergonomics or misuse by library authors is unfortunately fairly common in a lot of Java code that I've seen This is because the language has not invested to make the ergonomics better. Checked exceptions/errors are still superior than runtime exceptions. "Misuse" can still occur with values. Bad developers can still bubble errors they can't handle and that you can't handle either. I've written elsewhere [0] the things that Java needs. > By contrast, most Kotlin code that I've seen uses exceptions only for unrecoverable errors Except for the whole Kotlin standard library. Like you said the errors as unions proposal is very far away. So either I need to adopt some library and then when unions come I now have 2-3 competing systems + whatever the libraries are using. I'd rather just use checked exceptions. > - and importantly they don't break when used with higher-order functions. This is not a property of values or exceptions. It's a property of the type system. Checked exceptions can work perfectly fine with higher order functions, Scala has done good research there [1] and I believe Swift's typed throws works with lambdas as well; Java just hasn't invested in the language. Ultimately, there is no difference because Result<T, Error> and T func() throws Exception. One is not superior to the other. What it comes down to for me is whether a language has support for checked errors or not, and Kotlin does not. [0] https://news.ycombinator.com/item?id=44432640 https://news.ycombinator.com/item?id=44432640 [1] https://docs.scala-lang.org/scala3/reference/experimental/canthrow.html https://docs.scala-lang.org/scala3/reference/experimental/ca...
elcapitan 1y 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?
- dagw 1y 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'.
  - elcapitan 1y 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.
    - Tainnor 1y 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.
    - ackfoobar 1y 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.
tengbretson 1y ago
Coming from Scala and TypeScript, I always thought Kotlin had under complexity.

by ksec 1y ago

ckwalsh 1y 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).

ameliaquining 1y ago
Why don't they do codegen at build time in Hack?
- paxys 1y 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.
  - ameliaquining 1y ago
    Why don't they do the same in other languages, then?

arein3 1y ago

I really miss Kotlin's null safety in Java

vips7L 1y 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 https://openjdk.org/jeps/8316779
- Tainnor 1y ago
  > I really miss Java’s exception safety in Kotlin. Java is the only language that I'm aware of with checked exceptions (Swift has "throws" which I guess goes in that direction but is untyped) and it's in my experience not notably exception-safer than languages that use values for error handling (such as Rust, Haskell or Kotlin). Swallowing exceptions because of bad ergonomics or misuse by library authors is unfortunately fairly common in a lot of Java code that I've seen. By contrast, most Kotlin code that I've seen uses exceptions only for unrecoverable errors and otherwise uses some sort of sum type (Result, Either or some sealed class/interface). These can be handled ergonomically and in a very type-safe manner - and importantly they don't break when used with higher-order functions. In the future, Kotlin will have Rich Errors which will have even better ergonomics (I'm personally fine with Either, but I know some people dislike a heavily functional style, so this will be good for them).
  - vips7L 1y ago
    Swift has typed throws now. > Swallowing exceptions because of bad ergonomics or misuse by library authors is unfortunately fairly common in a lot of Java code that I've seen This is because the language has not invested to make the ergonomics better. Checked exceptions/errors are still superior than runtime exceptions. "Misuse" can still occur with values. Bad developers can still bubble errors they can't handle and that you can't handle either. I've written elsewhere [0] the things that Java needs. > By contrast, most Kotlin code that I've seen uses exceptions only for unrecoverable errors Except for the whole Kotlin standard library. Like you said the errors as unions proposal is very far away. So either I need to adopt some library and then when unions come I now have 2-3 competing systems + whatever the libraries are using. I'd rather just use checked exceptions. > - and importantly they don't break when used with higher-order functions. This is not a property of values or exceptions. It's a property of the type system. Checked exceptions can work perfectly fine with higher order functions, Scala has done good research there [1] and I believe Swift's typed throws works with lambdas as well; Java just hasn't invested in the language. Ultimately, there is no difference because Result<T, Error> and T func() throws Exception. One is not superior to the other. What it comes down to for me is whether a language has support for checked errors or not, and Kotlin does not. [0] https://news.ycombinator.com/item?id=44432640 https://news.ycombinator.com/item?id=44432640 [1] https://docs.scala-lang.org/scala3/reference/experimental/canthrow.html https://docs.scala-lang.org/scala3/reference/experimental/ca...

elcapitan 1y 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?

dagw 1y 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'.
- elcapitan 1y 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.
  - Tainnor 1y 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.
  - ackfoobar 1y 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.

tengbretson 1y ago

Coming from Scala and TypeScript, I always thought Kotlin had under complexity.