n_e

In the example you don't even need the default clause and the helper (the error message without it is worse though).

> If you write here about the fact that France's GDP is nearly 70% made of public spending you get downvoted into oblivion.

Maybe because it's false, or at least contradicted by the most popular sources?

https://en.wikipedia.org/wiki/Economy_of_France says 57% in the infobox

Totally agree. It seems like a good idea at first as it's simple, but, since the deployment concerns don't match the source code management ones it breaks down quite quickly.

For example it's quite readable when deployment order matches the commit order, but it gets problematic when e.g. the deployed version is rolled back to a previous version.

It also gets messy as environments are added, or even worse you have to manage customer-specific deployments.

> what should I choose and why?

You should choose Node.js unless you have a good reason to use something else. This is what everyone uses, and it is used widely enough that it's in the same position as Java, i.e. it will be supported forever.

Also the other runtimes only offer incremental improvements.

Regarding the blogposts, you don't read a lot about Node.js because it is mature software and there isn't a lot of drama or new things to talk about.

This sounds suspiciously like non-developers dumping their vibe-coded projects on online communities

> 2FA is quite simple, right?

No?

Aside from the fact that the implementation must be secure, you want for example to:

- handle accounts that have lost their second factor in an way appropriate for your business - decide what to do with accounts who don't configure it. If e.g. you want to send them authentication codes via email or SMS that's another can of worms.

Let alone the simple things such as making sure that your implementation works with the various TOTP apps

It's a mistranslation, the original quote is "Une enquête en recherche des causes de la mort est ouverte afin de déterminer l’origine du décès, aucun élément suspect n’ayant été découvert sur place par les services primo-intervenants. Les investigations sont en cours", which translates to "no suspicious element was found", not "no suspect was found"

> the funniest part of these AI detectors is that if I were to upload any of einstin's paper's they will all be flagged as AI-written.

Have you tried doing that or even read the article?

The article says that their detector flags 0.4% of pre-AI papers as AI-written.

If I paste the first page from this paper (https://www.fourmilab.ch/etexts/einstein/specrel/specrel.pdf) in https://unslop.run/app, I get a 0% chance that it was AI-written.

> There is general agreement among participants that he has engaged in off-wiki canvassing and is not here to constructively build the encyclopedia. There is also a significant concern shared by many editors that his actions constitute calls for outing.

You have web workers, and for shared memory and synchronisation respectively SharedArrayBuffer and the Atomics namespace.

Interestingly, despite the QUERY request being safe, the RFC says it's subject to preflight requests:

> A QUERY request from user agents implementing Cross-Origin Resource Sharing (CORS) will require a "preflight" request, as QUERY does not belong to the set of CORS-safelisted methods (see [FETCH]).

As a user, I like when things appear to sync instantly and perfectly, such as in Google Docs.

As a developer, I hated the article and many of the comments I read thus far because:

- Having clients and a server properly sync and not lose data in the event of a network failure amounts to having a consistent distributed system which is not easy to do, and the commenters don't seem to have understood that

- I hate having written a long document and then losing it because the sync code is buggy, so the previous point becomes even more important.

So reading many of the things here has been mildly infuriating.

That being said, none of these people are likely affiliated with Linear, and given the overall quality of the product I'm pretty sure it works properly.

Unfortunately it's not limited to the trendy topics. For example there is a huge amount of factually wrong comments on the topic of npm vulnerabilities. I'm sure it's the same on topics I know less about.

> The app would look up in both databases. If it exists in any, there would be a session.

And if you find the session with differing values in both databases, how do you know which one is up-to-date?

You need an algorithm to pick which data is right, such as electing a master instance.

And that brings us back to the original discussion: to manage sessions (unlike caches) in a highly available way, you need to setup HA (or reimplement it, which obviously is a bad idea). You can't read round robin from multiple non-HA instances.

Redis is used for plenty of things, not just memory caches.

For example if you use it for session storage, you can't have your application read from a random instance that may or may not contain the session.

Yes (assuming they're doing frontend dev and including the resources from the page). The code is fetched and executed from the browser, so It'll have to escape the browser sandbox to do something nefarious.

It works when the phone is in landscape mode.

I think the idea is that a site has no use for the status and address bars in portrait mode since the areas are already filled with controls.

> It runs code that Node et al can't run

What kind of code can't node run?

The problem with crappy frontend code is not only the maintenance. It's that stuff such as responsive design, accessibility or cross-browser compatibility that work nearly for free with elegant code won't work at all.

> Made me wonder why the packages even need build scripts

As the name implies it's for building stuff. Most (all?) packages that use C++ FFI with node-gyp need it. A popular package that needs it is re2.

Many newer packages bundle prebuilt native code as transitive dependencies, so build scripts are less needed than before.

The figure is likely wrong.

My Mac is currently using 9GB of RAM including 6.5GB of cached files with Safari and a few other apps opened. They likely forgot to subtract the cache from the used memory.

> it used to be that projects that pinned deps were called out as being less secure due to not being able to receive updates without a publish.

This is still the right advice for libraries. For security it doesn’t matter a whole lot anymore as package managers can force the transitive dependencies version, but it allows for much better transitive dependency de duplication.

For non-libraries it doesn’t matter as the exact versions get pinned in the package-lock.

> Yes, you can lock deps in NPM/Cargo/etc. but that's not the default. It is the default in Go.

How is it not the default in npm?

I'm not sure what to make of the graph.

On the one hand the acquisition of GitHub may have caused the availability to be worse.

On the other hand, the 100.00% availability before the acquisition looks suspicious, wondering if it's not just the status page being better updated.

(I'm aware of the recent availability problems with GitHub, but on the graph the problems start in 2020 and don't seem to worsen significantly)

Why not use swarm? On a single node it isn't really more complicated than compose, and you get scaling and rolling deployments.

enums and decorators mainly. There are also subtleties such as having the ts file extension in imports. Also imports aren't transpiled in cjs so you need to need es modules.

I'm using it in my projects with no issues.

The reply looks like it was written by an LLM. Not that this excuses anything.

The explanation is at the end of the article: another GoDaddy customer asked for the transfer of a similar-looking domain name, and they transferred the wrong domain.

> 1.On a system that is handling 10k concurrent requests, the 10GB of RAM is going to be a fraction of what is installed.

My example (and the c10k problem) is 10k concurrent connections, not 10k concurrent requests.

> 2. It's not 10GB of RAM anyway, it's 10GB of address space. It still only gets faulted into real RAM when it gets used.

Yes, and that's both memory and cpu usage that isn't needed when using a better concurrency model. That's why no high-performance server software use a huge amount of threads, and many use the reactor pattern.

> Why is reserving a megabyte of stack space "expensive"?

Because if you use one thread for each of your 10,000 idle sockets you will use 10GB to do nothing.

So you'll want to use a better architecture such as a thread pool.

And if you want your better architecture to be generic and ergonomic, you'll end up with async or green threads.