The anti-exception mind virus of the 2010s did a lot of damage. Go designers finally caved and added panic & recover, but jeez, the damage was done. The whole ecosystem has exception derangement syndrome.
Go had panic/recover right from the get go. Nobody “caved.” And indeed, you are free to use panic/recover for error handling in your code. That was always allowed.
That said, the key insight of the exception craze is that error returns are a normal part of a functions behaviour and as such should not use extraordinary control flow to take place.
Exceptions (panics) are used for things that should never happen or are indicative of a programmer error, like nil dereferences or out-of-bounds array accesses. That is, things where the programmer is not expected to provide reasonable behaviour on the API level if it happens (but perhaps there is a whole-program fault handler to shut down cleanly).
Opening a file that does not exist? Database record not found? Invalid credentials? These should be anticipated by the programmer and can occur at any time. Not exceptions, normal return values. Go requests that you think about these possibilities instead of pretending they can be ignored.
You're right about recover being in 1.0 of golang.
I definitely fully understand the trade-offs of returning result/error unions vs handling thrown exceptions. Exception handling is clearly superior to me. That said, the typical performance complaints made against the most common implementations of exceptions are valid.
> I definitely fully understand the trade-offs of returning result/error unions vs handling thrown exceptions. Exception handling is clearly superior to me.
Then you definitely don't understand the tradeoffs after all, and/or don't know the history of error handling.
Exceptions are an outdated concept that's inferior to explicit error returns for 99% of software.
The tradeoffs are super simple here - exceptions require very little of your input but lead to terrible spaghetti due to hidden control flow. Explicit error returns are seemingly the opposite, but their verbosity issues have mostly gone away thanks to modern language improvements, so they're just better, unless you're writing short scripts and the like.
The situation is very similar to static vs dynamic typing - dynamic typing used to make a lot of sense in the days of extremely verbose Java type declarations, but modern static type systems with inference have made dynamic typing basically obsolete.
> That said, the typical performance complaints made against the most common implementations of exceptions are valid.
This also sounds off and outdated to me. If anything, exceptions typically have better performance, so long as errors aren't common. Indeed, if optimized correctly, exceptions have zero cost if not thrown, which can get you better perf than error returns, which have a low, but constant cost.
Same. Need multiple terminals visible at once? New window. Need a few separate sessions? New tab(s).
All the bells and whistles people have shown me over the years... it never even gets close to making me think "oh yea, that's better than basic tab/window management and the terminal app that comes with my OS".
I've always found tabs to be pretty limiting, though I have a ton of them in Firefox and Konsole since that's what's - been - available. They're marginal improvement over multiple windows. Then Horizon[0] came on the scene a few weeks ago and I fell in love with that infinite canvas. Started tweaking it like crazy, but now I'm working on a full port that natively supports Xpra[1], so I can have all my apps on an infinite canvas with views grouped exactly as I prefer. And that's the future IMO.
I need it all the time. large monitors are a lot more productive for any task that involves looking at more than one thing while doing it if you have tiling.
tiling managers like Terminator are, to me, the most efficient. Something like Blender for hybrid customization might be a sweetspot. Blender allows for arbitrary layout and essentially tab control in any tile.
I am not sure, since this article uses sex and gender in senses that are entirely inverse to the common ones in 2026. How do you define those terms?
In particular, the 2026 senses are that sex is an immutable biological characteristic based on karyotype and gametes; gender is a social construct, and this is why it can be "transitioned."
The cited article nonetheless uses the archaic terminology "transsexual" to refer to what we today know as "transgender."
Now you see the linguistic ambiguity we are mired in? Can you clarify?
TUIs are very in right now. Nostalgia/vintage-computin-aesthetics & guru-gatekeeping around command line savviness are front and centre in the HN-and-adjacent mindshare.
I think it's AI tools, they are often done as tuis, they work well with text, the cli is a text processing god that is easy to extend with cli utilities, and since you find yourself in the terminal much nicer having TUIs quickly available, editor, git client, etc. I love the shift to the terminal as I use it a lot anyways (I'm old), but the missing piece for me is having a good sql tui client that does at least some of what data grip does. So I'm building my own as an experiment into agentic coding something from scratch (which I think what this TUI Studio is also). Surprised how good it is but also surprised how much time it takes to get things polished.
It's hard to tell with him. In the past rayiner has written that people opposing fascism were being antisocial. He's either a troll (and very committed to the bit) or a very confused individual.
Quite the opposite: I had an idyllic childhood in a southern state suburb that voted for George H.W. Bush twice. I grieve for the loss of that America and fear the regression to the global mean.
