HN user

xrstf

1,000 karma
Posts8
Comments161
View on HN

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, ...

New Firefox 5 years ago

Is it coincidence that comments are turned off on _all_ videos on YouTube[1] related to the redesigns?

What options do I as a "normie" have to give feedback? Is there really only one way, to use the ancient Bugzilla and hopefully finding a ticket somewhere?

[1] https://www.youtube.com/c/firefox/videos

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.

But a lot of things about php sucked, at least 10 years ago when I stopped needing to write it.

Sadly you missed out on the major advances that happened in the PHP ecosystem, like properly namespaced code, massive performance gains since PHP 5.3, Composer, modern frameworks, the PSR initiative (even though one might not agree with all their "standards") and so much more. So I would not judge PHP's evolution by that one proposal ;) A lot more were accepted, implemented and released, from type annotations to the spacechip operator. Personally I'm thankful that nobody further pursued the idea of tainted strings for PHP.

Fixing JSON 10 years ago

Because using certain keys could break your JavaScript (and JSON was designed to be a subset), like

    { delete: "me" }
If you don't want to keep a list of known keywords around, just insisting on quotes is the easier way.

[EDIT: See also this YouTube video, where Douglas Crockford explains it himself: https://youtu.be/-C-JoyNuQJs?t=5m]

not throwing any effort into postgresql

The amount of research about the on-disk internals of both PostgreSQL and MySQL are a lot more effort than I would have probably spent (granted, I don't have a team of highly paid devs at my disposal, but still, I've seen technical decisions made on the basis of Google Trends...).

I'm pleasently surprised that the generated sites work just fine with JavaScript disabled (at least on the author's blog). Which on the other hand makes me wonder why I (as the visitor) need to download a 700KB JS blob that contains all blog posts, React and other things just to read the content.

Without JS: 4 requests, 20 KB transferred, DOMContentLoaded @ 360ms

With JS: 27 requests, 518 KB transferred, DOMContentLoaded @ 22.07s (includes Disqus)

For caching purposes, it might make sense to split the bundle.js into a app.js and content.js and only update the content.js on re-deployments. Not sure if this is just on the author's blog or on every site built with Gatsby.