felixfbecker

The author makes the argument that in the age of LLMs more type safe languages will be more successful than less type safe ones. But how does that support the claim that Go is more suitable than JavaScript? TypeScript is more type safe than Go: Go doesn’t validate nil pointers, it doesn’t enforce fields to be set when initializing structs, it has no support for union types. All those things can cause runtime errors that are caught are caught at compile time in TypeScript.

That is like saying the kernel/sandbox hypervisor can access those things. The point is that the sandboxed code cannot. In browsers, code from one origin cannot access those things from another origin unless explicitly enabled with CORS.

MCP doesn't force models to output JSON, quite the opposite. Tool call results in MCP are text, images, audio — the things models naturally output. The whole point of MCP is to make APIs digestable to LLMs

An SVG doesn't need to support scripting. When you load an SVG through an <img> tag for example, no <script>s run either (only if you use <iframe>, <object>, or inline in HTML5). When you serve the SVG (or the HTML it is inlined in) with a CSP that doesn't allow inline scripts, no scripts run. It's totally possible to render an SVG without scripts (most SVGs do not contain scripts) and various mechanisms for this are already implemented in browsers.

OpenAI and Anthropic respect robots.txt afaik

Microsoft contributes a lot of web standard implementations upstream to Chromium. They are not just letting Google do all the work as your comment makes it sound like. They could have chosen to do the same with Firefox, which means the reason to fork Chromium and not Firefox had other reasons.

Right, I use a browser extension that automatically declines consent.

On my personal homepage I also use anonymous, privacy-preserving, GDPR-compliant analytics that doesn't require prompts. Other websites made a choice.

That's basically how goroutines work in Go. You opt into concurrency with the `go` keyword, while it's blocking by default. While in JS it's concurrent by default and you opt-in to blocking with the `await` keyword. (Except in Go you have true parallelism for CPU-bound tasks too, while in JS it's only for I/O)

Both have their pros and cons. I've seen problems in Go codebases where some I/O operation blocks the main thread because it's not obvious through the stack that something _should_ best be run concurrently and it's easy to ignore until it gets worse (at which point it's annoying to debug).

Any public information eventually is priced into the stock price by the market.

Say you buy the stock even though you didn't read the DEI statement, but other people bought the stock before you having read it. Their purchases drove up the stock price, so you had to pay more for the stock. You got defrauded of the delta. Especially if now it comes out, the price goes down, and you make losses.

I think the kind of teams that always stay on top of the latest TypeScript version and use the latest language features are also more likely to always stay on top of the latest Node versions. In my experience TypeScript upgrades actually more often need migrations/fixes for new errors than Node upgrades. Teams that don't care about latest V8 and Node features and always stay on LTS probably also care less about the latest and greatest TypeScript features.

This is true, but in other cases they added keywords in ways that could work with type stripping. For example, the `as` keyword for casts has existed for a long time, and type stripping could strip everything after the `as` keyword with a minimal grammar.

When TypeScript added const declarations, they added it as `as const` so a type stripping could have still worked depending on how loosely it is implemented.

I think there is a world where type stripping exists (which the TS team has been in favor of) and the TS team might consider how it affects type stripping in future language design. For example, the `satisfies` keyword could have also been added by piggy-backing on the `as` keyword, like:

    const foo = { bar: 1 } as subtype of Foo

(I think not using `as` is a better fit semantically but this could be a trade-off to make for better type stripping backwards compatibility)

> In SVG, all shapes are absolutely positioned. Text does not wrap automatically.

This is not really true — you can position elements inside the SVG coordinate system using percentages and you can mix absolute coordinates and percentages. This allows you to have elements grow and shrink in reaction to width and height without distortion.

Wrapping text is possible with <foreignObject>, simply let HTML/CSS do the text layout wherever you need text within the SVG.

However it is still true that you usually want to do a bunch of calculations in JS based on the width to know how many chart ticks you want, how many labels, etc. But that is pretty easy to compute with the helpers from D3.

I continue to be baffled how many websites rely on YouTube embeds to show videos, especially marketing/brand websites where you don't usually want other unrelated logos on the page. It's really not that hard to self-host and embed videos, there has been native support since HTML5.

If you just use it in the browser, <svg> is all you need. The browser is smart enough to parse it as SVG based on the context (e.g. if it's embedded inside HTML, if it's linked from an <img>, or if it's served as Content-Type: image/svg+xml). And you can omit the version.

> In SVG land, there is no way to orient around a multiline text box's corners, you can only align the baseline of the first line of text. In fact, there is no way to set a width on a box and have text wrap to the next line when it hits said width. Etc., etc.

You can use <foreignElement> and just include HTML text with all CSS text layout capabilities to achieve that. It won't work in Illustrator or Figma, but it's fine for the web. I honestly am somewhat okay with that, let HTML+CSS handle what it's already best at instead of duplicating functionality into SVG.

The z-index is somewhat annoying for accessibility though, because the DOM order also determines the accessibility tree order, so it's not always possible to reorder the DOM to re-arrange the z-order without breaking screen reader order.