101–110 of 185 posts
Earlier quoted context omitted.
I don't see how this reduces the need for a test that the wrong type is handled correctly.
The underlying idea is that it shouldn't handle the wrong type at all, it should fail. If some function A calls function B with a wrong type, the problem is with function A. So basically, there should be only type tests after IO functions (probably after parsing), the rest can be assertions.
> Kotlin comes from industry, not academia. It solves problems faced by working programmers today. As an example, the type system helps you avoid null pointer exceptions. I'm sorry but you just undercut your own anti-intellectualism better than I could right there. (There exist languages which have guarded against this without loss of expressive power since before Java and, oh, are from academia.)
A better example of 'engineering not academy' would be explicit vectorization, memory layout support and a good FFI. (all the stuff that in theory is better managed by compilers, in practice it either doesn't matter at all or else should be left to humans). Please correct me if I'm wrong, but Kotlin doesn't improve on Java in these areas.
> Kotlin comes from industry, not academia. It solves problems faced by working programmers today. As an example, the type system helps you avoid null pointer exceptions. I'm sorry but you just undercut your own anti-intellectualism better than I could right there. (There exist languages which have guarded against this without loss of expressive power since before Java and, oh, are from academia.)
Earlier quoted context omitted.
I would love to see that happen (or something similar, like Swift). I fear that it will be hard to move in that direction as long as Google does not push in that direction though. The official word is that we don't need their support in order to write Android apps in Kotlin, which is true and that the gap between objC and Swift was large enough to justify the change but that Java is not that old, which is debatable.…
> In all cases, it is hard to argument the move to a new language in an existing codebase when there is no official push in that direction. I don't understand the logic behind this sentence? Why do you need Google to push you somewhere instead of you youself choosing a more productive option? Kotlin is designed to be easy to integrate into existing Java codebase and our introduction to a largeish Android codebase has…
However, right now I am a senior engineer working on a 8 years old android app alongside 15 other Android devs.
The switch to another language is not even something that the current lead or the CTO are willing to consider.
In their defense, we would have to train the whole team, this would be a major task and build times are already a big issue so anything degrading them is hard to push for.
A push from Google would help a lot, it would remove a lot of objections like "this is hipster shit" or "I am not going to learn the language of the month" (coming from people who have not learned any language in years) and force them to take it seriously.
Even the iOS team barely use Swift though, so I don't see it in a near future. I guess I just have to search for another company.
> our introduction to a largeish Android codebase has been a great success. Do you mind sharing some details ?
Kotlin reminds me of coffescript to JavaScript.
Kotlin is unquestionably a very large improvement over plain old Java. I fear it might be very hard to make the Android community adopt it massively though, unless Google pitches in and supports it officially.
The Android community has already adopted it pretty significantly (join the #android Kotlin slack and see for yourself). And this was done without any official support for Google because... it's not necessary: Kotlin works out of the box. Which is one of Kotlin's strengths.
Do you have any adoption numbers though ? From what I see in the local companies, kotlin is still very rare, except for a couple of startups (which makes them very attractive tbh). That anecdotal evidence of course and I would love to see a tide change but hard numbers would be an huge help.
Earlier quoted context omitted.
Personally I don't much mind the added verbosity, coming from Ruby/Python/JS, so long as I don't have to write so many damn tests. Speaking from minimal experience, Kotlin still seems like a big net win here. Same is true of other languages with lightweight, static type systems like TypeScript/Flow, Swift, and Go. I agree about the documentation – I think it's one of the biggest reasons the language has seen such lit…
I agree the documentation needs work and I am using Kotlin in prod. JetBrains please take note!
Btw, the whole kotlinlang.org is OSS, and you can correct things you don't
I tried Kotlin during the Surprise Language round of Codeforces, a programming competition. I found it to be more verbose than a typical modern scripting language. Maybe it's the result of choosing the least of the evils for what it's trying to accomplish. The other drawback: the documentation. Kotlin's reference documentation (looking up how to properly use a call) does not have any examples. I'm not even talking ab…
Personally I don't much mind the added verbosity, coming from Ruby/Python/JS, so long as I don't have to write so many damn tests. Speaking from minimal experience, Kotlin still seems like a big net win here. Same is true of other languages with lightweight, static type systems like TypeScript/Flow, Swift, and Go. I agree about the documentation – I think it's one of the biggest reasons the language has seen such lit…
That's the reason one should use build tools, be it Ant, Maven, or Gradle. The process of setting them up without an IDE is narrowly described in the docs https://kotlinlang.org/docs/tutorials/build-tools.html
Wow, so much negativity here O.o Kotlin is getting rapid adoption in the Android community and is quickly getting the same status as Swift has in the iOS world. The main reasons for the rapid adoption are: - It's designed to easily integrate into existing Java codebases. This means that starting to use Kotlin is pretty much a case of adding two Gradle dependencies and source files into `src/kotlin`. Interop with Java…
What's keeping Swift itself from eventually becoming the preferred language for Android as well?
Wow, so much negativity here O.o Kotlin is getting rapid adoption in the Android community and is quickly getting the same status as Swift has in the iOS world. The main reasons for the rapid adoption are: - It's designed to easily integrate into existing Java codebases. This means that starting to use Kotlin is pretty much a case of adding two Gradle dependencies and source files into `src/kotlin`. Interop with Java…
> quickly getting the same status as Swift has in the iOS world. What's keeping Swift itself from eventually becoming the preferred language for Android as well?
And the fact that there's no standard library outside the Apple world for the language. Adoption of Swift makes pretty much no sense, technologically or politically.