skysight-inc/HackerNews huggingface dataset:
> non-blocking

What is your program going to work on while it waits for the task? Usually nothing. You need to read some data before analyzing it, etc.

While you wait the OS can switch to other threads.

The only question here is whether you want to return that time to the operating system or to your language runtime.

> they’re just hiding the complexity

async/await feels helpful because you can write normal code again! If else, for loops, etc.

Oh wait that’s also what the UNIX operating system does. It abstracts away all this blocking and context switching so you can write normal code.

> If adding async to a function is too much

The authors point is a good one. You essentially have two languages and classes of functions. The regular version and the async version. Lots of duplication and a tendency for everything to become async.

> a skill issue.

I think you don’t understand process scheduling.
Twitter is owned by the CEO of Tesla who has gone insane and has turned Twitter into his own little yellow-journalism platform that he has flooded with liars and used to amplify lies.
"Simple flaw" in session handling caused Path of Exile update to be delayed
"The constant that represents the length of an account name used in the account session was still accidentally using an old value, before we added the discriminator. If a player logged in with an account name longer than 27 characters then it would result in an exception being thrown when trying to copy the account name into the account session."

Again, the delicate art of string concatenation.
need no, but it could be useful. Not a requirement, but a very “nice to have” property. It would reduce certain confusions in some end users, as well as being handy for us techie types.

Often you don't care that the current batch of processes are using 100% of what the CPU cores they are assigned to can do at current clock rates, what you want to know is how much is left available, so you can add more work without slowing any existing tasks down much.

It used to be, back when CPUs didn't have low & high power cores and always ran what they had at the same speed, that %CPU shown in various OS displays was a reasonably accurate measure of the impact of a process that could easily be used to judge optimisation success (getting the same done in less hardware effort) and scaling success (getting the same done in less wall-clock time by giving more hardware to the problem or improving parallelism to make better use of what you already have).

These days it is more complicated than most assume at face value, and you have to be a lot more careful when assessing such things to avoid incorrect assumptions leading to wrong decisions. It would be nice to get back to the previous state of affairs, in terms of a given % value meaning something more fixed. Of course that is not as practical to achieve as naively stating the problem might suggest: for a start you can't really state what 100% is because in many cases the maximum clock might only be achievable for very short periods before thermal throttling kicks in. Maybe if there is a “minimum maximum”, below which we know the throttle won't go, we could state that as 100% and display more when the heat limit is not taking effect, but I expect that really would confuse end users (I have memories of confused conversations when multi-core CPUs became common, when people saw displays of processes using ~200%, with that meaning ~100% of ~2 cores).
The difference would be that you still can call the function without await.

So this would be possible:

async function f1() {
f2();
}

function f2() {
await fetch('something');
...
}

Instead of having to async each and every function and await each and every function call:

async function f1() {
await f2();
}

async function f2() {
await fetch('something');
...
}

Which is what TFA complains about and what indeed is a pain in the ass.
"the syntax for kicking off dozens of IO requests and collecting all the results is trivial."

