{"action":"created","issue":{"url":"https://api.github.com/repos/joyent/rfd/issues/45","repository_url":"https://api.github.com/repos/joyent/rfd","labels_url":"https://api.github.com/repos/joyent/rfd/issues/45/labels{/name}","comments_url":"https://api.github.com/repos/joyent/rfd/issues/45/comments","events_url":"https://api.github.com/repos/joyent/rfd/issues/45/events","html_url":"https://github.com/joyent/rfd/issues/45","id":247162650,"number":45,"title":"RFD 106 Discussion","user":{"login":"tgross","id":1409219,"avatar_url":"https://avatars3.githubusercontent.com/u/1409219?v=4","gravatar_id":"","url":"https://api.github.com/users/tgross","html_url":"https://github.com/tgross","followers_url":"https://api.github.com/users/tgross/followers","following_url":"https://api.github.com/users/tgross/following{/other_user}","gists_url":"https://api.github.com/users/tgross/gists{/gist_id}","starred_url":"https://api.github.com/users/tgross/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tgross/subscriptions","organizations_url":"https://api.github.com/users/tgross/orgs","repos_url":"https://api.github.com/users/tgross/repos","events_url":"https://api.github.com/users/tgross/events{/privacy}","received_events_url":"https://api.github.com/users/tgross/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":{"login":"sean-","id":349516,"avatar_url":"https://avatars1.githubusercontent.com/u/349516?v=4","gravatar_id":"","url":"https://api.github.com/users/sean-","html_url":"https://github.com/sean-","followers_url":"https://api.github.com/users/sean-/followers","following_url":"https://api.github.com/users/sean-/following{/other_user}","gists_url":"https://api.github.com/users/sean-/gists{/gist_id}","starred_url":"https://api.github.com/users/sean-/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sean-/subscriptions","organizations_url":"https://api.github.com/users/sean-/orgs","repos_url":"https://api.github.com/users/sean-/repos","events_url":"https://api.github.com/users/sean-/events{/privacy}","received_events_url":"https://api.github.com/users/sean-/received_events","type":"User","site_admin":false},"assignees":[{"login":"sean-","id":349516,"avatar_url":"https://avatars1.githubusercontent.com/u/349516?v=4","gravatar_id":"","url":"https://api.github.com/users/sean-","html_url":"https://github.com/sean-","followers_url":"https://api.github.com/users/sean-/followers","following_url":"https://api.github.com/users/sean-/following{/other_user}","gists_url":"https://api.github.com/users/sean-/gists{/gist_id}","starred_url":"https://api.github.com/users/sean-/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sean-/subscriptions","organizations_url":"https://api.github.com/users/sean-/orgs","repos_url":"https://api.github.com/users/sean-/repos","events_url":"https://api.github.com/users/sean-/events{/privacy}","received_events_url":"https://api.github.com/users/sean-/received_events","type":"User","site_admin":false}],"milestone":null,"comments":20,"created_at":"2017-08-01T18:38:55Z","updated_at":"2017-08-07T23:09:33Z","closed_at":null,"body":"For discussion of [RFD 106: Engineering Guide: Golang Best Practices](https://github.com/joyent/rfd/blob/master/rfd/0106/README.adoc)"},"comment":{"url":"https://api.github.com/repos/joyent/rfd/issues/comments/320804940","html_url":"https://github.com/joyent/rfd/issues/45#issuecomment-320804940","issue_url":"https://api.github.com/repos/joyent/rfd/issues/45","id":320804940,"user":{"login":"sean-","id":349516,"avatar_url":"https://avatars1.githubusercontent.com/u/349516?v=4","gravatar_id":"","url":"https://api.github.com/users/sean-","html_url":"https://github.com/sean-","followers_url":"https://api.github.com/users/sean-/followers","following_url":"https://api.github.com/users/sean-/following{/other_user}","gists_url":"https://api.github.com/users/sean-/gists{/gist_id}","starred_url":"https://api.github.com/users/sean-/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sean-/subscriptions","organizations_url":"https://api.github.com/users/sean-/orgs","repos_url":"https://api.github.com/users/sean-/repos","events_url":"https://api.github.com/users/sean-/events{/privacy}","received_events_url":"https://api.github.com/users/sean-/received_events","type":"User","site_admin":false},"created_at":"2017-08-07T23:09:33Z","updated_at":"2017-08-07T23:09:33Z","body":"On Aug 4, 2017, 8:04 AM -0700, cburroughs <notifications@github.com>, wrote:\n\n> Thanks for continuing to move this forward Sean. I think you have (inadvertently!) managed to fall on several process growing pains around sync-vs-asyn communication, remote timezones, where does the D in RFD happen, where documentation lives, and which current engineering practices are actually universal. This is all ultimately necessary to bring forward even if it has made for choppy waters for the HMS Golang.\nAs I said last week: some people want to do interactive chat (video), other people want to do offline.  There is no way to make 100% of people happy in this regard.\n> Do you know what the first projects using golang are likely to be?\nThere are a number of candidates and items we're considering incorporating into Triton.\n> I think it would be helpful to have some idea of what things we will learn first For example:\n>\n> • A project that includes people who no previous go experience would teach us the most about how big a problem crazy looking things like GOPATH actually are.\n> • A project that is a core service would need to carefully conform to the existing ecosystem.\n> • SKDs, or other code for external consummation would help us understand how we need to manage runtime upgrade expectations and managing which interfaces are committed for external consumption.\n>\n> We will get to all of them eventually, but I'd like to know which points of contention will continue to be abstract, and which might soon have some concrete experience to report.\nYup.  The genesis of the recommendation was that we would start in a monorepo and decompose that repository as necessary and fan out where required.  My estimation is that it's easier to break things out than to fan repositories in.\n> > vendor/ Management\n> I am still unsure if this doc is advocating checking 3rdparty dependencies in as source.\nI had a takeaway from Friday to explicitly note that it is explicitly advocating for this.\n> > \"Thread Worker Pools\"\n> Could you briefly elaborate on what this topic is? One concern I have about Go is choosing yet another language (after node) where \"use normal OS threads\" is not an available solution to problems.\nhttps://rakyll.org/scheduler/\n\nTL;DR: go routines are cheap, use 'em, and set an upper bound on the number of system threads by explicitly setting GOMAXPROCS.\n\nI remember FreeBSD and even Sun experimented with M:N threading models and abandoned them.  Go uses that model and it appears to work reasonably well in practice.  Anecdotal evidence (I forget where I picked the sup, but it was from someone at Google) suggests that having hundreds of thousands of goroutines is reasonable.\n\nOne place where things get complicated is the number of OS-level threads, setting GOMAXPROCS, and CPU resource constraints.  In particular this is problematic in smaller zones because smaller Zones detect all available cores.  The effect of this is that from a resource utilization perspective, a process doesn't actually have access to all of that compute time.  To effectively deal with that, smaller packages need smaller values of GOMAXPROCS and defaulting to the number of detected cores can be a poor default for Infrastructure VMs.  I don't have a hard and fast rule for this yet, but I'm using GOMAXPROCS=4 as my default value in my SMF startup scripts and scaling it up if necessary.\n\nhttps://blog.golang.org/pipelines\nhttps://blog.golang.org/advanced-go-concurrency-patterns\nhttps://blog.golang.org/concurrency-is-not-parallelism\nhttps://blog.golang.org/go-concurrency-patterns-timing-out-and\n> > Tools similar to bazel could\n> As someone not coming from a Go background, in my experiments I found that a pants/bazel-like like tool alleviated most of the GOPATH/vendor/deps crazyness. I felt like I was using a normal civilized language.\nMy boost.build, cmake, autoconf, scons, GNU Make, pmake, tup, and go build self was rather pleased with bazel and am secretly looking forward to a world where that tool is rewritten in Go so that I can sidestep the use of a JVM as a build tool (a build-time tool that I'm extremely reluctant to grow a hard dependency on).  And to be clear, inclusion of bazel in the foot note of this RFD was to make a point, not to hint that its even on the radar for something we're considering.  These are not the tealeaves you are looking for.\n>\n> • > My understanding is that in the Go ecosystem, source based deps are typically (exclusively?) used. How do we identity to 3rd parties which code of ours represents a committed stable interface?\n>\nCorrect.  There ... hrm.  I'm not finding it right now.  There is a linter that warns when the signature of exported functions changes.  Right now, and the conventional way of testing this, is to test the surface area of the exported interface via a `_test` package.\n\nFor example:\n\n```go\npackage foo\n\nfunc Bar() {```}\n```\n\nWould have a public interface test:\n\n```go\npackage foo_test\n\nfunc TestBar(t *testing.T) { ... }\n```\n\nAnd use that to test that the exported API is meeting the testable contract.  Where necessary, `rdeps` or other reverse dependency tools can be used to figure out who else implements a given package.  For instance: https://godoc.org/github.com/pkg/errors?importers\n>\n> • Is there a path forward to accommodate closed source Go code? A particular interest I have is in internal tooling and \"glue\" code (stuff I am otherwise doing in Python), for which neither bash nor node are ideal.\n>\nI am rather fond of Godo: https://github.com/go-godo/godo for the one-off odd-job that doesn't quite warrant becoming a full-fledged CLI utility.\n>\n> • > As discussed in the last call, elaboration on how gRPC and provising http+json endpoints are not exclusive would help clarify that section.\n>\nYup, it'll show up at some point.\n"}}
{"actor":{"display_login":"sean-"}}