[ 
https://issues.apache.org/jira/browse/BEAM-5298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17174839#comment-17174839
 ] 

Beam JIRA Bot commented on BEAM-5298:
-------------------------------------

This issue is P2 but has been unassigned without any comment for 60 days so it 
has been labeled "stale-P2". If this issue is still affecting you, we care! 
Please comment and remove the label. Otherwise, in 14 days the issue will be 
moved to P3.

Please see https://beam.apache.org/contribute/jira-priorities/ for a detailed 
explanation of what these priorities mean.


> Determine what painpoints exist for the Go SDK WRT the Go Generics Draft 
> Design
> -------------------------------------------------------------------------------
>
>                 Key: BEAM-5298
>                 URL: https://issues.apache.org/jira/browse/BEAM-5298
>             Project: Beam
>          Issue Type: Bug
>          Components: sdk-go
>            Reporter: Robert Burke
>            Priority: P2
>              Labels: stale-P2
>
> Specifically, the outcome should be a doc outlining what would need to change 
> in the SDK as a consequence of the draft design, with a focus on the user 
> experience, and how much unnecessary user toil could be avoided.
> [https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md]
> Initial impressions:
> As the draft design indicates, the current SDK code would not be required to 
> change, it would continue working as is, as the change is intended to be 
> backwards compatible. Users should be able to use their own generic code with 
> the v1 of the SDK.
>  
> A v2 of the Go SDK could remove much of the code the SDK spends in doing it's 
> own type checking of pipelines at construction time, in favour of the 
> compiler.
> PCollections would be properly typed to facilitate this.
> Specific focus should be made to cover the user experience side, and sketch 
> implementations of the generic types (like PCollection) and functions (like 
> ParDo), as well as on the execution harness side. eg. is it possible to avoid 
> reflection or type assertion on the processing path?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to