I just checked, my main side project only has less than 10 things that return never. `-> Never` reads even better, imo.

Part of their wonder is how they can behave differently depending on the data they’re working with. We like that feature when the data is the “good stuff” (docs, compiler messages, etc.), but how you tell that apart from “bad stuff” (prompt injection on official-seeming pages).

We basically expose LLMs to the same social-engineering vulnerabilities that humans have.

Hard to take seriously.

All their spec sheets say they support up to x% _non-condensing_ humidity, which I’m guessing is about the dew point?

The overwhelmingly common case is for an error in a nested call to be bubbled up to be handled by a parent call. If you make this common case look similar to the distinct case of actually handling an error, you just obscure where the real error handling happens.

Writing good error handling is Go is really hindered by two other issues mixing together: 1. There’s no Result type, so while it tries to treat errors as values, it’s missing out on a lot of the benefit of that idea. 2. Multiple function return values are implemented as a special case, and aren’t themselves a value

Most languages that support multiple return values, do it via some notion of tuples: returning a single aggregate value that you can pass around as a whole, but that also have some nice syntax for destructuring them into local variables. Go implements as a syntactic special case.

You can’t assign the multiple return values of a function call into a single variable. You’re forced to take all the parts, and pack them into a struct yourself. This means that you can’t factor your result-handling logic into testable functions, without needing to do this dance at every call site.

For example, SmallTalk is a class based OO system, yet this postcard doesn’t slow you how to create a class.

If people were just going to do it anyway, these gambling companies wouldn’t be pouring billions into advertising to stimulate demand

It’s a common misconception that comes from the standard library data structures, which almost all do implement CoW

It’s a bit odd they spend a lot of money on advertising to stimulate demand though, hmmmmmmmm /s

The AoC format goes out of its way to express all problem inputs and outputs in simple strings with only basic ASCII text, just for compatibility with the most programming environments. This is very different from almost all real-world problem, where the complexities of human language are huge.

Why?

https://en.wikipedia.org/wiki/Perian

That’s a huge limitation when writing libraries. If you have an old function that declares that it can throw a DatabaseError, you can’t e.g. add caching to it. Adding CacheError to the list of throwable types is an API breaking change, just like changing a return type.

Swift has typed errors now, but they shouldn’t be used carefully, and probably not be the default to reach for

Whether you write document them or not, types still exist, and you have to think about them.

Dynamic languages make it really hard to answer “what is this thing, and what can I do with it?”. You have to resort through tracing through the callers, to check the union of all possible types that make it to that point. You can’t just check the tests, because there’s no guarantee they accurately reflect all callers. A simple type annotation just gives you the answer directly, no need to play mental interpreter.