sseth

As Russ points out, the current approach of pulling the latest leads to a situation where a package managers can be quite sloppy. For example, a package may have a stated dependency A@1.1.2. But because everyone is pulling the latest, it may turn out that the package actually no longer works with that version of A anymore.

The vgo approach will encourage package managers to update their dependency versions to what they have actually tested with, which is very useful information for consumers of the package.

I believe (having tried the tour) that you will get v1.4.5 at the App level, if you do vgo get -u.

If you just do plain vgo get, you will get 1.3.4, because of the minimum version approach.

Interesting. You would think the case of Alex Kibkalo would lead to the opposite conclusion. Microsoft prosecuted a blogger for piracy of Windows software after reading his private hotmail emails.

Ryan Dahl wanted to replicate the nginx "async" model for normal web development. Since javascript was single-threaded, it pretty much forced an asynchronous programming model and many of the libraries were already built that way, so it proved to be a fertile ground for experimentation.

In other words, we have node.js and not node.xxx because other languages at that time did not provide a suitable ecosystem for building asynchronous programs. Today most languages have much better async support, or they have features (like goroutines in golang) which achieve the same objective in a different way.

The case I was responding to was one of car breakdown. Of course the other case would be an emergency while the car is moving (which is what you are talking of) and here i think the evidence is compelling. To hand over control to a distracted driver at the worst possible moment is not likely to work well. It actually does not work well even for trained pilots, as the Air France crash some years ago showed.

I think the point is the car has to be able to drive completely independently if we are to allow cars to travel without anybody inside at all, which includes handling emergency situations. And of course as some others have pointed out the people inside may be old, handicapped, children etc - expecting them to take control may make things worse.

As far as front seats are concerned, why even have a front seat? Have people sit in a circle facing each other, with a table in the middle - so you can have a conversation. Not having a wheel allows us to reimagine the interiors of cars which are currently built around the driver.

On point 3 : The fact that the (original) Gutenberg is in germany is irrelevant. Gutenberg here refers to the Gutenberg bible, not the place.

And in any case are we now assigning global trademark rights to cities / countries for names used in their jurisdiction? To give an example, Budweiser would be subject to Czech jurisdiction, since it is named after a Czech town. This is not much of an argument.

In Chrome today, as an example, the C++ based DOM and V8 (Javascript ) objects are using different GCs. Obviously it is a pain point, but the situation of having different GCs for DOM and language objects is not new with Web Assembly.

Google apps (now GSuite) has had offline functionality for several years. You can work on Sheets, Docs etc completely offline.

It also lost call-by-name parameters, which should be a considered a good thing.

One approach may be to tokenize user information. Ensure that any personal data is separated from other data and mapped via tokens and kept in one place. Handle backups of this database with special care.

You can then have the rest of your systems work as normal.

All this is easier said than done if you have a large investment in existing systems, but it is probably a design approach you can enforce from the beginning if you are a startup.

The performance difference for one thing - this comes not only from not using javascript, but also from the fact that there is no DOM to update and has been designed from the beginning to maximize use of the GPU.

As a javascript library it is pretty much as open as React or any other javascript platform.

It is the caching where the discussion lies - effectively Google is providing a CDN for AMP pages and I agree this needs some improvements. But these should in the realm of technical discussions rather than looking for conspiracies.

AMP at the end of the day is an open source javascript library. The pages accessible on AMP via the cache, can also be accessed directly if you want. I don't see this as a walled garden - having a cache does not mean the content is not available outside the cache.

Google does not do this out of altruism of course - their margins on web search are much higher than on mobile, and if more and more content exists only in mobile apps and walled gardens they will lose revenue.

AMP is one of a long series of Google's efforts to ensure the web remains competitive with walled gardens and native platforms. Chrome (with the V8 engine), NaCl, SPDY, QUIC, PWA, Dart, Certificate Transparency ... the list goes on and on. Some have succeeded (SPDY became HTTP/2) and some have failed (Dart, NaCl), but it has been consistent at least.

Standards cannot become a strait-jacket. In many cases (such as HTTP/2) the standards have come much after the concept was proven. Though Dart and NaCl failed, they triggered improvements in Javascript and also led to WebAssembly.

AMP was created as a response to Facebook's Instant Articles. If anyone supports the open web, then it is hard to see how things become better if the web stays stuck as more content moves into walled gardens, or the web remains unusable on mobile phones in large parts of the world.

Maybe there is no controversy, because there is no need for one.

Note that even currently, lockfiles have the effect of locking you to an old version of the software. You could choose to automatically update all dependencies to latest in CI, but then by that token you can run vgo get -u, to get the latest versions here as well.

One of the issues which the vgo developers point out is that the "latest" behaviour has the perverse effect that a module A may declare a dependency of version 1.1 of a module B, and may have never been even tested on that version because the package manager always picked the latest.

