vgo and the Onus of ‘A Technical Solution to All Possible Scenarios’ – InApps Technology is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn vgo and the Onus of ‘A Technical Solution to All Possible Scenarios’ – InApps Technology in today’s post !
Read more about vgo and the Onus of ‘A Technical Solution to All Possible Scenarios’ – InApps Technology at Wikipedia
The vgo package versioning for Go was first proposed a few months back and this week that proposal was accepted — though not without commentary and debate along the way.
There’s little else on the internet like the debate around a change in a popular programming language. Take a whole slew of people whose job and overall tendency it is to find the myriad ways some technical change affects things, and your discussion is likely to go deep and in all directions quickly. The debate around vgo is no exception.
When @jessfraz added the default Seccomp profile to Docker she tested every Dockerfile on GitHub to make sure she didn’t break things. When #golang vgo was accepted it required people to change things and many people who tried had issues.
I prefer Jess style
— Matt Farina (@mattfarina) May 23, 2018
Of course, this debate is also an example of the struggle that can arise between the community that surrounds an open source project such as Golang and the company and team that directly backs it. For your perusal, see “Go: From Godep To vgo, A Commentated History,” wherein one point of view on the struggle around versioning in Go is offered, and then plays out in detail in the comments, with Golang team member Russ Cox offering his own version of events.
Even in the debate and retelling of the events leading up to a new versioning system, the versions of events are as debated as the versions of packages that may or may not break your code in the near to distant future.
Either way, the language in the vgo notice of acceptance was rather interesting. The community’s objections to vgo were that “the proposal will require people to change some of their practices around using and releasing libraries” and that “the proposal fails to provide a technical solution to all possible scenarios that might arise involving incompatibilities.”
It is exactly this idea of providing a technical solution to all possible scenarios that really struck me. This is something, as programmers, that I think we’re always in search of, but I wonder if it is something we are always able to find. From my outsider’s perspective, I found this interesting, because it reads like a concession that the proposal wasn’t perfect, but rather a better way forward nonetheless, with some issues that would need to be ironed out during “the accompanying implementation rather than the proposal.” Of course, that’s not the way many people are reading this.
I’m saddened by this today. Tech details aside there are social ones. I feel like the Go team is saying “we only trust members of the Go team for the hard problems, and the community can pound sand.” Valid position, vgo may be good, but not a good look. #golang https://t.co/FCvD4TSWwr
— Barak Michener (@barakmich) May 22, 2018
“Authors and users of code will have to change some of their practices around using and releasing libraries,” the proposal acceptance reads, “just as developers have adapted to other details of Go, such as running gofmt. Shifting best practices is sometimes the right solution.”
I’m so vocal about this issue because it’s important. What’s worse is when people try to explain the problems we’re told is us. That our use cases are wrong. That we need to work differently. Part of that is fine, but it’s the Wild West out there. Stuff needs to work now. 3/
— Mark Bates (@markbates) May 22, 2018
In the history of open source projects and the various battles that swirl around them, I can only help but wonder the last time a long debate such as this ended in agreement. Has one ever? What is the fine line that needs to be drawn between working with the community and finally putting an end to debate and saying “this is the way forward?”
In the end, reactions run the gamut, from “this was surprisingly painless” to “this will break absolutely everything!” Where do you stand, dear Golang contributor? Go developer? Does flexibility need to be found further in the structure of the proposed vgo versioning or in the people implementing and using it?
And with that, we can look at some of the news and thoughts in the world of programming from the week past, starting with a quick one around vgo integration in the GoLand IDE.
This Week in Programming
- GoLand Supports vgo: The proverbial ink is not dry on the acceptance of the vgo versioning system, but the GoLand IDE by JetBrains is ready to support it nonetheless. “Package management has long been a topic of interest for many people in the Go community,” the announcement understates. “Today we are happy to announce the first version [of] this integration is available as a plugin for GoLand 2018.1.2+.”
- GitHub Desktop 1.2: The latest dot release of GitHub Desktop now works to “help you stay up-to-date with your coworkers’ changes and keep you in sync with your team.” The newest features include the ability to compare branches and select multiple files, which means you can “compare your branch to any other branch in the repository, like your master or base branch, and merge that work into your current branch.” As for multiple file selection, “now you can select multiple files to perform an action on by holding down Shift or Command/Ctrl and clicking on the files you want selected.”
- Slack Adds Actions & Other Dev Tools: Slack held its Spec developer conference last week and, according to SD Times, offered developers new ways to work with “new tools developers can add into their existing workflow,” including Actions, “a new way to provide deeper integrations with development tools and the Slack collaboration solution.” Basically, “with Actions, developers can turn messages into tasks, comments, or follow-ups as well as attach messages to tickets.” Beyond Actions, Slack also announced Block Kit, a new UI kit for developers that will “provide standard designs for things like date pickers, task objects, overflow menus, and more, to make apps both more powerful and easier to use.”
- Concerning Learning Kotlin: Two quick tidbits on those of you learning or looking to learn Kotlin, the Google-endorsed language for developing Android apps. First, Google announced this week a free, self-paced Kotlin Bootcamp Udacity course. The course covers the basics, like writing Kotlin statements and expressions. It also goes into writing functions and classes, and goes beyond the basics into pairs, collections and constants, and more. And for those of you already writing Kotlin, you might take a quick read of this blog post on lessons learned after six months of Kotlin development on the Karumi blog, which offers their “opinion on the state of the art.”
- Learning Machine Learning: While we’re talking about learning, there’s also this post on TechCrunch about Google and Coursera’s launch of a new machine learning specialization. This is not a first for the two companies, but rather builds on previous efforts, including the Machine Learning Crash Course, “which provides developers with an introduction to machine learning.” This machine learning specialization, called “Machine Learning with TensorFlow on Google Cloud Platform,” consists of five courses that take students “from setting up their environment to learning how to create and sanitize datasets to writing distributed models in TensorFlow, improving the accuracy of those models and tuning them to find the right parameters.”
Dear Jr, Developers,
EVERY Sr. Developer you know and admire for what they know or can do has spent time this week staring blankly at code and screaming in their head “WHY DOESN’T THIS WORK?”
It’s not just you. 🙂
— Uncle Cal (@CalEvans) May 22, 2018
- Open Source in Proprietary Apps: In a Black Duck survey that may or may not surprise you, an article this week finds that the percentage of open source code in proprietary apps is rising, with “96 percent of the scanned applications contain[ing] open source components, with an average 257 components per application.” According to the report, “the average percentage of open source in the codebases of the applications scanned grew from 36 percent last year to 57 percent, suggesting that a large number of applications now contain much more open source than proprietary code.”
- On Maintaining Microsoft Notepad: Many of you have been surprised by Microsoft’s recent announcement that Notepad now supports Linux line breaks. Indeed, in another blog post on the antiquated text editor, Microsoft this week writes that maintaining Notepad is not a full-time job, but it’s not an empty job either, noting that “Notepad is a common guinea pig.” It’s worth a read.
- In The Seeming Defense of PHP: This one is for those of you out there who love to bash PHP. In a blog post titled “PHP allows for the design of X”, PHP developer Joe Watkins takes on an old adage and some of the common arguments (such as “but PHP was designed as a templating language”) against using PHP. “Almost every extension I write gets the same sort of response: ‘Just because you can, doesn’t mean you should’. What they are communicating is ‘It doesn’t matter if you can, you shouldn’t’, which is somewhere between silly, and harmful. It really does matter if you can.” Read on for further reasons that PHP isn’t the things you simply say it is.
- F**k Off As a Service: Finally, this week, we leave you with a truly useful piece of As-A-Service. Just click.
#GDPR: Do you wish to continue receiving emails from us? (Subscribers who do NOT wish to receive further emails from us will be sent death certificates which they should complete and return to us. Please leave the Cause of Death blank; we’ve made all the arrangements).
— Scarfolk Council (@Scarfolk) May 24, 2018
Feature image via Pixabay.
InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.