rockmeamedee

[delayed]

It's very very important to note that there was an existing 2025 arxiv preprint that had a >66% proof assuming some weak condition, and this result removes that weak condition.

It didn't do this whole 41.6->67.2% jump by itself, humans had done most of the work and it came in at the end and found a way to remove the condition. Impressive, but not as massively impressive as when it sounds like it did the jump by itself.

This isn't goalpost moving, it's clarifying what exactly happened bc at first I thought it had made the jump by itself. The blog post is written in a technically correct, but misleading way where it takes credit for the whole jump.

I hate this. The style of LLM-written prose is unbearable, and I found several mistakes. This is "dazzle them with bullshit details" with no understanding behind it.

I assume the book this post is marketing is also AI slop too and I lost respect for its author.

For Bun to not have torched its reputation among its users, it would have had to publish this blog post _before_ pressing merge on that PR.

That's what underlies most of the vitriolic reaction to the events, it was done really in a really rash way.

All they had to do was a)not gaslight people about your intentions when they found the branch b)publicly post the intent to do this, and then c)publish a doc like this one right before merging, ideally leaving the branch open for like a week in case anyone in the "community" finds things to fix.

Then those UB/Miri issues others found would have been "yay collaboration" boosts instead of negative issues that prove that the approach was risky/unthoughtful.

If you're going to cross a rubicon, maybe tell people a)that you actually want to do it, b)why you want to do it and c)what it looks like after you've done the rewrite.

Reminds me of the "mathematical proof that there is no least interesting number". Because if there was a "least interesting number", that would make it interesting: it would have this unique property of being "the least interesting".

Here each candidate for "least interesting art" loses that property in much the same way, becoming interesting by being not_viewed_much.

I don’t understand. Gitoxide exists and is great.

It might have missing pieces, but it’s easier to vibecode any needed networking additions to Gitoxide (which is maintained) than to just go and burn tokens trying to clone all of git again.

Git wants to add Rust. Gitoxide is a multi year project that’s going to be more maintained than an ad-hoc “it says it passes the test” vibeclone.

I’m not even against vibecloning things when it’s useful, but this shows no benefits. Git is a beloved tool that few people dislike, it’s not like vinext (people disliking the vendor lock-in they have with nextjs).

Also execs should keep in mind that “we burned thousands of dollars on tokens to re-create this beloved software so we can have our own copy”, even without the copyright/licensing argument, just isn’t something positive that the community will react positively to.

It doesn’t feel nice to see your favourite works cloned for no benefit. We’re past the “it was an experiment to see how far AI can go” stage now.

[delayed]

What does this mean, that you can take Kimi and RL finetune it a little more and blow the big AI shops out of the water?

Would this have been extensively fine tuned, beyond what Anthropic/OAI would do themselves?

I guess this is Cursor's own benchmark, so you can finetune on your own dataset and get better results on your own specific tasks I guess.

I had no idea, but this "wiggle" is required for an optimal approximation, it's called the "equioscillation property" [https://en.wikipedia.org/wiki/Equioscillation_theorem].

For a polynomial P (of degree n) to approximate a function F on the real numbers with minimal absolute error, the max error value of |P - F| needs to be hit multiple times, (n+2 times to be precise). You need to have the polynomial "wiggle" back and forth between the top of the error bound and the bottom.

And even more surprisingly, this is a necessary _and sufficient_! condition for optimality. If you find a polynomial whose error alternates and it hits its max error bound n+2 times, you know that no other polynomial of degree n can do better, that is the best error bound you can get for degree n.

Very cool!

I'm interested in the topic, and the book cover looks great, so I'll probably read it.

But it seems a bit "Maintenance: For Boys". The items mentioned on this page are "the maintenance of sailboats, vehicles, and weapons", and "Soviet tanks, or tricked-out Model Ts".

No mention that for millenia we were mending our clothes, cleaning our houses, maintaining our food systems.

The reason this book sounds interesting is that maintenance is systematically undervalued, and basically in our human history pushed onto women and the lowest social classes. But the marketing material seems to highlight only the "sexy" stuff like weapons and vehicles. Where's the maintenance of washing our hands, washing our clothes, cleaning our streets?

There's this artist, Mierle Laderman Ukeles, who was the "Artist in Residence" at NYC's department of sanitation in the 70s, and tried to use conceptual art as a way to highlight the work of the department and make "maintenance art" a thing. I'm interested in that kind of re-valuing of maintenance.

I bet this book will be interesting, I just don't like the framing as "Maintenance: Of Everything" since it's clearly not the whole story. Hopefully part 2 has a broader scope and mindset.

