Re: [go-nuts] Go Styleguide
On Mon, Jul 31, 2017, at 07:39, ha...@arne.me wrote: > Hey, I just released a Go Styleguide[1], please let me know what you think! This is great! Going to focus on criticisms because they have the most value, but I really think it is excellent. - Feels more like a best practices than a style guide - Recommending specific non-stdlib packages in a guide like this tends to age very poorly and put people off it who don't like zap, testify or gometalinter, I would stick to stdlib and built in stuff -- maybe have an addendum or separate document about currently best tools you recommend. - Don't under-package. I disagree with this one, as I think premature splitting of packages often causes FAR more pain. I would at a very least like to see more justification for this one. - Use Makefile if necessary. I would make it more generic, to use external scripted build system. But I am not sure this belongs in the document at all, it is picking a tool and I often find it (make) is not good style or a best practice for a cross platform language like Go. - Use internal packages. This is something that has recently been annoying me about various go libraries, some key functionality being tucked away out of an abundance of caution. I am not sure this should be a good starting point. Like under-packaging, this is something where I think far more harm comes prematurely deciding something should be internal. I disagree with this recommendation. - Go-bindata ... another specific tool recommendation I would remove, it also tends to make the dev cycle more complex and has lots of competition. I have had this specific tool cause lots of confusion among neophyte gophers. The rest of it I by and large think is spot on -- I hope you continue to work on it. -- Robert Melton | rmel...@gmail.com Links: 1. https://github.com/bahlo/go-styleguide -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: Generics are overrated.
On Sat, Jul 29, 2017, at 13:33, dogan.k...@dodobyte.com wrote: >> Also, building a basic one yourself if you don't want to use those tends to >> be exceptionally straightforward. > > Thanks for examples, i can't tell if they are experimental or viable for > production use. I am not sure the case where a code generation tool would be "experimental", as they aren't in most cases that clever, they are mostly just saving typing time. Some of the ones listed are more clever than others -- but I would consider them all "production" ready in so much that they can output code you can use in production. > But if it's that straightforward, why people complain about it too much. I believe a part of it is tool anxiety. You have to pick a tool, learn it, vendor it, and train others on it and hope it is maintained / improved going forward. When this tool is not a blessed part of the language it often causes stress for people. That said, I use a lot of console tools with Go in my day to day development (over a dozen no less) -- so I feel a tool for generating variations fits very well with the Go ethos. -- Robert Melton | rmel...@gmail.com -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Generics are overrated.
My primary concern about generics is they may significantly hurt build times, which coming from C++ I am rather sensitive about. Beyond that I am worried that they might end up NOT being an improvement over all the tools that have already popped up to handle this problem. There are a lot of ways to generate code for Go already that can be run once and checked into your source repo. Regenerated if you need to support a new type or fix a bug. This is very reasonable and rational IMHO. I have yet to have a significant issue with this approach, outside of tooling phobia. Even in languages with prolific template support, I have often ended up eschewing them for better, external text processing tools. I think Mike Acton has something useful to add to the conversation about avoiding templates in C++: https://youtu.be/rX0ItVEVjHc?t=1h11m19s Questioner: ...you're against templates... how do you deal with code duplication?... Mike Acton: ... templates, how do you remove code duplication? One, it is almost certainly not as big a problem as people think it is. They invent things to duplicate so they can invent templates to solve the problem. But in the cases where it is potentially useful you can also generate the code. A template is just a poor man's text processing tool, we have tons of stuff that processes text, you can actually do a really great job with some other tool that does it better. You don't need templates in order to solve that problem... /mytwocents -- Robert Melton | rmel...@gmail.com -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Using Go in a locked down SOC2 environment (dependency management hell)
Jacek-- In a similar setup (must be able to build without internet access) we simply used glide on the developer machines, then used https://github.com/Masterminds/rmvcsdir to remove vcs stuff and commit full deps to our local version control -- then all that is needed to build is to clone it and build it, no other steps, no checking the internet for anything. It also gives you fully reproducible builds. Glide still worked for like glide up because it used the glide.yaml I believe. On Fri, Jan 6, 2017, at 11:35, Jacek Furmankiewicz wrote: > Hi everyone, > > We are operating in a SOC2 environment, which our customers demanded > as we host their systems and their data. > It's a common requirement for many companies in a cloud environment. > > One of the key requirements of SOC2 is that *all* external > libraries/depdencies are mirrored internally and *NOT *fetched directly from public Internet during the code building process. > > With our Java apps, this is simple. We have an internal Artifactory > instance and we mirror all the Java libraries from the Maven Central > repository there > (after each and every one of them goes through legal license review, > to exclude GPL, etc). > > All of our build servers are locked down and cannot reach public > Internet, only our local library mirror. > All of our Gradle build scripts are locked down to allow fetching > dependencies from our local Maven mirror only. > > As you can imagine, this is anathema to how entire dependency > management works in Go (and all the related tools, like go get, etc). > > Even if we mirrored Go git repos for the libraries we want in our > internal Stash repository, > pretty much all the current Go build tools (e,g. Glide) would still go > to the public internet to look for dependencies of any library. > > e.g.: > > https://github.com/Masterminds/glide/issues/729 > > > Just wanted to hear if there are any Go shops out there that operate > in a SOC2 environment and what combination of tools / procedures do > you use. > > We are very interested in Go adoption for some of our real-time server- > side applications, but the way dependency management works in Go > is a total showstopper due to the stringent security requirements > of SOC2. > > I would greatly appreciate any input, comments, suggestions from the > Go community. > > Much appreciated > Jacek > > -- > You received this message because you are subscribed to the Google > Groups "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, > send an email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Robert Melton | rmel...@fastmail.com -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Deleting the /r/golang subreddit
I think it is worth taking a moments pause and remember that community is over 25,000+ gophers. Those are just subscribed users, excludes just people passing through or who don't formally subscribe (RSS or other means). I absolutely agree you shouldn't have to maintain something you have a moral stance against. Additionally if the core Go team thinks it shouldn't be an official place, by all means, eject it form the go community space. That said, the idea of intentionally squatting on a namespace to kill off a community of 25,000+ gophers feels -- gross. It feels vindictive not to the CEO of Reddit, but to the 25,000 gophers. Additional, I suspect it will be ineffective. A new subreddit will popup and rebuild /r/golang2 or /r/goproglang or whatever. If you want to stop maintaining it -- at least at this point you could hand it off to some experienced reddit users who could continue to try to make it a worthwhile place and show respect (even in disagreement) to those gophers who happen to like a place that you may not. On Thu, Nov 24, 2016, at 18:53, Brad Fitzpatrick wrote: > In light of the CEO of Reddit admitting to editing user comments (see > dozen news stories today), I propose we delete the /r/golang > subreddit. > > That is so beyond unethical and immature, I no longer want anything to > do with that site. I will be deleting my account on Reddit after > backing up my content, and I will no longer be a moderator of > /r/golang. > > If other moderators of /r/golang feel strongly that it should remain, > I suppose you're welcome to keep it going. > > But if the other moderators want to abandon it and focus our > conversation elsewhere (or build a replacement), I'm happy to just > delete /r/golang. > > Opinions? > > > -- > You received this message because you are subscribed to the Google > Groups "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Robert Melton | rmel...@gmail.com -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
