Good taste is what I do; bad taste is what others do

Having native TTL in PostgreSQL would remove so much unnecessary Redis in the wild.

Take the seo, but don't waste any time with PH (or any other alternatives)

not only is YAML a pain but JSON has native parser in major languages, while not yaml. I find it crazy some people are still actively choosing this over JSON (or alternatives)

This is a case of the right tool for the right job. YAML is far easier to read and parse as a human than JSON.

If you're passing data between processes, and you still want the data to be human readable, then JSON is a good choice.

If you're writing a configuration file that's going to be edited by a human, then YAML is easier to look at and understand.

> YAML is far easier to read and parse as a human than JSON.

When you're on line 4000 of a YAML configuration file and the previous 70 lines have been at indentation level 6, and you see a blank line and another line at indentation level 4 (or is that 5? maybe 3?) then I strongly, strongly disagree that two '}' characters are more difficult to read than newlines, tabs, and spaces.

YAML is one of a family of languages borne from the idea that punctuation is bad and therefore should be invisible. Not gone, because all of these languages still have punctuation. No, these characters that are critically important to the interpretation of the file must be invisible.

Code and markup is easy to read when it is easy to predict what the computer will do when it parses it. Invisible punctuation makes the files harder to read, not easier. The only thing easier in YAML is writing it in the first place, and we all know that "write-only" is an insult.

I visited it 20years ago and wasn't really impressed. Then I went there last year, and I was blown away. The outside is nice, but the inside is truly a masterpiece, especially when the sun is low in the sky

If CUDA is nvidia's moat, which has basically created a monopoly, how long until there is an anti-monopoly trial against them in EU or even in the US?

It's a popularity issue; npm is an easy target. I don't see why it wouldn't happen to golang for example. You just need take over the git repo it's over for all users upgrading like npm

As far as I remember:

"go get" doesn't execute downloaded code automatically; there's no "postinstall" script (there can be a manual "go generate" or "go tool" the user may run)

Go doesn't upgrade existing dependencies automatically, even when adding a new dependency: you need an explicit "go get -u"

You don't use the same tool to both fetch and publish ("go get" vs "git push") so it's less likely a module publisher would get pwned while working on something unrelated.

The Go community tends not to "micropublish" so fewer people have or need commit rights to published go modules.

Go has a decent standard library so there are fewer "missing core functionality" third-party packages that world + dog depends on.

Npm is easier to pwn than Go, Maven, RubyGems, PyPI, CPAN, etc. because the design has more footguns and its community likes it that way

postinstall is a liability for sure, but as soon as you execute untrusted code, it's the same no matter the language. Last week, npm pawn was working like this without a postinstall, which could be the same with Go. Nothing prevents me from pushing a code that would read all your files as soon as you load the library in your code.

I notice you didn't address the other 4 differences. All 5 are about "defence in depth", making things less likely - and conversely, not doing them makes pwning more likely.

I'll add a 6th difference: "go get" downloads source code, not maintainer-provided tarballs. You can't sneak extra things in there that aren't in the code repo.

What about Java's Maven, much more popular and longer living?

When your only dependencies are Spring and Apache Commons, which requires legal approval in your corporation to use, and each update requires scrutiny, it's hard to get any supply chain attacks, right?

What makes you think Maven is more popular?

The takeover due to the lack of response to an email is worrying

Yeah, I really wasn't happy about that. I did put it to the registrar that such a policy is wrong and open to such an attack. I got the impression that they weren't going to change their policy though. Such policies are something I'm going to be looking at when considering a new registrar.

Who is the old registrar?

> The takeover due to the lack of response to an email is worrying

The trouble is that that is the way most way modern small print is worded.

Read the small print in any contract of the last 10 years. Almost all of them when speaking about delivery of notices will apply $n days to emails.

Everyone in the tech world knows why it's a horrible idea, but sadly most lawyers who draft these things either don't care, or their client doesn't care and that's how the lawyer has been instructed to draft.

You are lying to yourself. In this attack, nothing was executed by npm; it "just" replaced some global functions. A Go package can't do that, but you can definitely execute malware at runtime anyway. It can also expose new imports that will be imported by mistake when using an IDE.