Yeah, uv is cool and a step above conda, but that business model doesn’t look very profitable…

They did say they want their thing to have understanding of the code, so maybe they’ll sell semgrep-like features and SBOM/compliance on top. Semgrep is ok popular, but if it maybe bundled into something else (like the package registry itself) that might get enough people over the line to buy it.

Private registries and “supply chain security” tools individually aren’t the hottest market, but maybe together the bundle could provide enough value. Let’s see how it goes.

yeah but they're still >50% off SFBA salaries. SFBA comp for a sr dev can easily be $200k+ (and can go higher, lots of anecdotes on here about $350k+ salaries at BigtechCos), for an EU dev scratching 90k euro is considered "good". Devaluing the dollar by 10% and increasing the price of EU salaries by 10% doesn't really change the picture.

Oh this is great! I always have this problem. I find that's one of my biggest barriers when reading queueing theory content. I'm only doing it intermittently so I don't have memorized the meanings of ρ,σ,μ,λ...

Visually I also often confuse rho and sigma, and math texts will use psi ψ and phi φ in weird fonts and I can never tell them apart.

I too made a version of this (just a small Go DNS resolver + port forwarding proxy) that lets you do a similar thing: https://gitlab.com/amedeedabo/zoxy

I used the .z domain bc it's quick to type and it looks "unusual" on purpose. The dream was to set up a web UI so you wouldn't need to configure it in the terminal and could see which apps are up and running.

Then I stopped working the job where I had to remember 4 different port numbers for local dev and stopped needing it lol.

Ironically, for once it's easier to set this kind of thing up on MacOS than on Linux, bc configuring a local DNS resolver on linux (cf this taiscale blog post "The Sisyphean Task Of DNS Client Config on Linux" https://tailscale.com/blog/sisyphean-dns-client-linux). Whereas on Mac it's a couple commands.

I think Tailscale should just add this to their product, they already do all the complicated DNS setup with their Magic DNS, they could sprinkle in port forwarding and be done. It'd be a real treat.

Fastest growing but because they participated in a pay-for-play kickback scheme [1][2]?

So that number isn't really signal. Now that they're not paying CISOs to adopt the product they're not going to be growing as fast.

[1] https://www.bankinfosecurity.com/blogs/cyberstarts-program-s... [2] https://www.calcalistech.com/ctechnews/article/b1a1jn00hc

Idk man. It's a nice idea, but it has to be 10x better than what we currently have to overcome the ecosystem advantages of the existing tech. In practice, people in the frontend world already use Apollo/Relay/Tanstack Query to do data caching and querying, and don't worry too much about the occasional overfetching/unoptimized-ness of the setup. If they need to do a complex join they write a custom API endpoint for it. It works fine. Everyone here is very wary of a "magic data access layer" that will fix all of our problems. Serverless turned out to be a nightmare because it only partially solves the problem.

At the same time, I had a great time developing on Meteorjs a decade ago, which used Mongo on the backend and then synced the DB to the frontend for you. It was really fluid. So I look forward to things like this being tried. In the end though, Meteor is essentially dead today, and there's nothing to replace it. I'd be wary of depending so fully on something so important. Recently Faunadb (a "serverless database") went bankrupt and is closing down after only a few years.

I see the product being sold is pitched as a "relational version of firebase", which I think good idea. It's a good idea for starter projects/demos all the way up to medium-sized apps, (and might even scale further than firebase by being relational), but it's not "The Future" of all app development.

Also, I hate to be that guy but the SQL in example could be simpler, when aggregating into JSON it's nice to use a LATERAL join which essentially turns the join into a for loop and synthesises rows "on demand":

  SELECT g.*, 
         COALESCE(t.todos, '[]'::json) as todos
  FROM goals g
  LEFT JOIN LATERAL (
    SELECT json_agg(t.*) as todos
    FROM todos t
    WHERE t.goal_id = g.id
  ) t ON true

That still proves the author's point that SQL is a very complicated tool, but I will say the query itself looks simpler (only 1 join vs 2 joins and a group by) if you know what you're doing.

Like a non-toy version of this: https://artsandculture.google.com/story/ar-synth/7AUBadCIL5T...

As a regular programmer, I got really into queuing theory thinking I was going to learn secrets of performance tuning, then was slightly disappointed.

But it turns out the simple parts of it go a long way! Eg at work we have a single deployment queue for a monorepo. At first approx this is an MD1 queue (deploy job takes roughly the same amount of time every time, though arrivals are actually way spikier than poisson), and realized that wait time was inversely proportional to total utilization.

