xrstf

I find it incredibly hard to understand anything in TOML that is more than simple, unnested key-value pairs. If you get into arrays, maps etc. then TOML is a nightmare to read.

The "O" in TOML is not deserved in my opinion.

> We had those scams from beginning

I tend to disagree a bit. In the early days, most scams at least pretended to have some non-pump-and-dump usecase. Like Dentacoin or Filecoin. You could at least pretend to "buy filecoin today so you can store PB's worth of data in a year" or "buying Dentacoin now because in a year you need some dental work done".

Nowadays all new tokens/coins have 0 usecases attached and only exist to be pancake swapped and pumped and separating other people from their money. It's all about lending, yielding, farming, interest rates, staking, ...

Don't forget Internet Computer Protocol (ICP), which tries to replace the Internet but is also based on it.

Citation needed. Germans do not quit working for 2 weeks in the summer. Where did you get that from? What German companies shut down for 2 weeks in the summer of 2019?

Can you give some examples? I live in Europe and have never experienced that in my country suddenly everything stops for 2 weeks in the middle of the summer.

Good thing there are many spam knock-off sites re-using their content, so we don't need to start an archiving campaign like with Geocities.

A lot of this seems to hinge on "go get" being the best way to get Go source code. Most discussions I've read so far come down to "well, this might be cool, but it would break go get, so we cannot ever do it".

I for one could live without go get alltogether. In 99% of cases it boils down to a simple git clone anyway, which could (should?) be done by the package manager anyway.

Maybe it's time to re-evaluate the existence of go get, now that we're seeing that "just clone master and hope nothing breaks" has obviously not worked for everyone outside of Google? Maybe bundling Go (the compiler and linker) with tools for fetching source code wasn't such a good idea after all?

Just my 2 cents...

We are using Caddy as a simple reverse proxy in Docker environments. The configuration is a bit simpler than nginx and we love the tiny Docker images we can create (not sure how large an nginx-full installation is).

That being said, we did run into a few issues that forced us to go back to older Caddy versions, like broken websocket support or the timeout issue in 0.9.5. Also, sometimes the documentation is a bit lacking and unclear. DNS resolution seems to be flaky sometimes (we're using alpine-based containers and sometimes Caddy just won't resolve names of other containers, even though a curl inside the container can resolve the names just fine).

So if you've got a working nginx setup, I'd say stick with it. For new projects it is worth to check out Caddy. The issues we ran into occured early in our development process, they didn't just suddenly happen in production, so once you've tested everything, Caddy just works.