throwaway143829

Why do you think this implies they are building a search service rather than just scraping your site for more training data?

Couldn't the zero value be nil? I get that some types like int are not nil-able, but the language allows you to assign both nil and int to a value of type any (interface{}), so I wonder why it couldn't work the same for sum types. i.e. they would be a subset of the `any` type.

Enums and sum types seem to be related. In the code you wrote, you could alternatively express the Hot and Cold types as enum values. I would say that enums are a subset of sum types but I don't know if that's quite right. I guess maybe if you view each enum value as having its own distinct type (maybe a subtype of the enum type), then you could say the enum is the sum type of the enum value types?

> in some sense

I think you missed the point - this is what they mean by "defined so loosely as to be uninformative." By saying "in some sense" you are allowing arbitrarily abstract definitions of the term "computer" thereby making the term itself no longer useful.

What's the difference between this recipe and `impbcopy image.png`? Is it just for the pixelated effect?

Your comment seems to presume that AI will not get any better than it is now. Imagine an AI that understands how to create deep, impactful music better than humans do, because it understands how music works at a biochemical level. Imagine it can even predict the dynamics you're describing, about employing "unwanted artifacts" in the music as a way to evolve new genres. It would no longer need to create such obviously derivative works at that point, and it could generate music that sounds completely unique to us. It may take a long time to reach that point, but when it does, the kinds of music that it generates won't be able to be dismissed so easily.

Yeah, I'm very confused by this. Why is the example also showing a hard-coded 2023 in the component usage? Shouldn't the component be responsible for rendering that?

sqlite3, but I think bulk inserts would improve perf for other DBs too.

TLDR to get better performance, use bulk inserts instead of inserting one row per query. And (unrelated to DB perf) don't use the spread operator in JS for passing function args (the author says not to use the spread operator at all but you don't need to go that far)

Have you seen protobuf.js? I've dug quite deep into its generated code and have not seen any runtime magic. It's just directly working with the protobuf wire format and transferring the data to/from fields with very explicit code.

I can't speak for Google's official implementation though.

Stores don't have the space for that currently. Though it may be possible to redesign them in such a way that they do.

Can confirm, I broke the robot once when I accidentally had the sign flipped on the PID error term.

find is pretty slow compared to fd. It also spends a lot of time searching through directories like .git or node_modules which you typically want to exclude.

Handling "end of data" isn't really something that any serialization format needs to specify, so I don't think this needs to be called out for JSONL specifically. e.g. in JS if you're using a ReadableStream you can just check whether a read returns .done==true. This is true regardless of the data you're reading, JSONL or otherwise

HN has some really non-obvious UX, between this and the mysterious green usernames I still don't understand. And the fact that only some users can downvote. Or the weird logic behind which words cannot appear in titles.

Am I missing something? This doesn't sound like an attack at all. I'm interpreting it as just "don't host ffmpeg yourself and try to write distributed encoding workloads etc., just use our hosted solution instead which handles this stuff for you." I don't get how this is an attack - plenty of businesses are built this way.

It looks like the one-liner function comes from their npm library... which requires a build step?

At that point you could just use an SVG charting library. Good charting libraries will have code snippets readily available for line charts that you can copy/paste. SVG can be styled with CSS just like text.

"Simpler code" seems like the main benefit but it comes with a big "weirdness" factor as the tradeoff. I'd bet there's a super lightweight SVG charting lib somewhere out there which is about as simple as this while being much more standard. i.e. supports line charts only, and has the simple type signature `(number[]) => SVGElement`.

Makes you wonder what comes after AI. What's the "higher order" after AI that exists today or that will exist in 10 years? I'd guess we will never understand that level of intelligence, unless AI augments our brains somehow.

The article is mostly talking about things like Helm charts for kubernetes, which aren't possible to define as env vars.

This article made me think it'd be nice to generate k8s JSON using TypeScript. Just a node script that runs console.log(JSON.stringify(config)), and you pipe that to a yaml file in your deploy script. The syntax seems more sane and has more broad appeal than jsonnet, and I'd wager that the dev tooling would be better given good enough typings.

By the way the answer to the question "why are we templating yaml?" is: people are just more familiar with it and don't want to have to translate examples to jsonnet that they copy and paste from the web. Do not underestimate this downside :) Same downside would probably apply to TypeScript-generated configs I bet.

I love the simplicity, but wiping the cache is a no-go for most serious apps.

I'm both a casual TV viewer and someone with a short attention span. My experience was: I tried comparing a few Seinfeld episodes, found that I am unable to recall the episodes from the descriptions, then gave up.

I found it somewhat hilarious that you wrote a prose sentence with nested parentheses then began the next sentence with "Lisp's syntax is easy"

In Go, consts can only be used for primitives like 42, "foo" etc. - not structs, because the language doesn't have a concept of immutability (and so wouldn't be able to enforce const-ness) except for primitives.

More info here: https://go.dev/blog/constants