You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@beam.apache.org by "Robert Burke (Jira)" <ji...@apache.org> on 2022/01/13 19:52:00 UTC

[jira] [Updated] (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:all-tabpanel ]

Robert Burke updated BEAM-5298:
-------------------------------
    Resolution: Fixed
        Status: Resolved  (was: Open)

At this point Go Generics is coming out, and is sufficient for our current needs WRT removing the code generator and adding certain other conveniences. Closing this issue.

> 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: P3
>
> 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.20.1#820001)