BackBlast

Except that you've just split your available cache region between multiple processes. This can actually decrease performance, I remember cache thrashing back in the P4 days that could cause an application like MS Word to take minutes to load. One process evicting data the other one needs and vice versa. It circumstantially makes the situation worse instead of better.

Turn off hyper-threading and boom, everything started to function normally.

The solution to not having enough food for one mouth often isn't to add another mouth.

I still see this in modern benchmarks on modern systems where multicore throughput on many benchmarks is just better when you just turn off SMT.

AMD's 3D chips go faster because of the huge cache. Every time we add another process to a core we just split the cache in half instead.

Clearly, this is workload dependent. But I immediately turn off SMT on new systems I get. I'm not core limited, I'm usually single thread limited. Like, always. No reason to keep SMT on for this case.

Not sure what ads have to do with my response. I don't monetize with ads. A lot of software does, and it can misalign incentives. The user becomes the product instead of the customer.

> Anything Apple can do to discourage web apps and force more development of native apps I'm grateful for.

As a vendor, I would love nothing more than to never have to deal with the app store again to reach iOS users with first class software.

Yes, it does.

My take away is that this list is very unreliable.

I appreciate the thoughtful reply. Every time I see this list trotted out I can't get past the obvious red flag. Nice to have some more background on it.

> The list places JavaScript at a score of 4.45 and TypeScript worse at 21.5. For reference, C, the most energy efficient it 1.0

The point is that TypeScript is JavaScript with typing syntax added on top. There is a transpile step into JS. That's how TypeScript works. The runtimes are exactly the same. Unless we're also measuring the build step? Which seems silly.

The difference should be near zero. And it's not. They clearly do not understand exactly what they are measuring.

How can you trust a list that places JavaScript an order of magnitude lower than TypeScript? Seems fundamentally broken.

The measurement size is just marketing at this point. The actual transistors are much larger.

> childish and unethical

These are not attributes you want in a CEO. They prevent the building of trust with both employees and users. Both of which you should seek when building a site like Reddit.

The seeds of his character were revealed years ago. Now we're seeing the fruits.

Want to know the heart of a man? Give him power.

That rule set is pretty harsh. Can I recommend:

  news.ycombinator.com##body:style(background: black)
  news.ycombinator.com##td:style(color: #fafafa !important)
  news.ycombinator.com##table:style(background-color: #120F0D)
  news.ycombinator.com##div.toptext:style(color: #fafafa)
  news.ycombinator.com##span.c00:style(color: #fafafa !important)
  news.ycombinator.com##a:style(color: #ffa000 !important)
  news.ycombinator.com##span#karma:style(color: #faa000 !important)
  news.ycombinator.com##span.pagetop:style(color: #fafafa !important)
  news.ycombinator.com##textarea:style(color: #fafafa !important; background: inherit; )
  news.ycombinator.com###hnmain:style(background: #120F0D !important)

He has to flush the existing subscriptions no matter what. It's done. He has said he can afford it.

He could fire up a new system with appropriate pricing as soon as he can manage. All customers, if they want to come back, are then forced into the new system at new pricing levels. Maybe this takes a month or two or three. He's not losing money in the mean time and can re-open at something resembling a profitable stance when he can do so.

Yes, it sucks. But there's a path here if he wants to go for it. I don't blame him for throwing in the towel. He's tired of getting yanked around. I would be very hesitant to keep throwing good time(money) after bad.

This one isn't particularly abused. It's already available in Chrome and the number of sites that leverage it at all is vanishingly small. No real abuse from it - so far at least.

It does offer a much better user experience than "go search out these obscure menu methods".

Safari might do well offering a "don't badger me" option that just shuts all page based prompts and requests.

It's not that hard. You only need a few rules to make it work.

* Manage your own VPN and don't depend on the vendor's solution. * Only use base level services that are available on every cloud you want to leverage. Which probably means you're on a container based system and not using anything like Lambda.

Then a service being in another cloud just doesn't matter. You're always making requests via your VPN anyway, if it's in a local cloud or remote cloud it doesn't matter.

You'll feel the egress pricing if you integrate cross cloud services that are chatty. So it really depends on your immediate goals.

If you just want redundancy then you need to keep the resources standing in the backup cloud/AZ and just move your entry point via DNS, in which case you don't really need "cross cloud", just the ability to provision else where.

When your account changes from the time based free tier to the only forever free tier they often shut things down. Even if you're careful not to use the time based free tier stuff, which I was, it went pop anyway.

If you're below their "idle system" threshold, they'll shut it down.

Get past the 3 month or whatever it is tier. Put a low level load on the system to get it above the idle threshold and you should be good to have a nice personal playground. Probably.

I've had systems go down to both these. They also have rejected every credit card I tried to throw at them. Which is a known problem for them as well as some other cloud providers. I no longer put anything critical on OCI.

> And apparently a javascript framework is currently beating all of those languages in the composite score on techempower, though that seems a bit weird to me:

Just-js was essentially built to run the techempower benchmark. It's not a real stack you can use. An exercise in "what is possible".

Really depends on the use case. When you don't need the extra features of the AWS load balancer+API gateway over, say, a relatively straight forward nginx/caddy installation. The time to learn the AWS equivalents over off the shelf OSS is pretty similar. Why not just use the OSS all things considered?

There are significant downsides to a lot of the vendor offerings, they seem like a simpler solution but they are plenty complicated in their own right. Particularly since they are probably built to accommodate varied and complex cases that you don't really need. And rarely is this paired away under some special dialog for power users, often you are expected to just know everything up front.

