molf (u/molf) - Readit News

molf commented on Do Things That Don't Scale (2013) paulgraham.com/ds.html... · Posted by u/bschne

cjs_ac · 9 days ago

My theory is that there are three regimes: Not Scaling, Scaling, and Antiscaling.

Not Scaling is about crossing and shoring up your moat. Scaling is when your app has enough hype around it that your customers recruit new customers, and all you have to do is add new machines or shard the database or whatever to handle increased demand.

Antiscaling is when you turn into the thing that everyone hates about the modern web. Antiscaling is when intelligence agencies want to talk to you about how your chat app is used by terrorists, when cities want to licence access to your ridesharing or takeaway delivery app, when pieces of legislation are passed that are specifically designed to target your company, when you're sufficiently well-known as the founder of an app that people are making memes about you and tracking your personal movements.

You don't have to take over the world, you just have to make money. People who try to change the world often change it for the worse; just try to make something useful, and maybe the world will like it.

molf · 8 days ago

I feel this is an insanely distorted take.

How about extreme and utter irrelevance (such as after building a thing nobody wants)?

Or how about this, arguably the most common: slightly successful; nobody hates it but nobody loves it either. Something people feel mildly positive about, but there is zero “hype” and also no “moat” and nobody cares enough to hate it.

molf commented on The bitter lesson is coming for tokenization lucalp.dev/bitter-lesson-... · Posted by u/todsacerdoti

Scene_Cast2 · 2 months ago

I realized that with tokenization, there's a theoretical bottleneck when predicting the next token.

Let's say that we have 15k unique tokens (going by modern open models). Let's also say that we have an embedding dimensionality of 1k. This implies that we have a maximum 1k degrees of freedom (or rank) on our output. The model is able to pick any single of the 15k tokens as the top token, but the expressivity of the _probability distribution_ is inherently limited to 1k unique linear components.

molf · 2 months ago

The key insight is that you can represent different features by vectors that aren't exactly perpendicular, just nearly perpendicular (for example between 85 and 95 degrees apart). If you tolerate such noise then the number of vectors you can fit grows exponentially relative to the number of dimensions.

12288 dimensions (GPT3 size) can fit more than 40 billion nearly perpendicular vectors.

[1]: https://www.3blue1brown.com/lessons/mlp#superposition

molf commented on “Don’t mock what you don't own” in 5 minutes (2022) hynek.me/articles/what-to... · Posted by u/JNRowe

hynek · 2 months ago

> I’m not sure this is good advice. I prefer to test as much of the stack as possible. The most common mistake I see these days is people testing too much in isolation, which leads to a false sense of safety.

You make it sounds as if the article would argue for test isolation which it emphatically doesn't. It in fact even links out to the Mock Hell talk.

Every mock makes the test suite less meaningful and the question the article is trying to answer is how to minimize the damage the mocks do to your software if you actually need them.

molf · 2 months ago

But ultimately it suggests this test; which only tests an empty loop?

  def test_empty_drc():
      drc = Mock(
          spec_set=DockerRegistryClient,
          get_repos=lambda: []
      )

      assert {} == get_repos_w_tags_drc(drc)

Maybe it's just a poor example to make the point. I personally think it's the wrong point to make. I would argue: don't mock anything _at all_ – unless you absolutely have to. And if you have to mock, by all means mock code you don't own, as far _down_ the stack as possible. And only mock your own code if it significantly reduces the amount of test code you have to write and maintain.

I would not write the test from the article in the way presented. I would capture the actual HTTP responses and replay those in my tests. It is a completely different approach.

molf commented on “Don’t mock what you don't own” in 5 minutes (2022) hynek.me/articles/what-to... · Posted by u/JNRowe

molf · 2 months ago

I’m not sure this is good advice. I prefer to test as much of the stack as possible. The most common mistake I see these days is people testing too much in isolation, which leads to a false sense of safety.

If you care about being alerted when your dependencies break, writing only the kind of tests described in the article is risky. You’ve removed those dependencies from your test suite. If a minor library update changes `.json()` to `.parse(format="json")`, and you assumed they followed semver but they didn’t: you’ll find out after deployment.

Ah, but you use static typing? Great! That’ll catch some API changes. But if you discover an API changed without warning (because you thought nobody would ever do that) you’re on your own again. I suggest using a nice HTTP recording/replay library for your tests so you can adapt easily (without making live HTTP calls in your tests, which would be way too flaky, even if feasible).

I stopped worrying long ago about what is or isn’t “real” unit testing. I test as much of the software stack as I can. If a test covers too many abstraction layers at once, I split it into lower- and higher-level cases. These days, I prefer fewer “poorly” factored tests that cover many real layers of the code over countless razor-thin unit tests that only check whether a loop was implemented correctly. While risking that the whole system doesn’t work together. Because by the time you get to write your system/integration/whatever tests, you’re already exhausted from writing and refactoring all those near-pointless micro-tests.

