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

FWIW, AoC is very non-representative of real-world string manipulation problems.

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.

Are you suggesting that the test for whether they should “allow” a feature is whether your mom can figure it out?

Why?

You just reminded me of Perian. What a throwback!

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

Typed exceptions are unlike typed parameters or return values. They don’t just describe the interface of your function, but expose details about its implementation and constrain future changes.

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

Dynamic languages can execute code without type annotations, so you _can_ just dismiss types as redundant metadata. But I don’t think that’s wise. I find types really useful as a human reader of the code.

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.

This is the eternal selection pressure that slows new C++ adoption.

The kinds of places still waiting C++ aren’t usually the ones that put much emphasis on using a compiler from the past decade.

Java 8 and C++98 will be here forever lol

Stacked diffs are a core part of my workflow, letting me “work ahead” without being blocked waiting for reviews.

Setting them up in git is not to bad. Adding a change to the bottom of the stack, and restacking everything on top… that’s hell in git.

Ah yes, [a Dutch toilet](https://noplacelikeanywhere.com/destinations/dutch-toilets-a...)! A most regrettable invention.

I would be more than happy to see gift cards disappear.

Limited strings-attached IOU that’s worse in every way than the cash paid for them.

The unrefactorable ball of mud problem is real, which is why both Stripe and Shopify have highly statically typed code bases (via Sorbet).

Btw Stripe uses Ruby, but not Rails.

How many declarations did it have in C++ in total? Technically those were all unsafe, just implicitly so.

Exactly, you write them with AI

Such is the issue with bad defaults. Opting into the sensible thing makes most of your code ugly, instead of just the exceptions.

Engagggge. Consume the slop. Shareholders demand it!

I hope your train of thought proceeds to the next station along that line: “oh yeah, because that doesn’t scale, obviously.”

It’s the same reason why it’s better to sponsor a “we’ll double your donation up to $X” charity campaign, than to just donate $X directly. It attracts others in with you.