While the infra team was saying “we do X deploys per day out of 4X and are only at 25% capacity”, I realized even hitting 2X would more than double the already bad wait time.

What happened is that a few initiatives were under way to increase capacity, but then out of nowhere the queue got log jammed (bc of high arrival rate variability) and we had to switch to Gitlab merge trains, which run CI concurrently on the optimistic result of merging. I wrote about it here: https://engineering.outschool.com/posts/doubling-deploys-git...

I’m planning on writing a blog post about the math of CI/CD deploy queues as G/D/1 queues.

For a programmer’s view of queuing theory and great performance testing foundations, I highly recommend “Analysing Computer system performance with Perl:PDQ” (don’t worry about the Perl, the book is very relevant) http://www.perfdynamics.com/iBook/ppa_new.html, which shows examples of queues inside computer systems and how to model them. The author has a nice little library to model different computer systems you come across.

I liked realizing that the dreaded “coordinated omission” problem in load testing (when you can only generate X rps and the server can handle more than that, your numbers are bunk) is actually when you think you are modeling an open system but you don’t have enough resources and end up seeing the closed system behaviour.

The number one thing that got me to senior engineer, and will get me to staff as I improve (though staff has more of a relationship management component) is emotional management.

Staying in a long debugging session without ragequitting and getting to the fix.

Pushing through when I feel really dumb for not knowing how a react hook works or how to test a particular feature.

Not getting bored (or recognising it and pushing through) when fixing a bug that is "trivial" but complicated.

Not getting angry when the codebase is not architected well or is hard to understand.

In every one of these situations, better emotional management has made me more productive, calmer, and I had a better outlook of the situation in the end, so my suggestions to external stakeholders about what to do next were more accurate.

And I'm still learning! I get bored and take 3x too long all the time.

This is maybe an exaggeration, but after you learn about for loops and functions, the rest of the job is emotional management.

Ok, maybe EQ becomes important a little bit after for loops, but way earlier than you think. Maybe after 1 year of experience.

The term "crisis response" will get you info on PR crises and brings to mind the TV show Scandal.

The term you want for our field is "Incident Response", and the practice of 1)preventing them and 2)handling them 3)learning from them is Resilience Engineering. It's about investigating air plane crashes, nuclear meltdowns, errors during surgery, etc, and learning how humans keep complex systems running.

I recommend "Behind Human Error" by David Woods as a great starter there. A key insight of this field is that incidents aren't just "some idiot didn't follow the safety checklist", but often the safety checklist itself will cause the issue; at some level the errors happen because of complicated interactions between the system and even the safety mechanisms.

An interesting tech industry related document is the STELLA report [1] from a few tech companies comparing notes on incidents.

[1] https://snafucatchers.github.io/

There's apparently a bananas crunch/backstory to this, where they committed to Swift before realizing they would hit its limits, and had to come up with a bunch of this optimization madness on the fly. I guess this is the cleaned up version and the more final, stable optimizations for the company blog:

https://twitter.com/StanTwinB/status/1336890442768547845

The post says

  The new API to cast in an unsafe manner is:

  let x: f32 = 1.0;
  let y: u8 = unsafe { x.to_int_unchecked() };

  But as always, you should only use this method as a last resort. Just like with array access, the compiler can often optimize the checks away, making the safe and unsafe versions equivalent when the compiler can prove it.

I believe for array access you can elide the bounds checking with an assert like

  assert!(len(arr) <= 255)
  let mut sum = 0;
  for i in 0..255 {
    sum += arr[i];//this access doesn't emit bounds checks in the compiled code
  }

I'm guessing it would work like this with casts?

  assert!(x <= 255. && x >= 0);
  let y: u8 = x as u8; // no check

This is pretty weak.

It mentions redlining, quotes Kareem Abdul-Jabbar, but then mostly argues that Twitter's filter on Trump's tweet made it spread wider, the reverse of the action they wanted, implying they did the wrong action, or that it would not work in the future, which is pretty bad logic.

The tweet became more notable because Twitter has never done this before. It got reproduced because it was the first time Twitter did it, not because people wanted to read the "shocking tweet". If twitter were to do this often, or dump Trump, we'd stop talking about it again. Cf Milo.

And then it ends with this whole "The internet is the new industrial revolution, and that is both good and bad" thing. Kind of like, Ben couldn't stop himself from Internet Thoughtleadership for a minute. After 4 minutes of commenting on Race in America he had to go back to musing about Platforms.

I get it, you want to (and can!) tie it in to your expertise. But you just kind of failed at that.

