You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@beam.apache.org by "Beam JIRA Bot (Jira)" <ji...@apache.org> on 2020/08/10 17:08:30 UTC

[jira] [Commented] (BEAM-5298) Determine what painpoints exist for the Go SDK WRT the Go Generics Draft Design

    [ 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)