I think so. These sites can be hardened by relying on people following who they know, but the slop ruins discoverability. That's also partially the reason people moved to TikTok from older, more dumped-on platforms.

...so TikTok is less dumped on?

I assume it was when it was newer, as they all were.

There are at least two of us

PK isn't the same as public ID, even though you could make them the same. Normally you have a uuid4 or whatever as the public one to look up, but all the internal joins etc use the serial PKs.

> Normally you have a uuid4 or whatever as the public one to look up, but all the internal joins etc use the serial PKs.

what? that's possible, but it's the worst of both worlds. I've certainly never encountered a system where that's the "normal" practice.

the usual reason people avoid UUIDv4 primary keys is that it causes writes to be distributed across the entire B-tree, whereas sequential (or UUIDv7) concentrates them.

but if you then add a "alternate primary key" you're just re-creating the problem - the B-tree for that unique index will have its writes distributed at random.

if you need a UUID PK...just use it as the PK.

The problem isn't so much the writes, it's the reads. Every time you join tables, you're using a PK 2-4x the size it needs to be, and at least that much slower. Even filtering on a secondary index may involve an internal lookup via PK to the main table. It doesn't take long to start noticing the performance difference.

Since you'd have a secondary index for the public UUID, yes that one index suffers from the random-writes issue still, but it takes a lot of volume to notice. If it ever is a big deal, you can use a separate KV store for it. But if you picked UUID as the PK, it's harder to get away from it.

I agree. Ironically have inherited a lot of projects where they picked a "type-safe" language but didn't properly type the system boundaries, including RPC and database. Wrong priorities there.

Adjacent to the article... there are a lot of bits from WCF I really liked and miss. I didn't really like a lot of the default way to use it... I generally would combine all the interfaces and a client instance generator into a single library to share (as opposed to the XML config crap the people tended to default with).

Today, there's tooling around OpenAPI/Swagger, but I don't think it's nearly as nice as using WCF for the server and client interfaces directly.

I could see myself picking Java over Go just cause of the error handling

HN posts are mostly not about politics, at least not on the top page. Sometimes a non-politics post ends up getting politics comments though.

When I tried Reddit a while back, that problem showed up even with no moderation action being taken. I guess cause an obsessed person will use the site like 1000x more than a regular person, they end up being the "majority." The voting system also encourages bad behavior.

I still don't get why Java is the only language that needs the heap to be carefully tuned. Like it hogs some memory at start, crashes if you go above a certain amount, and doesn't return memory to the OS when GC'd. Even Python and JS don't have those problems.

> I still don't get why Java is the only language that needs the heap to be carefully tuned.

Only tuning you should be doing is setting the heap size and algorithm (Though, size is likely enough).

> Like it hogs some memory at start, crashes if you go above a certain amount, and doesn't return memory to the OS when GC'd. Even Python and JS don't have those problems.

Unlike Python and I believe most javascript engines, the JVM uses moving garbage collectors. That's the primary reason why it hogs memory.

In these ready to return to OS languages, when something is freed or allocated they are literally calling "malloc" and "free" directly. That's why stuff tends to return back to the OS faster.

The JVM doesn't do that. When a GC runs in the JVM, the JVM picks up and moves live data to a new location. That means the JVM needs a minimum amount of free space to operate. The benefit of this is the JVM can allocate really fast, it's just a single pointer bump and a check to ensure there's enough space. It's pretty close to the same performance as the stack is in C++.

And if there's a lot of data that lives for a short period of time, the JVM frees that data very fast as well. There is little accounting that the JVM has to do to free stuff up because it's simply moving the live data.

For even the fastest allocators that python/javascript engines use, this isn't true. They have to keep track of the various allocation locations and the gaps in allocation when something is freed. And a request for allocation needs to ultimately find a location in the heap with enough room.

Java does have a memory issue, though, all objects in java are pretty bulky. This will hopefully be fixed in future versions when "value" types are added.

Thanks, that's a really good explanation. And makes sense, especially since Java objects are all constantly getting allocated/freed on the (virtual) heap rather than stack.

No problem.

The GC strategy for Java works best when the JVM has a lot of memory to play with. That's a big reason why a lot of companies use it for the backends.

However, Java suffers when you start talking about small heaps. This has become a much bigger issue as containered applications have risen as a primary deployment method. There are active efforts ongoing to solve this problem and make Java more friendly to smaller memory footprints and containers in general.

The Go/python/javascript strategies end up working better in those situations. They have very fast startups and pretty low memory requirements. However, when you start talking about apps that need a lot of memory, they both end up suffering as their allocation strategies degrade as the memory being tracked grows. Especially if there's a large amount of memory churn. The JVM has about the best strategy for very high memory churn.

Yeah the Java way makes sense if it's the only thing running on that machine, or at least you know ahead of time how much RAM to budget to each thing. Which was often the case on servers. I'm not surprised if that performs better than Go in a way, but seems like Go does ok. If they really wanted a custom heap on top of preallocated memory in a Go program, couldn't they just do that?

The weirder part is that Java also used to be a bigger thing client-side, back when websites commonly included Java applets.

You don't have to do anything, it just works.

But eventually someone gonna write the goddamn whole of AWS or Alibaba in the language where you have machines with TBs of heaps (yeah, you read that right), where most other managed languages would just give up instantly - and then you may have to add 2-3 parameters to make it actually run properly in these extreme conditions.

They do, but then people either work around them, or rewrite in Rust.

Java has all these knobs, because the ultimate goal is not needed to rewrite, rather fine tuning, just like when you look at the endless command line options for GCC, clang, MSVC,...

It is also a matter of implementation, Android is Java (kind of), and you also don't get push knobs unless you are a developer talking directly to a single device over ADB.

HN doesn't need it. I'll read this site, not gonna bother with Twitter or Reddit though.

AI