github.com/graybobo/golang.org-package-offline-cache@v0.0.0-20200626051047-6608995c132f/x/blog/content/a-conversation-with-the-go-team.article (about)

     1  A conversation with the Go team
     2  6 Jun 2013
     3  
     4  * Introduction
     5  
     6  At Google I/O 2013, several members of the Go team hosted a "Fireside chat."
     7  Robert Griesemer, Rob Pike, David Symonds, Andrew Gerrand, Ian Lance Taylor,
     8  Sameer Ajmani, Brad Fitzpatrick, and Nigel Tao took questions from the audience
     9  and people around the world about various aspects of the Go project.
    10  
    11  .iframe http://www.youtube.com/embed/p9VUCp98ay4 309 549
    12  
    13  We also hosted a similar session at I/O last year:
    14  [[http://www.youtube.com/watch?v=sln-gJaURzk][_Meet_the_Go_team_]].
    15  
    16  There were many more questions from Google Moderator than we were able to
    17  answer in the short 40 minute session.
    18  Here we answer some of those we missed in the live session.
    19  
    20  _Linking_speed_(and_memory_usage)_for_the_gc_toolchain_are_a_known_problem._
    21  _Are_there_any_plans_to_address_this_during_the_1.2_cycle?_
    22  
    23  *Rob:* Yes. We are always thinking about ways to improve performance of the
    24  tools as well as the language and libraries.
    25  
    26  _I_have_been_very_pleased_to_see_how_quickly_Go_appears_to_be_gaining_traction._
    27  _Can_you_talk_about_the_reactions_you_have_experienced_working_with_other_
    28  _developers_inside_and_outside_Google?_Are_there_any_major_sticking_points_remaining?_
    29  
    30  *Robert:* A lot of developers that seriously tried Go are very happy with it.
    31  Many of them report a much smaller, more readable and thus maintainable code
    32  base: A 50% code size reduction or more when coming from C++ seems common.
    33  Developers that switched to Go from Python are invariably pleased with the
    34  performance gain. The typical complaints are about small inconsistencies in the
    35  language (some of which we might iron out at some point). What surprises me is
    36  that almost nobody complains about the lack of generics.
    37  
    38  _When_will_Go_be_a_first-class_language_for_Android_development?_
    39  
    40  *Andrew:* This would be great, but we don't have anything to announce.
    41  
    42  _Is_there_a_roadmap_for_the_next_version_of_Go?_
    43  
    44  *Andrew:* We have no feature roadmap as such. The contributors tend to work on
    45  what interests them. Active areas of development include the gc and gccgo
    46  compilers, the garbage collector and runtime, and many others. We expect the
    47  majority of exciting new additions will be in the form of improvements to our
    48  tools. You can find design discussions and code reviews on the
    49  [[http://groups.google.com/group/golang-dev][golang-dev mailing list]].
    50  
    51  As for the timeline, we do have
    52  [[https://docs.google.com/document/d/106hMEZj58L9nq9N9p7Zll_WKfo-oyZHFyI6MttuZmBU/edit?usp=sharing][concrete plans]]:
    53  we expect to release Go 1.2 on December 1, 2013.
    54  
    55  _Where_do_you_guys_want_to_see_Go_used_externally?_
    56  _What_would_you_consider_a_big_win_for_Go_adoption_outside_Google?_
    57  _Where_do_you_think_Go_has_the_potential_to_make_a_significant_impact?_
    58  
    59  *Rob:* Where Go is deployed is up to its users, not to us. We're happy to see
    60  it gain traction anywhere it helps. It was designed with server-side software
    61  in mind, and is showing promise there, but has also shown strengths in many
    62  other areas and the story is really just beginning. There are many surprises to
    63  come.
    64  
    65  *Ian:* It’s easier for startups to use Go, because they don’t have an
    66  entrenched code base that they need to work with. So I see two future big wins
    67  for Go. One would be a significant use of Go by an existing large software
    68  company other than Google. Another would be a significant IPO or acquisition
    69  of a startup that primarily uses Go. These are both indirect: clearly choice
    70  of programming language is a very small factor in the success of a company.
    71  But it would be another way to show that Go can be part of a successful
    72  software system.
    73  
    74  _Have_you_thought_any_(more)_about_the_potential_of_dynamically_loading_
    75  _Go_packages_or_objects_and_how_it_could_work_in_Go?_
    76  _I_think_this_could_enable_some_really_interesting_and_expressive_constructs,_
    77  _especially_coupled_with_interfaces._
    78  
    79  *Rob:* This is an active topic of discussion. We appreciate how powerful the
    80  concept can be and hope we can find a way to implement it before too long.
    81  There are serious challenges in the design approach to take and the need to
    82  make it work portably.
    83  
    84  _There_was_a_discussion_a_while_ago_about_collecting_some_best-of-breed_
    85  `database/sql` _drivers_in_a_more_central_place._
    86  _Some_people_had_strong_opinions_to_the_contrary_though._
    87  _Where_is_ `database/sql` _and_its_drivers_going_in_the_next_year?_
    88  
    89  *Brad:* While we could create an official subrepo (“go.db”) for database
    90  drivers, we fear that would unduly bless certain drivers. At this point we’d
    91  still rather see healthy competition between different drivers. The
    92  [[https://golang.org/wiki/SQLDrivers][SQLDrivers wiki page]]
    93  lists some good ones.
    94  
    95  The `database/sql` package didn’t get much attention for a while, due to lack of
    96  drivers. Now that drivers exist, usage of the package is increasing and
    97  correctness and performance bugs are now being reported (and fixed). Fixes will
    98  continue, but no major changes to the interface of `database/sql` are planned.
    99   There might be small extensions here and there as needed for performance or to
   100  assist some drivers.
   101  
   102  _What_is_the_status_of_versioning?_
   103  _Is_importing_some_code_from_github_a_best_practice_recommended_by_the_Go_team?_
   104  _What_happens_when_we_publish_our_code_that_is_dependent_on_a_github_repo_and_
   105  _the_API_of_the_dependee_changes?_
   106  
   107  *Ian:* This is frequently discussed on the mailing list. What we do internally
   108  is take a snapshot of the imported code, and update that snapshot from time to
   109  time. That way, our code base won't break unexpectedly if the API changes.
   110  But we understand that that approach doesn’t work very well for people who are
   111  themselves providing a library. We’re open to good suggestions in this area.
   112  Remember that this is an aspect of the tools that surround the language rather
   113  than the language itself; the place to fix this is in the tools, not the
   114  language.
   115  
   116  _What_about_Go_and_Graphical_User_Interfaces?_
   117  
   118  *Rob:* This is a subject close to my heart. Newsqueak, a very early precursor
   119  language, was designed specifically for writing graphics programs (that's what
   120  we used to call apps). The landscape has changed a lot but I think Go's
   121  concurrency model has much to offer in the field of interactive graphics.
   122  
   123  *Andrew:* There are many
   124  [[https://golang.org/wiki/Projects#Graphics_and_Audio][bindings for existing graphics libraries]]
   125  out there, and a few Go-specific projects. One of the more promising ones is
   126  [[https://github.com/skelterjohn/go.uik][go.uik]], but it's still in its early
   127  days. I think there's a lot of potential for a great Go-specific UI toolkit for
   128  writing native applications (consider handling user events by receiving from a
   129  channel), but developing a production-quality package is a significant
   130  undertaking. I have no doubt one will come in time.
   131  
   132  In the meantime, the web is the most broadly available platform for user
   133  interfaces. Go provides great support for building web apps, albeit only on the
   134  back end.
   135  
   136  _In_the_mailing_lists_Adam_Langley_has_stated_that_the_TLS_code_has_not_been_
   137  _reviewed_by_outside_groups,_and_thus_should_not_be_used_in_production._
   138  _Are_there_plans_to_have_the_code_reviewed?_
   139  _A_good_secure_implementation_of_concurrent_TLS_would_be_very_nice._
   140  
   141  *Adam*: Cryptography is notoriously easy to botch in subtle and surprising ways
   142  and I’m only human. I don’t feel that I can warrant that Go’s TLS code is
   143  flawless and I wouldn’t want to misrepresent it.
   144  
   145  There are a couple of places where the code is known to have side-channel
   146  issues: the RSA code is blinded but not constant time, elliptic curves other
   147  than P-224 are not constant time and the Lucky13 attack might work. I hope to
   148  address the latter two in the Go 1.2 timeframe with a constant-time P-256
   149  implementation and AES-GCM.
   150  
   151  Nobody has stepped forward to do a review of the TLS stack however and I’ve not
   152  investigated whether we could get Matasano or the like to do it. That depends
   153  on whether Google wishes to fund it.
   154  
   155  _What_do_you_think_about_ [[http://www.gophercon.com/][_GopherCon_2014_]]_?_
   156  _Does_anyone_from_the_team_plan_to_attend?_
   157  
   158  *Andrew:* It's very exciting. I'm sure some of us will be there.