IceDane

Also famously terrible. If not for the walled garden and the fact that anthropic can take away our ability to use custom harnesses any day, I would not be using CC. Given some of the features they add I've also started to suspect that their models are making product decisions. Not necessarily intentionally, but more in the sense that I think their engineers just let their models build and add whatever it feels like is a good idea to the codebase and then they just publish that.

Everything Steve yegge has done has been trash. That's why nobody is talking about beads or gas town. It was clear even in the beginning that it was a borderline AI-psychosis-fueled trash fire.

There's a good way and a bad way to use tools. My suggestions were based on my extensive usage of the tools in question.

It has to be both. You can lay things out in memory so they are tightly packed together and thus ostensibly cache efficient but that doesn't help you if you index into that data structure in such a way that every new index loads a new cache line.

Stop using compaction. Stop treating sessions as something you keep alive for weeks. Set up a proper workflow for handing off work and start handing off well before maximum context is hit. It's less efficient, slower and more costly to constantly be sitting at high context and compaction is just not good.

But push is not for use in production? It's for development. You generate a single custom migration that sets strict, apply it, and then you can use push as you want (during development, not for deploying actual changes to your database)

It's really weird to me how the SQLite author is clearly a very smart guy and talented developer and then his argument against type safety effectively just boils down to

> But I do not recall a single instance where the bugs might have been caught by a rigid type system.

Which is a shame. Of course the author writes more than this, but this is IMO largely the gist of the argument. At this point it's beginning to feel like this is mostly a sort of stubborn sunken cost fallacy, where they've been arguing this for so long they can't take the "hit" of agreeing to change the defaults.

But only just. It doesn't really replace graph databases. It's mostly a slightly more convenient ways to write certain kinds of queries, but it doesn't come with anything else you might expect from a graph database.

Unfortunately AGE is very immature and optimized even simple traversal queries rather poorly.

You can output assembly with any toolchain, yes. But there's no runtime, at least if you mean in the sense that the code is executed by a runtime.

Why not just do like.. actual engineering, and stay in control of what the LLM builds?

Why on earth would you deliberately choose to do whatever the fuck it is you did with the scroll and the animations for each paper when scrolling through the landing page? What are those animations supposed to be? I use firefox but I also visited on chrome, and the page is even more broken there. Scroll doesn't "take" unless I scroll hard enough, otherwise it bounces back. But on chrome, at least, it seems like the animation for each paper is clearer - it's supposed to be animating the scale of the paper as you scroll to it.. but it seems that your background animation is lagging everything so much it just doesn't work.

Slowly but surely dynamic programming proponents discover the value of statically verifiable correctness. Who'd have thought?

Martine just straight up sucks.

Vendoring your components gives you the best of both worlds. You get a full component library but retain the ability to modify them as you want.

Your AI agent claim doesn't make any sense either. When upgrading normally your component just gets rewritten on disk. When switching from radix to base ui, a more comprehensive approach is needed.

But Kubernetes isn't postgres or ruby or containers. It's the orchestration service. Your comparison doesn't make sense.

This example is not only wrong for what you intend to demonstrate but even if it wasn't, it's not problematic. In typescript the proper way to do this is using branded types and exporting only the safe constructor, making anyone who wants to violate the invariant go out of their way, which is no different from the situation in any number of programming languages or scenarios.

  declare const brand: unique symbol;
  type NonEmptyString = string & { readonly [brand]: 'NonEmptyString' };

  // the ONLY non-cast way to produce one
  export function nonEmptyString(s: string): NonEmptyString | undefined {
    return s.length > 0 ? (s as NonEmptyString) : undefined;
  }

  export type { NonEmptyString };

If the goal is to convince me not to use this: mission accomplished. This looks awful on mobile.

The examples for the M5 exploit and the other stuff immediately make me think that the author is an idiot. I'm not calling you an idiot - I'm saying that if I were to read a technical article and the first thing I'm presented with is an absurdly stupid emoji-person animation that makes no sense and has no purpose and adds literally nothing, I would just immediately exit that website. This goes for all of the examples, and the fact that it's all so clearly written by LLMs isn't helping either.

Nobody in Denmark actually thinks of Lars Andersen as any sort of serious privacy activist. He is a drug-addled moron who just happens to dabble in those things. He's an idiot and contributes nothing of value to society.

Like the sibling said: CORS is the relaxation of default security features. It's even in the name: Cross-Origin Resource Sharing.

> According to my rough computation (N=1), a Claude Max 20x at $200 gives you access to around $8k

According to my own personal `cc-usage` script, I'm just about to hit $15k in the past 30 days, and that's about half 5x and half 20x. And I'm not someone running openclaw or letting my agents spin around 24/7 - this is just very active agentic coding, where I'm constantly involved.

> I don't see an asymmetry in the abstraction. Both vectors and maps are associative structures - you can assign a key to a value - the only difference is that vectors have a more constrained keyspace (i.e. ordered, consecutive integers starting from zero).

The asymmetry lies in the fact that it's an overloaded function that's supposed to do the right things every time, but in some cases, it does what is arguably the wrong thing, silently, and in others, it refuses to do the wrong thing and fails loudly. It's better that it fails loudly, of course, but the point is that the ergonomics of the abstraction is lessened because you can't just assume it will work. You effectively have to keep the types of all the things involved in your head and/or trace them to ensure that you don't run into a crash.

> We can see that the return type of this expression is obviously an integer, but what is the type of m? How do we type m such that (:number m*) can be inferred to be an integer by the compiler?

