[
https://issues.apache.org/jira/browse/FLINK-13414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17344555#comment-17344555
]
Nick Burkard edited comment on FLINK-13414 at 5/14/21, 12:12 PM:
-----------------------------------------------------------------
I love Scala and use it everyday at work, but my intuition would think most
Flink users are writing their code directly in Java / Python, or wrapping the
API with something like Beam. I'd love to be proven wrong here with metrics
etc., but Scala is a very niche language with a high learning curve, especially
for the FP-centric style that's become more popular within the last few years
thanks to the success of cats / zio / etc.. The languages may share the JVM but
can look entirely different depending on who's writing the code.
Flink is almost exclusively implemented in Java which is great - it's the right
tool for the job here. As others have mentioned, maintaining proper Scala
support in a library that's almost exclusively Java requires dedicated
resources who specialize in the language and understand its many nuances. The
Scala community has the capacity and interest to develop Scala APIs around OSS
libraries & frameworks, but it's typically done separately from the source
projects themselves. This lets the two communities set their own precedents for
code quality / style / etc. without interfering in each other's releases.
Binary compatibility has been one major issue in the past. 2.13 also comes with
the issues of migrating the collections API. 3 would require rewriting the
macros uses to generate TypeInformation as well.
I think the best choice would be to deprecate the official Scala APIs first,
then phase out official Scala support by some later version. The Scala
community can then drive best practices for developing a Scala wrapper around
Flink, perhaps even supporting Scala 3 once it's picked up momentum
commercially.
was (Author: nickburkard):
I love Scala and use it everyday at work, but my intuition would think most
Flink users are writing their code directly in Java / Python, or wrapping the
API with something like Beam. I'd love to be proven wrong here with metrics
etc., but Scala is a very niche language with a high learning curve, especially
for the FP-centric style that's become more popular within the last few years
thanks to the success of cats / zio / etc.. The languages may share the JVM but
can look entirely different depending on who's writing the code.
Flink is almost exclusively implemented in Java which is great - it's the right
tool for the job here. As others have mentioned, maintaining proper Scala
support in a library that's almost exclusively Java requires dedicated
resources who specialize in the language and understand its many nuances. The
Scala community has the capacity and interest to develop Scala APIs around OSS
libraries & frameworks, but it's typically done separately from the source
projects themselves. This lets the two communities set their own precedents for
code quality / style / etc. without interfering in each other's releases.
Binary compatibility has been one major issue in the past. 2.13 also comes with
the issues of migrating the collections API as well. 3 would require rewriting
the macros uses to generate TypeInformation as well.
I think the best choice would be to deprecate the official Scala APIs first,
then phase out official Scala support by some later version. The Scala
community can then drive best practices for developing a Scala wrapper around
Flink, perhaps even supporting Scala 3 once it's picked up momentum
commercially.
> Add support for Scala 2.13
> --------------------------
>
> Key: FLINK-13414
> URL: https://issues.apache.org/jira/browse/FLINK-13414
> Project: Flink
> Issue Type: New Feature
> Components: API / Scala
> Reporter: Chaoran Yu
> Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
