mohbk

I'd argue this is because social media is ironically enough, manipulated less than traditional mass media.

Despite brigading from any side, anyone can get anything trending on social media, including videos of the aftermath of israeli air strikes, meanwhile nothing but filtered news headlines make it out of editors.

A fun exercise is comparing how big news websites frame headlines when Palestinians die (passive voice) and Ukrainian / israelis are killed.

Yep, people not seeing the usecase have not tried to build a serverless product on AWS and found themselves stuck between cheap, performant but denormalized ddb or whatever the fuck aurora serverless v2 is supposed to be.

I do not want to denormalize my data model, i do not have a high performance usecase, I simply want infrastructure that scales with usage (down to 0) and a flexible normalized model I can build more on top of easily.

DDB is great and all until you're asked to add 3 filters and orderby feature and suddenly you're adding elastic search to your project

and typeof NaN == "number" is also part of the standard, it is valid to pass NaN to functions that accept numbers, and it's expected to propagate or change back to normal numbers (e.g. NaN^0=1)

the website is 90% problems of very stupid implicit type conversion, and 10% valid floating number behavior that exists in other languages too (0.1+0.2, NaN a number)

I agree using plain JS anywhere is not a good idea, but Typescript (or js with ts annotations) is often ignored when it does a very good job of catching most of these issues, while offering a very flexible type system in a more mainstream paradigm

knowing how many people can't take disagreement well, I don't think this was a poor decision, practically you can't just trust everyone to have a good head on their shoulders, when you just want a job to survive or get your foot in the door, you can't be picky with who you work for.

I feel the alternative is not better, a light weight bare minimum lib and no ability to install your own is definitely worse.

there's a number of benchmarks you can checkout online.

number crunching wise, Go is on par with Java and C#: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

for webdev work, the standard library might not be that fast, but it's fast enough, and if you need even more speed the fasthttp third party Implementation offers good speed: https://www.techempower.com/benchmarks/

I think service-changing requests should be passed to a higher level in the chain, to the architects or whatever, changing service contracts can end up changing the domain. I'd assume the architects would have a high level view where they can instruct teams whether to prioritize the requested change, delay it or just veto it completely

you can solve underfetching and overfetching in a normal restful API, you can have optional entity relationship fetching on query/params, and also user defined queries.

This might be hard/tiresome when you're hand writing SQL queries but this is where query builders and ORMs really shine.

IMO I wouldn't reach for graphQL unless I have a lot of entities and a lot of nested relationships (or an actual graph), it can get either very tiresome to add or overly complex or tightly couples your DB layer when you have deeper nested relationships