You could talk about the huge tech titans making it worse: Amazon's Ring doorbell, the $10B JEDI contract with the DoD, Facebook's extremist groups/lack of moderation, Twitter not banning Trump the first time around, the Adtech industry in general pushing surveillance everywhere it can, to gather datapoints. Or the way tech has made income inequality worse. The homogenous makeup of the tech industry. The social construction of "nerdiness" as whiteness. The tech industry (and everyone on the Internet)'s unquestioning acceptance of the capitalist approach, and only being accessible to people with money and app solutionism.

But instead it ends with "I am hopeful there are fewer gatekeepers, and can therefore see racism more clearly now". Like, that's it?

At least put a couple links to non-profits in the footer. Doesn't this guy make a few million $ a year from his newsletter? Donate it!

This is a very lucid piece on PL adoption in general. When I think about programming languages, I do think rather emotionally (which is fine, emotions are early warning systems).

I liked the linked author's points about the pre-requisites for marketing a solution:

    It is memorable
    It includes a key benefit
    It differentiates
    It imparts positivity

When I think about the most popular languages, they do have all of these: Rust:

Memorable: very. It's basically everywhere you look Has a key benefit: going C++ fast without the C++ footguns, memory-safe, WASM integration Differentiates: Using Rust is definitely choosing a particular set of technical tradeoffs Imparts positivity: the community is known to be welcoming, feels cool, cute crab. People re-write existing software in Rust just because it feels good!

Yet Haskell has almost none of these:

Memorable: I mean, yeah, but it's not being shown to people, and I can't point to a bunch of software. Tools I know of include PostgREST, Hasura, Nix, hledger, which is better than nothing. Key benefit: Hand waving about "being more correct", unlike Rust which has reams of "Microsoft claims 60% of its bugs are memory-errors" articles, and in any case TFA's point is that this needs to be a different message because correctness isn't gonna sell it. Differentiates: This is definitely true, almost too much Imparts positivity: Not really feeling this one with Haskell. People feel good when they figure out a monad is a container & a lens is a path through a data structure, but attempts to explain to others these things feel condescending. Does Haskell even have an animal mascot? (serious question.) Also "stumps" a lot of people and people feel bad about it. There's no "import antigravity" equivalent feeling with Haskell.

This sounds pretty sombre for Haskell, though it's been an academic language a long time, and could probably stay alive that way.

One positioning possibility is maybe with the Frontend dev world becoming more and more functional and pure-oriented, positioning itself like reasonML, as a way to write and reason about declarative pure UIs. But I don't think the existing Haskell community cares too much about that world.

Idk, I'm going to just keep writing Rust and JS, the already most loved and popular languages.

https://flexi.chat, a videoconferencing app where you can have a schedule and flexible speaking formats.

For example, you can have everyone in the meeting speak one after the other (the app handles muting and un-muting the right people), then repeatedly shuffle people into pairs so that everyone gets to talk 1-on-1 with everyone else. Or have a “speed-dating” style format for the first 20 minutes of your remote meetup, before bringing everyone back to the main room for the main speakers.

Barely ready to open it up yet, using it to host daily "standups" with my friends, but going to have a few friend gatherings with it later, and maybe a local meetup. The friend gathering will have the first schedule I mentioned above; have everyone speak in a circle to catch up the group on what they've been doing, then split the group into pairs (shuffling the pairs). The meetup will have the "speed-dating" + switch to main talks.

Uses Jitsi for the hard video webRTC stuff, and then nextjs with socketio for my application.

On gitlab at https://gitlab.com/amedeedabo/flexichat.

Getting back into React and ES6, and all the amazing new CSS stuff of the last 5 years!

Eventually I want to split it off so that the logic can be in its own package, to make it easy to integrate different speaking formats into different, existing apps.

Kalman filters. The explanations always start easy and then get too confusing.

Yeah, I too am tired of projects named mean-ly. Git, dolt, LAME, Gimp... DWARF is borderline, even if it has historical reasons (being based on ELF) it's not nice to hear out of context.

Even if it's a joke on yourself, just like, why would you give anyone who hasn't heard of your project the idea that it might be mean?

You wouldn't name your pet Dumbass. Why your pet project.

It's a common thread in Incident Response & "Resilience Engineering" that preventative measures that reduce the blast of incidents are always blamed, especially if they work. Whatever ends up working to fix the incident, you should have done it sooner or it was too drastic a response. (No matter the fact that it _did_ fix the incident, outsiders will blame you that way).

One example is the Knight Capital trading disaster, where they eventually noticed (I don't remember the exact number) X minutes after the runway trading bot had been put into place, and shut it down, but got blamed for not shutting down the trading soon enough.

Can't find any links about this right now though :(