Please show me this trivial code, assuming I want to process 12 requests in parallel at most (and always processing 12 at the same time until there's non left to process).
Germany effectively banned broker fees in 2015 with the "Bestellerprinzip": the person who hired the agent pays for the agent. In most cases, this means the landlord. The fee is also capped to 2x the cold rent (before utilities).

You also can't charge an agent fee for merely giving someone access to a database, and you can't be both the agent and the landlord, nor the agent and the previous tenant.

Unfortunately, the difficult housing market ended up creating all sorts of other bribes. The most common is the previous tenant selling their furniture for an exhorbitant fee, or straight up requesting a bribe. These are obviously illegal, and you would be entitled to keep the apartment even after getting your money back in court. However rights are of little importance if you don't have the time/energy/means to enforce them. It's also a bad way to start a relationship with a landlord.

German law is firmly on the side of tenants, but sometimes the greed is just too strong, and there is an endless supply of applicants who are willing to compromise.

More info here: https://allaboutberlin.com/guides/housing-scams#scams-by-lan...
The event loop behind async await is completely equivalent to thread scheduler.
> Brixton riots.

That was more than 40 years ago. I was wondering whether bringing up 2011 might make sense (since it was over 10 years ago, the riots weren’t as politically motivated etc.) but this is just something else..
Languages with async/await do usually give you a way to bridge between async and sync code, but generally through a function (like this one [1] in Python) rather than allowing you to await from sync code. The problem is that sync code isn't being scheduled by the event loop. You need to use a function that's aware of the event loop's internals and can schedule your coroutine, and use a rendezvous or another synchronization primitive to wake up your sync code when the coroutine is done.

One could imagine a language where an await from sync code was syntactic sugar for such a function call, but generally the async/await syntax serves as a way to deliberately segregate your sync and async code. So that would defeat the purpose. At that point it might make more sense to design the language like Go and make everything async. (Preemptive runtimes like Java's virtual threads are another option.)

There was a good blog post I want to link here where the author argued that async/await is making explicit the fundamental property of some functions being expensive, as a counterpoint to TFA, but I haven't been able to find it again. But they made the case that expensive operations are fundamentally viral, and async/await was only making this explicit and wasn't unjustified overhead as some argue.

[1] https://docs.python.org/3/library/asyncio-task.html#asyncio....
Experimenting with creating semantic chunks of large podcasts. Got the following chunks, https://gist.github.com/nutanc/a9e6321649be5ea9806b4450b0bd6...

Dwarkesh has 18 splits. https://www.dwarkeshpatel.com/i/151435243/timestamps

I got 171. So roughly 9 context discussions in one time stamp.
Hi Francois,

any chance to work or at least intern (remote, unpaid) with you directly? Would be super interesting and enriching.
Consistency is the hobgoblin of minor planets
The closest open-source alternatives to Notion and Miro
Attemtps at Immutability with Dataclasses in Python
Zero-Copy Reads in Rust
Relevant. I almost invariably think of this post when discussing federation, openness, etc.

https://signal.org/blog/the-ecosystem-is-moving/
Evolution: optimization done by selection, result is the DNA, that does amazing (we can't match that with traditional programming) things but it's bloody hard to decipher.

Neural network: created via training, does amazing things but (this is the area my knowledge is too small) it's bloody hard to decipher why is it doing the thing it does.

"Traditional" programming: you can (as in article) explain it down to the single most basic unit.
And that new solution will have only 70% of cups' features 15 years in with tons of gotchas in everyday use cases, like wayland
CSP is simpler. Simpler is easier to get right.

I used to write a lot of asynchronous servers in C up until a couple of decades ago. I found it easy. Most people didn't. We have better ways of doing things today.
The article complains that async/await 'infects' all the code that touches it and forces the callers to use async/await too.

But isn't the same true with go channels ? If you want to asynchronously interact with a channel (that is, without blocking the main thread), you have to do it in a go block and the caller has to do the same and so on ?

Promises behave similarly - must wrap your code in promises all the way.

These constructs are alternatives to the good old callbacks, which force you to write your code inside callbacks, thus 'infecting' everything and leading to callback hell.

This 'cascade infection' effect is due to the inherent nature of things happening asynchronously, which contradicts the synchronous program flow inside a thread, so when the async event terminates, the program has to jump to a handler in order to process the results.

In the end it's a matter of taste imo..
I mean, just look at https://milksad.info for what some argue is a very long game supply chain attack. Intentionally bad entropy in the tool recommended in Mastering Bitcoin
Hey everyone! Author here. Just saw a lot of traffic from HN. I'm happy to answer questions. :-)
Lots of the claims about Gwern in the intro are exaggerated.

Gwern is an effective altruist and his influence is largely limited to that community. It would be an exaggeration to claim that he influenced the mainstream of AI and ML researchers -- certainly Hinton, LeCun, Ng, Bengio didn't need him to do their work.

He influences the AI safety crowd, who have ironically been trying to build AGI to test their AI safety ideas. Those people are largely concentrated at Anthropic now, since the purge at OpenAI. They are poorly represented at major corporate AI labs, and cluster around places like Oxford and Cal. The EAs' safety concerns are a major reason why Anthropic has moved so much slower than its competitors, and why Dario is having trouble raising the billions he needs to keep going, despite his media blitz. They will get to AGI last, despite trying to be the good guys who are first to invent god in a bottle.

By the same token, Dwarkesh is either EA or EA adjacent. His main advertiser for this episode is Jane Street, the former employer of the world's most notorious EA, Sam Bankman-Fried as well as Caroline Ellison. Dwarkesh previously platformed his friend Leopold Aschenbrenner, who spent a year at OAI before he wrote the scare piece "Situation Report" made the rounds. Leopold is also semi-technical at best. A wordcel who gravitated to the AI narrative, which could describe many EAs.

People outside of AI and ML, please put Dwarkesh in context. He is a partisan and largely non-technical. The way he interfaces with AI is in fantasizing about how it will destroy us all, just as he and Gwern do in this interview.

It's sad to see people who are obviously above average intelligent waste so much time on this.
> Doing blocking IO together with UI code is pretty bad in general though.

Non-blocking IO without multithreading doesn't require async/await though, all operating systems have had non-blocking IO functions for decades, they just never made it into language stdlibs.
I made a tool in Java recently where I was expecting relatively untechnical people to wind up using. Decided to check if there was a version of Java already on a Windows 10 tablet I've had but not really used and it had 8 on it so I developed to version to minimise the need to guide people through installing a newer version.
That's why they pay us the big bucks.
Ah, OK, it is all static RAM? Ouch...
The problem are incentives. There are monetary incentives to create whatever technology you can, because you can, and thats the way you earn money. There is zero incentive to consider how your technology might be abused.
MassiveFold: Reducing AlphaFold's computing time from several months to hours
I misread your comment. It wouldn't make sense to have a non-async sleep in a browser, as it is an event-loop based primarily single-threaded JavaScript runtime.
People kept up bringing this argument since the very beginning when people already asked for this feature. This used to be the most upvoted request on AWS forums with AWS officially acknowledging (back in 2007 IIRC), "We know it's important for you and are working on it". But they made a decision not to implement it.

The details don't matter, really. For those who decide to set up a hard cap and agree to its terms, there could be a grace period or not. In the end, all instances would be shut down and all data lost, just like in traditional services when you haven't paid your bill so you are no longer entitled to them, pure and simple.

They haven't implemented and never will because Amazon is a company that is obsessed with optimization. There is negative motivation to implement anything related to that.
Nice writeup - Wow your broker fee was crazy high 15%.
I paid 3% when I sold a $5M business in the UK.
Same, what point does the post serve? And it's not like Keras is the hottest thing in DL world.
SQLite Index Visualization
Most of the time you can just buy an expired domain name tied to a js include or dependency maintainer email address and you now have arguably -legal- ability to publish any code you want to thousands of orgs.

Plenty of expired npm maintainer email domains right now. Have fun.

I have done it twice to bring exposure to the issue. Seemingly no one cares enough to do the most basic things like code signing.
> Worse than the Fujitsu Horizon system that lead to deaths due to stress and suicide, innocent people being put in jail etc...?

Horizon had really bad bugs, yes - but it wasn't the software that caused the cover-up or the miscarriages of justice: it was the management of (then-)privatized Post Office Ltd that decided they could not afford the risk of losing big government contracts if any word got-out that the system was making fundamental ledger errors. Most of everything else can be blamed on the sheer separation between the devs and the actual end-users: these problems could have been caught and fixed if the Horizon tech-support people weren't 100% subordinate to upper-management: if I learned that our support people were using phone-scripts that were as bad as the PO's I'd threaten to resign).

(though I'd argue the real fundamental problem here wasn't technical, nor managerial, but a simple consequence of the UK's entrenched class-system: subpostmasters generally don't read Classics at Oxbridge, which means in the eyes of the establishment that they're probably the ones at fault)

I'm not mad at the ICL/Fujitsu devs - they were severely understaffed (I gather it was literally just 4 people?), but I am disappointed (and in a state of disbelief) that they evidently didn't have any devs competent enough to know how to design a transactionally-safe retail POS system in the first place (and P.O.S. is the word...): hiring and retaining good people would have avoided this episode entirely (...though no-doubt something else would have led to a similar management scandal eventually - it's in the nature of almost all large UK businesses at this point.
But most windows 98 era Ui programs were 1 or 2 threads…. You just handle events in order in a loop.

It works and is far more responsive than what we have today.

> Disks are certainly not quick enough to have File.Delete(...) be blocking

What if you invoke a delete and then it fails and you want the user to respond? What will the state of your UI be when that happens?
As in hard to get the implementation right.
It isn’t consistent, but a lot more people can fluently read “B” for billion rather than “G” giga and understand 10^9. The SI prefix “k” is sufficiently used that it is understood.
> Almost no level of accidental spend is worth creating downtime or data loss in a critical application.

That feels like a bit of a red herring — if that was their ethos, then you'd _have_ to choose burstable/autoscaling config on every service. If I can configure a service to fall over rather than scale at a hard limit, that points to them understanding different their use cases (prod vs dev) and customer types (start-up vs enterprise).

Additionally, anytime I've worked for an enterprise customer, they've had a master service agreement set-up with AWS professional services rather than entering credit card info, so they could use that as a simple way to offer choices.
So are we supposed to stick with the clumsy inelegant languages that have become mainstream forever, or can we hark back to more elegant designs?

I mean, by that logic, languages like Rust and Golang should never have taken off. Yet we see improvement due to their invention and adoption. Limiting programming language design and theory will rob us of a lot of potential improvements we could achieve at some point.
Every so often, I'd get a random bill from AWS totaling to a few cents. No idea where it comes from and it's not worth the non trivial effort to find out about it. Just another reason I avoid AWS unless necessary.
Context matters.
In the context of the wider web, I don't think Firefox matters anymore.
As others have said at this point, S3 hardly counts as new tech anymore.

But even if you disagree, S3 is conceptually super simple: put binary blobs, get binary blobs, delete binary blobs. I trust the blobs to be there when I need them. I don't have to think about storage size at all, maybe not even backups (depending on use case).

I still have to worry about network, but that isn't really that much different from disk access that can fail.

So yeah, I think S3 counts as boring. :)
Haskell has significantly more powerful abstraction capabilities than your average async/await language though, making coloring less of a problem.

Also in Haskell you can only perform IO (aside from unsafe IO I guess) inside the IO monad, potentially making the abstraction worthwhile, this is not the case in many other languages.
Is every problem you see so insurmountable?

In the olden days if we spotted a customer ringing up a colossal bill, we would tell them. These huge Amazon bills are fast but still multiple days. They can trivially use rolling-projection windows to know when an account is having a massive spike.

They could use this foresight to call the customer, ensure they're informed, give them the choice about how to continue. This isn't atomic rocket surgery.

"Oh but profit" isn't an argument. They are thousands of dollars up before a problem occurs. The only money they lose is money gained through customer accident. Much of it forgiven to customers who cannot afford it. It's not happily spent. They can do better business.
By checking what resources you are spinning up and double checking everything has been removed after you're done. I have used AWS for small projects many times and have never been hit with a surprise bill. The platform is built for actual customers, not your hello world app.
It's becoming increasingly hard to tell.
Trying to do productive work via a keyboard on a bike isn't going to catch on. A walking desk is better for that. I've had the idea of creating a custom game controller on the handle bars though, in a similar setup to this to play some simple games.
No "they" pay you to ship features.
Keras is now standalone and multi-backend again. Keras weights files from older versions are still loadable and Keras code from older versions are still runnable (on any backend as long as they only used Keras APIs)!

In general the ability to move across backends makes your code much longer-lived: you can take your Keras models with you (on a new backend) after something like TF or PyTorch stops development. Also, it reduces version compatibility issues, since tf.keras 2.n could only work with TF 2.n, but each Keras 3 version can work with a wide range of older and newer TF versions.
Yes, exactly! There's not much new here. :D
Are you mad because everybody is down voting your 42133422 post to shit, so you're down voting everyone who replied you? Don't do that, because it will only give you more down votes.

> it involves less moving parts

Every sane person who experienced a few server updates will not put out claim like that. One day you ran `apt upgrade -y`, minutes later 30% of your clients PHP website somehow went down? "less moving parts"?

In fact, Docker was invented to address this exact "it worked on my machine, why not yours" problem, by actually introducing "less moving parts".

> cutting corners just because "this will run in a container, so they can just add another HTTPS terminator" is just carelessness IMHO

Stop trying to misrepresent anything. No one is trying to solve a problem by wrapping HTTPS terminator with "another HTTPS terminator". Also, for real, how can you terminate HTTPS twice?

Also, from your another post:

> Traefik plus my service is two layers. My service has a DB hidden behind it, it's three layers. I put a VPN in front of it, and now it's four.

Why stop there, if you start from user's keyboard as a layer, then there's 5, and screen 6, then countless Internet cable and routers. Man! so many layers, it's crazy!

Also, that's not how you structure things. You have a reverse proxy, and then a service, 2 layers total.

And VPN? Oh boy you'll probably be surprised that Docker has cross-node communication built right in (https://docs.docker.com/engine/network/drivers/overlay/), so you don't even need VPN to connect to your database.

Alright, alright, please, just admit that currently containerization is not a technology you can correctly take advantage of, and then you go ahead and learn more about it. It will be an useful tool for you, as it did for many, I'm sure.
The Guardian, note, isn't a social network, it's a newspaper. The idea that social networks and newspapers should be held to different standards is reasonable, because they are different things. It is _legal_ for Carface to use Twitter to promote ol' minihands, but, yeah, I mean, not everyone's going to like it and some people are going to leave due to that (or due to many other problems with Twitter over the last two years).
I think boring is mostly a bad terminology for stable in these sort of arguments. Which means you get to actually focus on doing work. This author is apparently a fan of Go as an example of what they probably consider a “boring” technology and from that article it seems they came from Python. I think that speaks volumes about how they work with technologies that don’t change very often, because they are designed to be simple to use. Well maybe not Python if you allow it to go crazy, but if you actually know the difference between looping over a List and using a generator you probably do some very boring Python.

I think it’s similar to why a lot of places use Ruby on Rails, Django and the likes. They work, and they work well. It’s why people use Debian. It’s to lead relatively uneventful lives as far as the underlying tech goes, which is “boring”.

In my experience you’ll find far less attachment to specific technologies in this crowd of people. They like their stable tools but they won’t preach to you about a specific tool, more so about how choosing something that is simple to work with because it just works is nice. We do it in practice, we use C and we didn’t go onboard with Rust. We use a little Zig but only when it’s completely interoperable with C. In 5-10 years when Rust or Zig are more mature (and boring) we may pick them up again. Well I probably won’t be here by then but I’m sure you know what I mean. Until they get boring, however, we’re just going to use C. I don’t think C is better than Rust and I don’t think you should necessarily copy us, but for us C is “boring” and Rust isn’t.