This is trivial in TypeScript. You can see it in action here: https://www.typescriptlang.org/play/?#code/MYewdgzgLgBAtjAvD...

  const m = { name: "weavejester", active: true };

  const mStar = { ...m, number: 3 };
  //    ^? const mStar: { number: number, name: string, active: boolean }

  const x = mStar.number;
  //    ^? const x: number

> This is the ultimate problem with static type systems: you're trading capability for safety. If you're programming within a static type system, there are options that are simply not available or feasible to use.

This is just not true. It's true for some certain specific static type systems, but not true in general, and that brings me back to my original thesis: You just need a sufficiently capable type system with the right properties - structural/row polymorphism, ish, plus type inference. And also my Haskell point: it doesn't have to be an incredibly complicated type system that is beyond mortal ken. TypeScript is already doing this and it's arguably one of the most used programming languages on earth.

It's not about "knowing" anything. It's about admitting that humans are fallible meat computers that can't hold invariants in their head across thousands or millions of lines of code and possibly an exponential number of interactions. It's using the technology we are capable of building to help us because it's the obvious thing to do. The notion of dynamic typing as an attractive programming model hinges entirely on the hypothesis that it lets you somehow express things that you need or want to be able to express that static typing prevents you from doing, and that is demonstrably false. The `assoc` example above is a perfect example.

The problem with your counter-argument is that it hinges on a false premise: That you need or even want a function like `assoc` which is polymorphic over everything. It's an extremely overloaded function which does a lot of things at once, and in many circles and arguably in general within the realm of software design, this is considered a smell.

In practice, what you want is something that allows you to do this safely for the concrete type you're working with. If you want an abstraction that covers all of it, there are ways to achieve this in a type-safe manner, such as traits/type classes. Even in clojure, you're not working with everything at once all the time. You are working with a record, or a vector, or whatever. The fact that you can use one function for all of them is mostly just needless cleverness. In Clojure, you have to keep the type of the data you are working with in your head at all times, because even though `assoc` "just works" for many cases, that's not true in all cases. It will happily insert an integer key into a record without issue, which may or may not be waht you want. But you can also try to insert an atom key into a vector, which then crashes loudly. This is clearly an asymmetry in the abstraction.

Moreover, pointing out that Haskell cannot do what you'd want to do in this case doesn't make a lot of sense. I mentioned Haskell precisely because its type system is extremely powerful and complicated to understand for a lot of people, but still doesn't achieve the kind of flexibility we are looking for - it lacks row polymorphism.

To answer your actual question: Typing a function like that for the individual cases is bordering on trivial in a language such as typescript. For the record case, you don't even need it, because in practice, you get the correct type inference for free by just spreading one object into another.

"Until you get better" is such an arrogant take.

It's not just about skill. It's about maintainability, ease of refactor, and modeling invariants in your code in a way that they can be checked by the machine (the compiler) without every single developer having to maintain them in their head.

Clojure even knows this is an issue and many people use `spec` to sort of retrofit static typing.

Dynamic typing was, is and always will be a mistake. There is nothing you can do with dynamic typing that you cannot do with a sufficiently powerful static type system - and it doesn't have to be something absurd like Haskell's. You basically just need structural typing and type inference and some type-level programming constructs.

The worst part about Clojure is the community. Rich Hickey has cult-like status and the only thing clojurians can do is parrot his inane commentary.

Effect is unreasonably effective. Pun etc.

The problem with these concepts is a) they are completely opaque to the common chud programmer and b) they are just not available to people in languages that anyone actually uses. There are a bunch of effect libraries in Haskell, even special efforts to make them work better in GHC, but it's nearly all wasted effort because it's just academic circlejerk.

Effect brings these capabilities to the masses by implementing them in the most popular programming language on the planet. Obviously, there is quite a learning curve -- it is essentially a programming language unto its own inside another programming language -- but it's doable. I've onboarded juniors with close to 0 FP experience into an Effect codebase. The guardrails help a lot. The language server which helps with best practices, the type errors themselves help quite a lot.

Arguably the best way to do Effect would be a separate programming language, but that would just give us the problems Haskell has: nobody would use since there would be no ecosystem, and there will be no ecosystem since nobody would use it.

Is this really a position you want to take in public with your real name and identity and everything plastered over your profile?

No.. that's not the only reason.

Global state is bad because it makes it hard to reason about your system. The global state can affect any part of it, or, focusing on the inverse which is probably better applied to global styles, any part of your system can depend on the global state.

It's also weird to say "global styles are not mutable" - you're right, they're (generally) not mutable, at runtime. But they are mutable in the sense that your developers (you, or your colleagues, or someone in 3 years maintaining your code) can mutate them, and if large parts of your system are implicitly dependent on the CSS cascading properly and so on, then those changes can have unintended consequences.

Of course, that can also apply to tailwind, to some extent. A developer can change a class (custom or otherwise) or the configuration - but at least it is very clear what is being changed and what parts will be affected (just grep).

This doesn't make any sense to me.

The problem with this dev's approach is not AI, it's their use of it. They didn't ensure that the architecture made sense. They didn't look at the code and get a "feel" for it. They didn't do the whole build stuff, step back, refactor, rinse and repeat dance. The need for that hasn't gone away; if anything, it's even more important now. Because you can spit out code 100x faster than you could before, your tech debt compounds 100x faster. The earlier you refactor, the less work it is.

I usually give the agent a solid idea of what I want, often down to the API interfaces. Then every now and then, I'll go through the code and ensure that everything makes sense, and that I'm not just spitting out code that works, but building a codebase that scales.

Runs smoothly for me in Zen (FF) on Linux.