In some sense, the vgo approach is saying that across hierarchy of module owners, each one should keep upgrading their manifest to the latest versions of their direct dependencies, and ensure that things keep working, rather than relying on the topmost module to pull in the latest of the entire tree of dependencies. This seems to be good for the entire ecosystem.

Done. https://github.com/golang/go/issues/24042

Not sure if i did it right, since the default template seems to be for a bug and not a new feature request.

I believe this will get the latest of all the dependencies, not just the direct ones. If my module A depends on B and C, which both in turn depend on D, i want the latest of B and C only, and then transitively pull in the minimal version D compatible with B and C.

edit : I can of course do it one by one explicitly for B and C. But it would be nice to qualify e.g. : vgo get -u -directonly

The minimal version selection addresses a problem that other package managers do not seem to : For transitive dependencies, it allows projects to use the version that direct dependency was actually tested with. This sounds like a good thing to have.

What would be nice would be a command to upgrade to latest of the direct dependencies - and then transitively pull in the latest version of packages they have been tested with.

We age for the same reason that code bases go bad over time - the accumulated cruft of tech debt overwhelms the ability of different parts of the system to work together well. This is a problem of any dynamic system, not something related to physics.

Of the IT giants, Google has the most to lose from a closed web. The rise of mobile apps and walled gardens is a direct threat to their search business model. So the argument that Google would threaten the open web seems strange, on purely selfish grounds.

AMP seems to be an attempt to keep the web relevant. In countries like India (where i live), most new users access the web via the mobile, and the experience can be far worse than in the west, and absent of initiatives such as AMP you will see a fall off in web usage in general. I am not sure how that helps the open web.

There are many threats to the open web. For example, governments building firewalls. Lot of content locked up in walled gardens. The death of net neutrality.

Definitely one of the threats to the open web would be the web platform falling behind "native" platforms such as mobile platforms. 10 years ago it seemed that native apps are dead, the web is going to win. And then the rise of smartphones has brought us back to a world where we are forever installing native applications. From what i can see, attempts to make the web faster (SPDY, AMP), safer (Certificate Transparency), more open (AV1) are all initiatives i can get behind. The question is : What are other companies doing to ensure the web retains its place as the premier open content / application development platform.

There are definitely more indian men than women in IT, by a big margin. But to take an example, Google currently has about 18-20% women in technical roles, i.e. 1 in 5. So assuming more than 1 in 5 immigrants in Google were women, you cannot argue that immigrants are the cause of the low ratio of women in Google. What we need to answer this question is the ratio of women among immigrants vs the overall ratio, something i could not get data on.

The picture becomes more complicated when you consider a hierarchy of packages, because presumably the packages you depend on would have their own lock files, which represent the versions those packages have been tested with.

npm will pick the latest version of the dependencies compatible with the package.json of the packages (package-lock.json, is not published as part of the package). This means that with npm we may end up using a version of a transitive dependency which is much later than than the one that your direct dependency was tested with.

The proposal for vgo will take the minimum version compatible with the packages, and hence pick a version which is closer to the actually tested one.

The implication or this post is that the ratio of women among immigrants was lower than the indigenous population, and thus the influx of immigrants drove down the percentage of women in tech. I am not aware of other countries, but in India at least we have a higher percentage of women in IT than in the USA. So is it really true that female representation among these immigrants is lower than the indigenous population, as this post seems to imply?

When code quality is hard to enforce, one approach is to at least ensure that the design of public APIs, and boundaries between components reaches some level of quality. This is usually a smaller surface to monitor than the entire code base, and it allows islands of good quality to emerge. Good boundaries also will allow for easier refactoring over time of the really bad code.

It does not have to be violating your privacy. In India, we have IMPS as the immediate payment system. On top of this, the central bank has built UPI - which allows mobile numbers for payments. But it also allows the use of "dummy" or "virtual" ids which can be used to mask your identity from the payer. There is no reason why this cannot be done in Australia also.

The use of mobile numbers to instantly transfer money is using UPI, a system built on top of IMPS. UPI is actually just an API. Third-party apps provide payment features on top of UPI.

There are companies which have patented drugs in India, but do not make their drugs available in India. The Indian Patent Law allows for compulsory licensing of such drugs to another manufacturer under certain conditions which meet public interest. This is not a free for all - there are significant legal tests that the manufacturer has to meet to get the CL, and i think only one or two cases have been granted. This provision of indian IPR laws has led to having India being put on an IP watchlist in the USA, though India's laws are compliant with the TRIPS agreement.

I think the strategy is to make Flutter an attractive tool to build mobile apps across Android, iOS and Fuchsia (it already runs on all three today). Even in an alpha stage, it is a really productive framework for mobile development.

So if Flutter hits 1.0 or beta sometime next year, you would have a way to develop mobile apps for today's platform which will require a smaller investment to run on an eventual Fuchsia platform.