It’s interesting to me since it doesn’t seem that they have a “v2+ problem” but probably more of a messaging problem.
You are on your own to piece together how SIV works via the myriad of blog posts, wiki pages, and Github issues. The information being spread all over the place doesn’t help anyone get comfortable with the concepts. I’ve gone so far as to write an internal wiki for all go teams in my org that is simplified and answers most questions about modules plainly.
The other part of the “messaging” problem was the journey just to get to modules. Google and the go team let the “community will sort out dependencies” experiment go on for way too long. They compounded this with the fact that we went from a “blessed” solution in dep to what I’ll call a paradigm shift with modules.
So, some mistakes to learn from and areas for investment but nothing that is absolutely a deal break (at least to me).
As an aside, we are working on some proposals to help with deprecation / alerting to newer major versions. Would love any comments or feedback!
… let’s go shopping!
Ironically Go looks like one of the few languages on this list that succeed.
Go does have an easier time because of it’s lack of generics and limited inference, which makes type checking (and inference) pretty simple.
Of course this may change completely with the Go Generics design draft. From their descriptions it seems to be similar to the simplicity of the old inference algorithm, only inferring function types when all type variables occur in the function argument.
I really want to know how this will be impacted by Go generics!
Me too! I haven’t found any information on the (planned) implementation of Go’s generics though (it vaguely alluded to HM’s algorithm W), so we will have to see how it plays out.
Edit: It looks like the current draft has plans of keeping it simple with a 2-pass unification algorithm in restricted contexts.
What do you mean by “succeed?” The piece doesn’t talk about success or failure in any meaningful sense as far as I can tell.
One thing I wanted to call out - you no longer need to use an external package (github.com/pkg/errors) to get error wrapping.
If you want to read more about this they discussed it here: https://blog.golang.org/go1.13-errors
Was happy to see the stdlib introduce error wrapping. I continue to be impressed with the slow evolution of the language and introduction of features like this.
I am in this and actually really loving it. I turned off all my github email notifications and now just going through the mobile app. You also get access to their new notifications UI on the web if you get into the mobile beta. That has also been pretty incredible to use. Nice work from the teams that did both features.
I love LSP for go development but I am really not a fan of having to install JS and dependencies like yarn just to get coc.vim. I much prefer https://github.com/autozimu/LanguageClient-neovim along with some tweaks to get the LSP support. I really need to put my .vimrc up somewhere so I can link to it.
I agree this is a real problem. If I have to pull in the world to run your plugin I’ll pass.
Saw Spark mentioned once but I am using it on both iOS and MacOS. I’ve found that the smart inbox and pinning work really well for the way I like to manage my email. Haven’t really used any of the other functionality but group editing of an email sounds interesting. Does have calendar integration as well.
I’m using 1Password with local sync over the built-in web server. 1Passwords also supports syncing via Dropbox, iCloud and, most recently, 1Passwords’s own servers. I want nothing of that but it means that I can’t use 1Password on Linux. What’s great about 1Password is that it is highly polished - using it adds very little friction. I understand that I could manage all passwords encrypted in Git but the integration would never be as good and there is a lot of risk that this would somehow not be as secure as it sounds.
I recently switched to Enpass, which is a conceptual clone of 1Password. Reason for switching was Linux support.
This is a closed-source app that has not yet received a lot of scrutiny. Using it for truly sensitive information requires quite a bit of trust. They claim to use sqlite with encryption – which I would trust but of course, there is a lot of code around it that would have to be trusted as well.
The first thing it tried to do when I ran it was reach out to Google Analytics. I said enough of that, and promptly uninstalled it.
1Password (at least the hosted version) has linux support via both 1password-x and 1password-cli. I quite enjoy the CLI and generally find that it has a better user experience than LastPass.