search

sk22 / megalodon

Pink modification of the official Mastodon for Android app
https://sk22.github.io/megalodon
GNU General Public License v3.0
546 stars 34 forks source link

Incrementally port to Kotlin #500

Open girlbossceo opened 1 year ago

girlbossceo commented 1 year ago

While I do know that this is a fork of the upstream app, some tiny files could potentially be incrementally ported to Kotlin and wouldn't be very difficult to maintain with upstream especially if they very rarely change. If downstream code has significantly diverged from upstream, then porting more larger stuff to Kotlin wouldn't hurt.

Kotlin has many benefits over Java and is the new language that official AOSP uses for new projects and files where possible. The biggest issue Kotlin solves is proper null safety and overall code safety which Java does not have.

https://kotlinlang.org/docs/comparison-to-java.html

https://kotlinlang.org/docs/android-overview.html

https://developer.android.com/kotlin

FineFindus commented 1 year ago

https://github.com/mastodon/mastodon-android/issues/3 explains why upstream is not moving to Kotlin. Also, this makes maintenance harder when switching between languages, plus the maintainer needs to know/learn Kotlin.

girlbossceo commented 1 year ago

That doesn't explain anything. That was a very unproductive, one-sided, and close-minded "discussion" by a member of the Mastodon team (which is typical of them) that was closed immediately and locked by Gargron forbidding any further discussion all because one of the Mastodon team members said "google bad k get out of here". This is behaviour that isn't unseen with the Mastodon team before. It wasn't technical or productive in any way.

I already stated that I'm aware this is a fork and acknowledged the maintenance issue.

While I do know that this is a fork of the upstream app, some tiny files could potentially be incrementally ported to Kotlin and wouldn't be very difficult to maintain with upstream especially if they very rarely change. If downstream code has significantly diverged from upstream, then porting more larger stuff to Kotlin wouldn't hurt.

girlbossceo commented 1 year ago

The original user who submitted that issue failed to cite any official links that explain why Kotlin is objectively better than Java for Android development, and failed to mention some benefits.

I posted 3 resources and mentioned null safety, especially because null safety is a difficult thing to work with in regards to Java. Perhaps a proper discussion with the maintainer of this project would be warranted instead of upholding a very bad and invalid "discussion" by upstream. This project makes changes that goes against what upstream does. So why would we uphold a verdict by upstream if we're supposed to make significant downstream changes?

If the author of this project simply doesn't know Kotlin, then that's completely understandable and I don't expect the maintainer to go out and learn it.

Otherwise, I would love to hear some actual factual reasons or have a proper discussion on why Kotlin should not be considered that aren't "google bad lol" or "no one uses kotlin, everyone knows java more therefore java better".

Jacocococo commented 1 year ago

Null safety is a big problem here and a cause for a lot of crashes, especially on non-Mastodon instances

However, with the way the code is currently structured, basically all values that are fetched from the APIs will need to be optional types anyways, and I don't see a way to get around that anyways because we can't be sure that each request to the server will provide every field we need. While optional Kotlin types do prompt the developer to consider if the value could be null, it is also very easy to get around it and so I don't actually think it would be used properly since the fields will often just be expected never to be null until they turn out to be in some niche scenario

Some fields have also been marked as required as a kind of null safety, but that actually lead to problems sometimes where nothing bad would happen if it was null, but since it was marked as something that couldn't be null, it ended up causing a problem exactly because of that

So overall I don't think Kotlin will help enough for it to be worth it, especially not as long as upstream doesn't use it, and I also understand upstream's reasoning for not using it. This is just my take as someone who has opened a few PRs tho