[
https://issues.apache.org/jira/browse/SPARK-32530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17175052#comment-17175052
]
Sean R. Owen commented on SPARK-32530:
--------------------------------------
I speak for myself, but, I think the cost is viewed as very high. Which is
valid; maintaining every change across 3 languages has proved to be a lot of
work. As I say, I'm not even sure of the future of the R bindings; despite
hopes that these would be equally maintained, they just aren't at parity, even.
I think the argument would have to be: this opens up Spark to a class of users
that can't really otherwise use it. JVM users use Spark directly (or Java, more
rarely), Python users can use Pyspark; R users for now can use SparkR or
sparklyr, which is a separate project. I am not sure how many users use Kotlin,
but can't use Java or Scala?
I fully trust the intentions of any group that says "we will maintain our
contribution" despite the inevitable fact that it doesn't always work out that
way in OSS. If the Kotlin bindings are in Spark, notionally, they have to be
updated by anyone touching any APIs, etc. That just will never only fall on one
group of maintainers.
OK, so you say, it's fine if they lag a bit, differ a bit. If some degree of
'lag' is OK, then I think that neuters the argument, in the short term, for
pushing it into Spark now. Just let it succeed as-is, as a third-party project.
As you say, .NET is 'harder' to run this way but its bindings have done OK
separately.
What goes wrong if it stays in its current form?
> SPIP: Kotlin support for Apache Spark
> -------------------------------------
>
> Key: SPARK-32530
> URL: https://issues.apache.org/jira/browse/SPARK-32530
> Project: Spark
> Issue Type: Improvement
> Components: Spark Core
> Affects Versions: 3.0.1
> Reporter: Pasha Finkeshteyn
> Priority: Major
>
> h2. Background and motivation
> Kotlin is a cross-platform, statically typed, general-purpose JVM language.
> In the last year more than 5 million developers have used Kotlin in mobile,
> backend, frontend and scientific development. The number of Kotlin developers
> grows rapidly every year.
> * [According to
> redmonk|https://redmonk.com/sogrady/2020/02/28/language-rankings-1-20/]:
> "Kotlin, the second fastest growing language we’ve seen outside of Swift,
> made a big splash a year ago at this time when it vaulted eight full spots up
> the list."
> * [According to snyk.io|https://snyk.io/wp-content/uploads/jvm_2020.pdf],
> Kotlin is the second most popular language on the JVM
> * [According to
> StackOverflow|https://insights.stackoverflow.com/survey/2020] Kotlin’s share
> increased by 7.8% in 2020.
> We notice the increasing usage of Kotlin in data analysis ([6% of users in
> 2020|https://www.jetbrains.com/lp/devecosystem-2020/kotlin/], as opposed to
> 2% in 2019) and machine learning (3% of users in 2020, as opposed to 0% in
> 2019), and we expect these numbers to continue to grow.
> We, authors of this SPIP, strongly believe that making Kotlin API officially
> available to developers can bring new users to Apache Spark and help some of
> the existing users.
> h2. Goals
> The goal of this project is to bring first-class support for Kotlin language
> into the Apache Spark project. We’re going to achieve this by adding one more
> module to the current Apache Spark distribution.
> h2. Non-goals
> There is no goal to replace any existing language support or to change any
> existing Apache Spark API.
> At this time, there is no goal to support non-core APIs of Apache Spark like
> Spark ML and Spark structured streaming. This may change in the future based
> on community feedback.
> There is no goal to provide CLI for Kotlin for Apache Spark, this will be a
> separate SPIP.
> There is no goal to provide support for Apache Spark < 3.0.0.
> h2. Current implementation
> A working prototype is available at
> [https://github.com/JetBrains/kotlin-spark-api]. It has been tested inside
> JetBrains and by early adopters.
> h2. What are the risks?
> There is always a risk that this product won’t get enough popularity and will
> bring more costs than benefits. It can be mitigated by the fact that we don't
> need to change any existing API and support can be potentially dropped at any
> time.
> We also believe that existing API is rather low maintenance. It does not
> bring anything more complex than already exists in the Spark codebase.
> Furthermore, the implementation is compact - less than 2000 lines of code.
> We are committed to maintaining, improving and evolving the API based on
> feedback from both Spark and Kotlin communities. As the Kotlin data community
> continues to grow, we see Kotlin API for Apache Spark as an important part in
> the evolving Kotlin ecosystem, and intend to fully support it.
> h2. How long will it take?
> A working implementation is already available, and if the community will
> have any proposal of changes for this implementation to be improved, these
> can be implemented quickly — in weeks if not days.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org
