Also, in many EU states, companies contribute to social security. In some this is indexed to profits, but on others this is indexed directly to wages, so if you count that bit, taxes directly attributable to your income can easily exceed 60% of what a company pays out.

I don't know if Belgium is using that loophole when counting the 60%, though.

I have no idea about this. Can you explain what you mean and give some examples of such countries ?

>Also, in many EU states, companies contribute to social security. In some this is indexed to profits, but on others this is indexed into wages, so if you count that bit, taxes directly attributable to your income can easily exceed 60% of what a company pays out.

True. Some EU countries also tax the gross salary the employer has to give you before it gets to you, which is in bad faith not included in payslips. So when you negotiate your 60k gross wage, it's actually costing your employer something like 72k Euros. I hate this shady practice.

Their inward FDI stock to GDP ratio is around 250%, which is about 4× the EU average; and Ireland does this with a decently sized economy.

And then there's Luxembourg (1400%) and Malta (2000%) which arguably do much “worse” but are comparatively tiny.

I didn't do the math for every EU country. Those were just some of the few that came to mind. For instance, Cyprus has similar values to Ireland, but the Irish economy is 15× bigger.

When there's a lot of foreign money going through your economy and you can tax it to moderate amounts, you get to offer lower rates to your own citizens.

Which is great, but obviously doesn't scale if every country tries to do the same.

Probably countries like Ireland, Montenegro, Belize, etc which act as tax havens for foreign corporations. Or Singapore, while also a tax haven, acts as a center for regional trade.

They could also mean resource rich countries that sell mineral rights to foreign corporations, who made investments in infrastructure in order to facilitate their operations, and they pay back dividends to the state, which offset the tax burden of the local population.

But many would find them wasteful, and a terrible place to live, compared to a decently sized apartment (one 10m² - 100 sq ft - bedroom per person/couple and maybe an extra office) in a walkable town.

Just as we find american SUVs totally inadequate compared to our cars.

And it's not matter of cost, we're perfectly “happy” paying borrowing millions of euro for such apartments, and paying far more for our cars.

It's been popular demand, not financial institutions, driving the change to “the smartphone can do everything, I don't want to take debit/credit cards with me everywhere.”

People don't want an additional card, or yubi key, or printed second factor, or whatever, to authenticate.

They want an app that uses a data connection, and a fingerprint to replace even needed a PIN. They tolerate a second channel: an SMS, if the app automatically reads it. That's as much inconvenience as the general public is willing to put up with.

They're starting to demand that this works offline for smaller spends. And they'll put up with a phone call as a 3rd factor for when they want to unblock a really high spend, like purchasing a car, but it can't happen all the time.

They want this to work reliably, even on holidays, all around the world. And they want the banks to cover losses if it all goes south.

Now try to design a system that covers the requirements people are demanding for, without trusting the terminal the people decided they want to access it from.

For the question “is the data in the checksum database immutable” you can trust people like the parent, who double checks what Google is doing.

For the question “is it the same data that can be downloaded directly from the repos” you can skip the proxy to download dependencies, then do it again with the proxy, and compare.

So I'd say you don't need to trust Google at all in this case.

You run that when you've made manual changes (to go.mod or to your Go code), or when you want to slim down your go.sum to the bare minimum needed for the current go.mod.

And that's one common way to update a dependency: you can edit your go.mod manually. But there are also commands to update dependencies one by one.

No?

All dependencies - direct and indirect - are listed in your go.mod. Your module - as is - depends on nothing else. And those exact versions will be used to build it, if yours is the main module.

If your module is used as a dependency of another module, then yes, your module may be built with a newer version of those dependencies. But that version will be listed in that module's go.mod.

There's no way to use different versions without them being listed in some go.mod.

go.sum to only maps between versions and hashes, and may contain hashes for multiple versions of modules.

If you wanted to verify the contents of a dependency, you would want to check go.sum. That's what it is there for, after all. So if you wanted to fetch the dependencies, then you would want to use it to verify hashes.

If all you care about the is the versions of dependencies, you really can (and should) trust go.mod alone. You can do this because there are multiple overlapping mechanisms that all ensure that a tag is immutable once it is used:

- The Go CLI tools will of course use the go.sum file to validate that a given published version of a module can never change (at least since it was depended on, but it also is complementary with the features below as well, so it can be even better than that.)

- Let's say you rm the go.sum file. That's OK. They also default to using the Go Sum DB to verify that a given published version of a module can never change. So if a module has ever been `go get`'d by a client with the Sum DB enabled and it's publicly accessible, then it should be added to the Sum DB, and future changes to tags will cause it to be rejected.

- And even then, the module proxy is used by default too, so as soon as a published version is used by anyone, it will wind up in the proxy as long as its under a suitable license. Which means that even if you go and overwrite a tag, almost nobody will ever actually see this.

The downside is obviously all of this centralized infrastructure that is depended on, but I think it winds up being the best tradeoff; none of it is a hard dependency, even for the "dependencies should be immutable" aspect thanks to go.sum files. Instead it mostly helps dependency resolution remain fast and reproducible. Most language ecosystems have a hard dependency on centralized infrastructure, whether it is a centralized package manager service like NPM or a centralized repository on GitHub, whereas the centralized infrastructure with Go is strictly complementary and you can even use alternative instances if you want.

But digression aside, because of that, you can trust the version numbers in go.mod.

You're right, but also TFA says "There is truly no use case for ever parsing it outside of cmd/go". Since cmd/go verifies the contents of your dependencies, the point generally stands. If you don't trust cmd/go to verify a dependency, then you have a valid exception to the rule.

Only that if the corresponding version does get used, and the hash doesn't match, you get an error. But you can have multiple versions of the same dep in your go.sum - or none at all - and this has no bearing on what version gets picked when you build your module.

The version that does get picked is the one in go.mod of the main module, period; go.sum, if it exists, assists hash verification.

Yes, if you want a lockfile in the npm sense, you need both.

But a Go module does not get built with new transitive dependencies (as was claimed) unless they're listed in some go.mod; go.sum is irrelevant for that.

https://scottsumner.substack.com/p/imagine-130000000-washing...