Ubuntu server itself is pretty arm friendly. But there's a LOT of software that doesn't come with the distro's packaging that one might want to run in the cloud. Docker images and vendor hosted package repos. Everyone does this for x86. Very few do it for ARM. And if you want to try to build-from-source, the dependencies of a lot of pieces are often very out of date on ARM.

There is a kind of after market ARM community that occasionally builds these items. But they are generally pretty out of date.

I don't have an issue with the base distro and what it tries to do, but there are so many random pot holes and road blocks that just don't show up for x86.

I have ARM servers running in production now. But I have workloads that aren't reasonable portable to the uArch and I don't force them there.

To the downvoter...

I strive for simple infrastructure.

ARM doesn't support the x86 docker eco system. That's a significant strike but not totally unworkable for me.

My primary database isn't prepackaged with the ARM packages nor does the originating org build one. I could build it myself, which I have done plenty over the years. I did try it, but the dependencies aren't up to date on ARM. So now I'm building dependencies and the software package. Building software from scratch can be a rabbit hole that eats untold amount of time. After a one-day effort I gave up and abandoned it. I'll revisit again if Hetzner brings Ampere to the US and I can verify the instances have much higher IOPS ceilings.

Enter another distro and I have to rebuild all of my provisioning and management scripts for all my services with all the testing entailed in the new dependency chains. I'd rather try to build my db from source again, frankly.

4k block size, it's IOPS limited. No surprise there.

Introducing new distros to solve the problem is moving in the wrong direction. It's so much easier to deal with one distro in the cloud. Just more reasons not to go multi uArch.

I've benchmarked ARM systems vs other processors.

On my workload, using Intel as a baseline. AMD under performs relative to standard benchmarks. ARM over performs relative to standard benchmarks. I have seen good performance from Ampere, particularly for the price.

However, ARM architecture complicates my workflow significantly. I've found that they are not worth using it right now due to compatibility issues, easier to just stick with x86 for most things. Dealing with required missing packages just kills the value.

My system isn't generally compute limited anyway. IOPS and egress dominate rather than MIPS.

Online deployments are discussed with some frequency. Tooling is talked about. Always as a "cluster". Why do we need clusters anymore? Scaling containers, scaling functions, scaling, scaling, cluster, cluster. We suffer so much tunnel vision about horizontal scaling when it's just unnecessary anymore for most applications. The cloud products are all about horizontal.

Do you really need more than the 400 threads >12TB ram with PBs of storage found in a reasonable high end server?

The API calls shouldn't be stored in the browser. That would just be a mess. A refresh should predictably fetch fresh data, because that matches user intent. There are also times I want to turn caching off. The understanding of what is reasonable to cache and what isn't is better understood on the front end, where the data is actually used/consumed. Browser caching is out for my use case.

I create a JavaScript object that matches the interface of my request library, axios in my case. The cache is basically a middleware to it created by function wrapping. Kind of like how memoize works but with a bit of extra smarts.

I have my own .get(), .post(), .delete() and .put() functions. So when a .get() is called, it's a cache check and return the stored value. If not found call axios.get() with the passed in args and store in cache before returning.

The post() function clears the cache then passes through the arguments to axios.post().

Etc.

The 5 minutes is accomplished with an entry on the event loop to remove said item.

It's only like 30 lines of code.

The real wins for this is in basic navigation. Clicking around site exploring, makes it snappy. Another advantage is lowering the total request count a bit to the backend, lowering the cloud bill.

Last time I used GraphQL seriously, caching was suppose to work. I never really saw it work well. Not like you can predictably cache REST.

I do. It helps with latency when someone hits the "back" button and your queries are page/view based. Instead of seeing the delay of the query, it's instant. Because, well, it probably should be.

Cache times are usually short, < 5 minutes, and are cleared whenever a POST/DELETE/PUT are issued. Works pretty well in my experience.

Complexity of the backend is much higher with GraphQL. Caching is much more difficult (not impossible) compared to REST. The client query system is bigger and more complex. So... Complexity generally is higher with GraphQL.

Some data flows end up with dependencies you don't know when you build a query. Such as a auth token, credentials, etc. So you end up with several round trips anyway for these cases.

A lot of the advantages to GraphQL don't materialize due to how front ends are built. It encourages the use of a global store to shove all data into from the large query you just completed. Except every front end I've ever worked on that used GraphQL basically used it just like REST with a few extra features because typical front end architecture encourages this. Taking little advantage of what GraphQL is suppose to offer.

In my experience versioning was more painful with GraphQL than it was with REST. With REST you know you just need to rev the path or some other obvious marker like a header, which allows you to run both versions side by side. In GraphQL this isn't so obvious that you need to do the same kind of separation for braking changes. And breaking changes are occasionally needed contrary to what some people believe.

So when I make a backend now, it's vanilla REST without anything fancy. I favor simplicity.

Sounds like toxic workplace problems to me. Those are very not fun.

So what? You got preached to. "Bullied" seems to strong. Now it's time to shout your displeasure to the world of it's unfairness?

Every round of tech hype sounds about the same. Object Oriented programming. The network is the computer. SCRUM. Mobile apps. SPA. Micro-services. Cloud. Serverless. They make it sound like the savior of all that ails you, but the reality is always more nuanced. It's like this in more than just tech.

There are interesting ideas in all of them, places they could be used and places they shouldn't. The reality never matches the hype train. The more experienced I get the more I generally want tried, true, and longevity to be attributes of the stack I pick. This seldom intersects with hype.

Unplug a bit from the online echo chambers preaching this stuff and you won't feel so "bullied".