Having said that, I know there has been some falling out between RH and Docker some time ago, which was one of the reason RH ended up creating Podman.

> In Go there is less noise, but also there no way to interrupt Go's time.Sleep.

The full piece would be something like:

    func sleepCtx(ctx context.Context, delay time.Duration) {
        select {
        case <-ctx.Done():
        case <-time.After(delay):
        }
    }

    func main() {
        fmt.Printf("%v\n", time.Now())
        ctx, cancel := context.WithTimeout(context.Background(), 500*time.Millisecond)
        defer cancel()
        sleepCtx(ctx, 1*time.Second)
        fmt.Printf("%v\n", time.Now())
    }

[0] https://github.com/plibither8/refined-hacker-news

Podman has an almost identical CLI to Docker, and can have a daemon that is fully Docker compatible (thus, all Docker integrations work against it including docker-compose). It is literally a drop-in replacement but it doesn't require your company to buy licenses. So yes, you should if you can.

Comments URL: https://news.ycombinator.com/item?id=31051576

Points: 1

# Comments: 0

[0] https://github.com/romkatv/powerlevel10k

I've been struggling to find it again. Does anyone remember what the article/site was called?

I suppose, so we shouldn't try breaking monopolies any more? There are plenty of examples where $big_corp is basically ubiquitous to $their_market until $competitor comes along.

The data Bloomberg uses can probably mostly be licensed outside of Bloomberg. Nothing stopping from these guys getting at least some of that data. Being it is open source, it likely means you can pick and choose your data instead of having _everything_. At which point the price can go down.

For the Brits among us, or perhaps anyone with a non-US keyboard layout, I recall when I still had my Mac, this wasn't mapped properly. It was the button on the right of the left shift. This was quite strenuous when I had to switch within the same application. I can't remember if I just re-mapped the shortcut or what it was, but I suggest you look into having that mapped to the button right above Tab (below ESC). It makes it a lot easier.

> most of the documentation talks of gopath

Historically go used a GOPATH env var. Go code had to live under there under `$GOPATH/src/`. When doing an import, go would look at the import path, and find it in GOPATH. This wasn't flexible enough but still exists under the hood as it's where go saves (caches?) packages globally. If you have a go.mod/go.sum file in your project, in general, you won't have to worry about GOPATH.

Worth noting that go, while widely used, was created to solve Google's problems (I guess at least initially?), where (from my understanding) they have a huge monorepo. At that point, having everything live under such a GOPATH somewhat makes sense.

> why are go mod vendor and go mod tidy different commands?

Go mod vendor puts all the dependencies in a ./vendor directory. Often used to commit your packages directly into git. There might be other advantages, not sure, but personally I don't use it. Go is able to pick up the packages in your go.mod directly from $GOPATH.

Go mod tidy ensures your go.mod matches your used package. E.g. if you remove usage of a package in your code, go mod tidy is able to pick that up. In addition, it also ensures your go.sum matches go.mod.

> the lack of “one true way” is very strange. some projects module. some projects check in dependent source code

This is a historic issue. Prior to 1.12 (I think), go modules didn't exist, and there were different community projects that attempted to solve go package management.

> do i download with go get? or go install? or go get -u?

Again, historic issues, iirc go get -u forces an update of a package, meaning this updates your go.mod file. Go get without -u does not force update the package. It update your go.mod file if you haven't included the module previously. Go install is used for go main packages. It fetches the code, builds it (so it must be a main package), and puts the final binary in $GOPATH/bin. Assuming you have that in your patch, you can use it straight away.

> We need to keep track of our customers’ account balances.

Right. That's what the blockchain is able to do. It can assert that you, who says you have 1 bitcoin in your wallet, actually really have 1 bitcoin in your wallet (assuming no attack vectors such as 51% attack).

> We need them to trust that their Wave balance is correct and Wave won’t lose the money.

This is the same argument as above.

> We need to comply with relevant regulations—know-your-customer laws, capitalization requirements, account limits, etc.

Not something cryptocurrencies have claimed they can solve.

> We need to provide an easy way for users to exchange their balance for cash and vice versa.

This is an implementation detail, and entirely depends on how the UX of the wallet is. Sure running a CLI tool and GUI that looks like it's from 2008 (at least it was last time I looked at bitcoin's GUI) isn't great UX, but you can build a different GUI for it. Something plenty of exchanges have already done.

> Of course, the above aren’t the main use cases of cryptocurrency today: those are speculation, theft, extortion, more theft, drugs, even more theft, and speeding up climate change. It remains to be seen whether legitimate, productive uses of cryptocurrency will ever justify the hype. We hope so!

There it is. This is just an article blindly bashing cryptocurrencies. I implore you to ask yourself, what has previously been used to do all the above? That's right. Fiat currencies such as the GBP, USD, and other currencies.

I may possibly be biased, because, I certainly believe cryptocurrency has its place, though I don't believe it will replace fiat. But this article is just unnecessary fear mongering with zero merit.