HN user

jamesrr39

260 karma
Posts0
Comments132
View on HN
No posts found.

Subjective depending on who you ask, but for me RSC is not really representative of React usage. (I believe) the vast majority of React apps (and the vast majority of dev experience in React) are front end only. I have been writing React in some form for 8+ years, but never touched RSC.

I tried Angular 2+ back in the day. I found it frustrating to learn as the API had changed between versions, and when searching for help you would come across a blog post/stackoverflow answer, start implementing it and realise it didn't work in the version of Angular your project was in. Frustrating.

Tried React afterwards, this frustration didn't really exist and it was much easier to pick up.

Ironically we bought a Roborock (Chinese brand with close links to Xiaomi) and didn't connect it to the internet (checked this would work before we bought it).

If you don't want the scheduling and other app features, and are happy switching it on when you need it, it works fine.

Motivation for an offline one was more than just cameras, also that it wouldn't be bricked by an update one day, but still...

Sounds like a Samsung phone... no end of dark patterns and pushing Bixby AI and whatever else. And then once you have the phone set up you get to spend the next 10 minutes uninstalling a load of pre-loadded apps that you didn't want.

Fortunately Android is a pretty diverse range and Samsung is just one player. I had much more user-friendly experiences with Fairphone and Motorola.

Developers (often juniors) use LLM code without taking time to verify it. This leads to bugs and they can't fix it because they don't understand the code

Well... is this something new? Previously the trend was to copy and paste Stackoverflow answers, without understanding what it did. Perhaps with LLM code it's an incremental change but the concept is fairly familiar.

Thanks for these comments, I appreciate it.

Although I would point out:

scalability [...] no company would even bother with PostgreSQL at all

In my experience, you can get pretty far with Postgresql on a beefy server, and when combined with monitoring, pg_stat_statements and application level caching (e.g. the user for this given request, instead of fetching that data on every layer of the request handling), certainly enough most businesses/organisations out there.

Genuine question: I appreciate the comments about MongoDB being much better than it was 10 years ago; but Postgres is also much better today than then as well. What situations is Mongo better than Postgres? Why choose Mongo in 2025?

The amount of perfectly functional messaging apps Google has gone through is crazy[1]. Each Google messaging app (GTalk, Hangouts, Meet, etc) is perfectly functional, but with an endless series of migrations, why would you stay around and every several months/year explain to the non-technical family members how the new version of Google's messaging product works?

Enter Whatsapp, which has been pretty consistent through the years, and of course guess which one people use.

[1]: Of course, it's crazy from a product management perspective - but from a "launch a new product to get the next promotion" perspective...

At the risk of appearing low-tech, a much more simple, Goroutine-safe solution for dealing with "now-dependent" code:

type NowFunc func() time.Time

func getGreeting(nowFunc NowFunc) string {

  now := nowFunc()

  if now.Hour() < 12 {

    return "Good Morning"

  }

  return "Good day"
}

And just pass in `time.Now` in for live code, and your own inline function for simulating a time in tests.

On a larger scale: Copenhagen and Vancouver both have fully-automated metro systems (i.e. driverless systems). Presumably there are many other cities with such systems around the world, and they probably all work nicely.

Fine for getting around different areas of the cities, but it's not going to drive you wherever you want to go though.

The future for self driving cars are closed roads where only driverless cars are allowed.

Given that human-driven cars, trucks, cyclists are already on the roads and will be for quite a while to come, and pedestrians already cross it, you would have to build a whole new road network, with crossing points for human-driven vehicles/pedestrian traffic. Which is simply infeasible, both in terms of money, but also simply space, especially in built-up areas where the space is already fully utilised.

So basically they're trying to do a "liveness" check, probably under the assumption that videos are too hard to fake (and hopefully they compare the ID documents against the video). Honestly, that seems legitimate to me. With data leaks and generative AI, it's going to be increasingly hard to do the kind of identity verification tasks online that we take for granted.

I worked for a company that required these videos in one of the markets they served. Some countries have decent digital ID solutions already in place, but in many it's just a picture of a driving license or such that is so easily faked/stolen. Kind of a shame how in many countries officially identifying yourself online is not implemented/implemented badly enough that no-one uses it, so instead we have this poor uploading pictures of private documents and videos of yourself fallback.

Yes. See GDPR (max fine 4% of global annual revenue) or the new EU Digital Services Act (max fine 6% of global annual revenue).

These are both fairly new laws, if you look at the laws they replace (which themselves may not even be that old), the fines are a huge leap up.

presumably there is still some authorization requirements though? The logged in user is authorized to see details about Friend 123, but not about Non-Friend 456?

I agree with the article, and want to add on that the browser network debugging tools are a pain to use with GraphQL (every request to /api/graphql, can't even quickly filter by endpoint name). I landed instead on OpenAPI, which can feel like a bit of a hoop to jump through sometimes when writing endpoints (but then, so can GraphQL), but the result is equally nice. And it's much easier to get authorization right with REST APIs.

I wonder if GraphQL would have been as popular if it was a much smaller shop than facebook launching it. Feels like having a name like FB gets you a tech credibility pass.