Yeah it really baffles me why a symbol like `!` was spent on this, which could be more useful for more a more commonly used feature.

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

The exclamation point is also used both as the C-style negation operator and as the identifier suffix that indicates macro invocations, so it was unlikely that it would have been used for any new feature. As my sibling comment notes, this syntax for divergence is very, very old (predating even 0.1), not something that anyone newly came up with.

And if you'd like to write `-> Never`, the nice thing about being a first-class type is that you can now just do that if you'd like, via a standard type alias: `type Never = !;`.

Different incentives.

I don’t know how you could keep the two isolated, without drastically dropping up the utility of LLMs.

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.

No benefits to modules? Oh come on.

Hard to take seriously.

“It’s so much magic! Now if you’ll excuse me, I have to go use my generic container library rewritten in 50 layers of preprocessor macros.”

How big is the risk of condensation when you bring a cold laptop inside?

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

I’ve always been told to let electronics and musical instruments slowly warm up in their case after bringing them inside. Supposedly reduces the chances of condensation forming.

The uncomfortable fact about the mentioned Wisconsin winters is that inside dew point tends to be quite low.

I agree with all the motives you describe, yet come to the exact opposite conclusion.

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.

I never understood the appeal of this talking point. It’s just an accounting trick that moves the complexity to the standard library.

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

Yeah, I was also going to say that conflating trivial syntax and "supremely easy to learn" is a very weak flex.

The first Smalltalk-80 book you randomly find is 560 pages.

Also, there is a weird bargaining with "but not block temporaries" and "not an instance variable". Why not? Half of the postcard is basically empty. Also, "except primitives" — how many primitives are there?

The appeal of having a very simple, base syntax and almost everything in the library / primitives, would be that code is always easy to read and write, also on the 'reflection' level, where most languages have specific keywords that cannot be used 'first class' with the rest of the language. E.g: Types next to class objects or operator overloading, look at Swift.. (Of course the complexity of a full working system (library) does not disappear in Smalltalk, it's just easier to read and modify. :)

> on the 'reflection' level, where most languages have specific keywords that cannot be used 'first class' with the rest of the language.

In Ruby this is also the other way around, and it's one of my pet peeves.

`Kernel#callcc` looks like a method (arguably, of a special class), yet it's impossible to re-implement directly in the language, as far as I can tell.

Same with `raise`, I keep forgetting that it's not a keyword even.

Yeah, I just discovered this and was also amazed.

https://decasia.org/tech/2026/02/raise-not-a-reserved-word.h...

This being said, I don't think there is any requirement technically that every core method can also be re-implemented in Ruby... There are so many methods that are just thin interfaces to something written in C, whether because they are touching VM internals, or for perf reasons, or because they make system calls or call external libraries.

You reimplement `while` in terms of `loop`, but do you know that `loop` is also a method :)

Next up: “all the characters you need fit on a single keyboard!”

I hope it's not an APL keyboard

https://en.wikipedia.org/wiki/APL_(programming_language)#/me...

Some amount? Sure. But not at this scale.

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

That makes digitization even more important, you sold me.