molf commented on Selfish reasons for building accessible UIs nolanlawson.com/2025/06/1... · Posted by u/feross

chrismorgan · 2 months ago

> When I’m trying to debug a web app, it’s hard to orient myself in the DevTools if the entire UI is “div soup”

That’s tame. Try adding some Tailwind CSS.

After monitoring Tailwind CSS since its early days, and believing I had some pretty serious philosophical disagreements with it, I recently took an opportunity to try it out in earnest, and it is so mindbogglingly obnoxious in dev tools that I think surely I must be missing something. How do people cope with this stuff!?

If you’re not sure what I’m on about, go through some of the sites linked near the bottom of https://tailwindcss.com/. In the Inspector/Elements panel, the DOM tree is a bloated mess with a class attribute which amounts to inline styles or worse, commonly hundreds of characters long, discouraging you from using semantically-meaningful classes, and duplicating stuff enormously rather than using sane selectors; the mostly-better ones are those that have data-sentry-{element,component,source-file} attributes. The styles subpanel becomes utterly unnavigable.

(I’m not saying everything in Tailwind is bad; I think I am likely to use a limited utility styles approach more than I did in the past, and there are a couple of other things that are provoking thought in me, and I think it would be more suitable in apps than in marketing-style websites. But the total embodiment of it is not for me.)

molf · 2 months ago

Not just in dev tools; that mess is also in your source code...

molf commented on In case of emergency, break glass morrick.me/archives/10048... · Posted by u/microflash

molf · 2 months ago

The points about visual hierarchy are spot on, in particular on macOS. I think Apple has two realistic paths forward to resolve this mess:

1. Double down on the aesthetic and gradually redesign apps to improve the hierarchy. That would mean adapting UX across countless apps to serve the new look.

2. Tone down the glass effects and shadows drastically. Preserve existing app layouts without compromising usability as much. We'll be left with shimmering buttons and panels, a bit more blurred transparency than in the 'current' design language.

My guess is they will end up choosing option 2, simply because it’s cheaper.

molf commented on How we’re responding to The NYT’s data demands in order to protect user privacy openai.com/index/response... · Posted by u/BUFU

molf · 3 months ago

It would help tremendously if OpenAI would make it possible to apply for zero data retention (ZDR). For many business needs there is no reason to store or log any request at all.

In theory it is possible to apply (it's mentioned on multiple locations in the documentation), but in practice requests are just being ignored. I get that approval needs to be given, and that there are barriers to entry. But it seems to me they mention zero-data retention only for marketing purposes.

We have applied multiple times and have yet to receive ANY response. Reading through the forums this seems very common.

molf commented on A maths proof that is only true in Japan newscientist.com/article/... · Posted by u/monksdream

bananaflag · 3 months ago

Yeah, it's ironic how math is more or less the one "universal" truth, and we still long for somehow magically make it culturally dependent. I can definitely understand that temptation. Like the opposite one, e.g. the search for a "perfect" language (as in e.g. Umberto Eco's book). Both temptations are examples of a longing for an actual paradox or absurdity in the world.

molf · 3 months ago

Totally get your point, but math is still a human creation. The symbols, language, and frameworks we use are cultural, and disagreement over proofs like this one shows math depends on shared understanding, not just objective truth.

molf commented on A South Korean grand master on the art of the perfect soy sauce theguardian.com/world/202... · Posted by u/n1b0m

steveBK123 · 3 months ago

For me I always have Kikkoman in the fridge (especially because thats what wife grew up with) as the staple soy sauce. I like to dabble in having 1-2 other variants in the fridge at once, but they can tend to have too strong a flavor for some peoples taste. Or certain variants are best with certain dishes, etc.

molf · 3 months ago

This is the first time I hear about keeping soy sauce in the fridge. Is this common?

molf commented on Fast Allocations in Ruby 3.5 railsatscale.com/2025-05-... · Posted by u/tekknolagi

uticus · 3 months ago

> But most of the speedup right now is still coming from rewriting C into Ruby.

Quick glance, this statement seems backwards - shouldn't C always be faster? or maybe i'm misunderstanding how the JIT truly works

molf · 3 months ago

C itself is fast; it's calls to C from Ruby that are slow. [1]

Crossing the Ruby -> C boundary means that a JIT compiler cannot optimize the code as much; because it cannot alter or inline the C code methods. Counterintuitively this means that rewriting (certain?) built-in methods in Ruby leads to performance gains when using YJIT. [2]

[1]: https://railsatscale.com/2023-08-29-ruby-outperforms-c/ [2]: https://jpcamara.com/2024/12/01/speeding-up-ruby.html