amomchilov

Bolting on concurrency after-the-fact is notoriously difficult to do.

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.

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 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.

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

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.

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.

They don’t, by default. That’s something you have to implement yourself.

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

Recent macOS versions zero out memory on free, which improves the efficacy of memory compression. Apparently it’s a net performance gain in the average case

The industry assures us they’re just filling demand that already existed, that used to be fulfilled by a black market anyway. So now it’s all above board and taxed and hunky dory.

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