Defletter

Checked exceptions are not the problem. In fact, I don't think there should be ANY unchecked exceptions outside of OOM and other JVM exceptions. I will die on this hill. The actual problem is that handling exceptions in Java is obnoxious and verbose. I cannot stress enough how bad it feels going from Zig back to Java, error-handling wise. If Java had Zig-style inline catching, there wouldn't nearly be as much humming and hawing over checked exceptions.

Why? It's a good grammatical equivalent to the full stop for the programmer. It can serve as useful context for the compiler. And it's only one character. Antagonism over semicolons is another strange symptom of conciseness at all costs. If you want APL, just use APL.

The only complaint I have about RSS is that it seems antagonistic to edits. It's not usual that, when refreshing my podcast RSS feed, there are multiple versions of the same episodes because they made some edit somewhere in the title or description, etc. I've had five versions of the same episode before. I feel like we should have the technology to fix this by now :P

> Are all your plates and bowls at home plastic as well?

Funnily enough, there are contingents of people who exclusively use paper plates and plastic cutlery. I think there's an interesting parallel there. Those kinds of people simply do not want the effort and cost of maintenance. I'm not particularly sympathetic to this mindset in either case, but still.

You may be surprised by the amount of people who dispute this... it's depraved

Wouldn't surprise me whatsoever if someone creates zigplus, which is just some TypeScript-style superset that adds lambdas and interfaces to Zig as syntax sugar.

Unless something has changed from this (https://github.com/ziglang/zig/issues/1717#issuecomment-1627...), that is unlikely. The irony is that Zig's new async/await strategy is to use event loops with passed-in functions (https://www.youtube.com/watch?v=x3hOiOcbgeA&t=3643s).

It may not be the usual example, but I believe it an apt one: shrinkflation and other kinds of forever "cutting costs" to the detriment of everything else is so normalised it's a cliche. We expect planned obsolescence now.

Another project burdened by Andrew Kelley's weird hate-boner for function literals.

    (struct { fn run }).run

How ridiculous that this is required to do something so simple.

As it turns out, trademarks for small open-source projects are effectively worthless (https://news.ycombinator.com/item?id=44883634), so there's effectively no real solution to people appropriating your project's name while repackaging their inferior fork of it.

Yup, this one (https://news.ycombinator.com/item?id=43824640) comes to mind. The first comment says "Another failed game project in Rust", hinting that this is very common.

That's... honestly really disappointing. I use explicit `T{}` because otherwise becomes too unreadable, too Assembly-like: I like knowing what types I'm using. It also provides a convenient thing to click on to inspect the type. I genuinely do not understand this headlong pursuit of conciseness to the detriment of readability.

Forking is fine, do whatever, but as soon as you make actual changes to the code then adopt your own name. This is what trademarks are for, it's just that official trademark registration is somewhat inaccessible (eg: cost) for open source projects. Could you imagine trademarking every little project you make just in-case it gets repackaged by someone who tears huge chunks of it out?

Just jumping in to say that this is making me genuinely reconsider adopting a licence/policy that forbids repackaging: the fact that someone can repackage my project, but worse, and still use my project's name? Absolutely not. I do not want the burden that inevitably comes when people complain to me that this or that is missing from a repackage.

Yup. I used to use a Macbook Pro as my daily driver and played League of Legends on it... and the amount of forced-focus was infuriating. You just locked in and are messaging your friend on Discord about something? Well, there's 10 seconds left until the game starts and that's more important so you're focusing the League client now.

Oh absolutely. I admittedly haven't used Spring beyond trying it out for a couple hours and deciding never again, but I can easily imagine Ktor being an improvement over Spring. When I wrote my comment, I was more thinking about it in comparison to Netty and Java-Websockets (relevant: https://news.ycombinator.com/item?id=43800784), rather than as a web framework, though I have used it as such.

Netty is also a struggle to inspect so perhaps I just struggle with deep abstraction in general? I find code to be far better documentation than actual documentation, particularly when so much of it is along these lines:

    /**
     * Gets the next string.
     *
     * @return Returns the next string, or null.
     */
    public abstract @Nullable String getNextString();

This documentation is entirely unnecessary because everything it says is present within the method signature. But say you have an abstract method that users override to handle incoming data, often documentation will not contain things like: whether the ByteBuffer is a slice or the whole buffer at a particular offset; or whether the buffer is a copy or a view; etc. So I end up doing a lot of defensive copying which is possibly unnecessary, but because it's very difficult to figure out where that buffer is coming from without first trudging through a seemingly endless forest of abstractions first.

I did ask "Or rather, how do you do this without returning to the un-ergonomic try-catch?" but I don't want to die on this hill. Can I just assume then that this distinction isn't possible in Swift without returning to try-catch blocks?

You misunderstand. In the question given, we don't care about the error, only that an error having occurred is detectable. In Rust, this would be represented as: Result<Option<ExampleType>, ()>, whereas using try? would reinterpret the error as a null, so there's no way to tell the difference between an error-as-null and a returned-null.

This has consequences for config parsing, for example, where a particular subsection (sub-object? keyed struct?) may be optional, so it being missing is perfectly legal. But if you use try?, then there's no way to distinguish between it simply being missing and it being present but malformed. It unfortunately seems like the only other options in Swift is to propagate the error, or revert back to verbose try-catch blocks.

Whereas, in Zig, you can do inline catching and care about the error only as much as you want to, for example:

    // This is equivalent to Swift's try
    const i: ?i32 = try someThrowingFunc();

    // This is equivalent to Swift's try?
    const i: ?i32 = someThrowingFunc() catch null;

    // This is a yielding inline catch block that does not care about the error
    const i: ?i32 = someThrowingFunc() catch brk: {
        logger.warn("Something went wrong!");
        break :brk null;
    }

It's not perfect, I don't love the block-label-break thing, but I much prefer this if only because then the variable can be defensively const, which I do not believe is possible with the kind of code snippet you provided. Also, instead of breaking out, it could capture and return the error or return a new error. It's incredibly versatile.

While I am certainly a fan of Swift's error handling and think it'd be an improvement to Java's current state of affairs, I do think that using null as an error analogue is... unwise. What happens when a function is throwable but also may return null? How do you determine whether the null is a coerced error or a valid return? Or rather, how do you do this without returning to the un-ergonomic try-catch? Zig solves this by having errors and nulls be separate parts of the type system which you can deal with separately and inline.

While I am definitely impatiently waiting for null-restricted types, what I feel Java really needs overall is ergonomic handling syntax, notably: "safe calls" (https://kotlinlang.org/docs/null-safety.html#safe-call-opera...), "elvis operator" (https://kotlinlang.org/docs/null-safety.html#elvis-operator), and inline catching (https://ziglang.org/documentation/0.14.1/#catch).

Relevant: https://news.ycombinator.com/item?id=44672787

Kotlin can be fairly pleasant to write but it's so incredibly unpleasant to inspect. For example, Ktor is the Kotlin backend framework, but good luck figuring out how any of it works. It's a complete mess of "higher-order functions", extension methods, and other abstraction-hell as to make it extremely difficult to figure out what is executed when and under what circumstances. Basic Kotlin code is fine, great even, but once people stop writing Kotlin as Java developers, but as Kotlin developers, then it goes downhill fast.

> This wasn't the case until relatively recently (the 1700s or so, depending on where you live)

While that's true, that comes from the secularisation of law and the emergence of the concept of the nation distinct from the King. Prior to this, to break the law was to insult the King. This dynamic was at the forefront of the trial of King Charles I, who argued that he could not have committed treason since treason was to act against the King - the King was the nation.

That said, I do take your point that different places in the world have/had different approaches to law. I talk more about Anglosphere-law because that's ultimately what's won out, particularly with the system of the sovereign nation states.

I guess that's an interesting distinction: what's the difference between a law and a rule. I think there are two main differences:

1. In your example, the group of buddies all created the rules and consented to them. This is not true for laws which instead invent concepts like the social contract to justify itself.

2. When you break the law, say murder, the ultimate victim is the state. The person you murdered is just evidence in the state's case against you. This is why there are Victims Right's movements. This is not really true with such buddie rules: breaking them may hurt your friends' feelings, but there wont really be an equivalent to it harming the social fabric.

3. Laws imply law enforcement, which implies use of force. Are you and your buddies willing to enforce your rules on each other with lethal force?

> To be honest, when people start talking about "echo chambers" it's usually because they are upset that I won't listen to bigoted alt-right hate.

Agreed, though they aren't necessarily using that term in recent years. Nowadays they tend to use terms that evoke "echo chamber" without actually saying it, like "woke mind virus" and "groupthink". And while I agree with some of the other comments that "echo chamber" has since been more used to refer to algorithms, this might be a result of being on Hacker News, which is an echo chamber in itself. I do have a somewhat instinctual aversion to the term "echo chamber" though given its prolific use as a thought-terminating cliche.

Okay?

> You try help someone based on their CURRENT circumstances

You claim I'm being disingenuous and then say this as if I haven't been this entire time referring to historic injustices AND THEIR ONGOING LEGACIES. Nah, y'all just prefer to selectively ignore that part.

Your fundamental problem is that you presume and assert that "ideas that apply to individuals" cannot also apply to groups, communities, and institutions. You realise such things are, ultimately, just collections of individuals, right? Institutions are not freak forces of nature either, they are created by people, for people, to act on behalf of people; the institutions act as individuals (hence why you can sue an institution like it's a person) and is comprised of people. Obviously, there are things institutions can do that an individual cannot and vice versa (eg: an institution cannot marry), but this clean and objective divide you continue to insist upon is simply untrue.

> Trust between nations is a concept that exists, but it's not the same thing as trust between individuals.

And here's an example of the above: you reject my claim that trust between nations and trust between individuals are comparable and within the same category because it's not literally the exact same thing. Okay, let's follow your logic: trust between people and their institutions are not the same concept; trust people family members and friends are not the same concept; trust people have in their tools or craft is not the same concept. It is not useful or relevant to compare any of this because if it's not literally the exact same thing in the exact same context, it's irreconcilably different.

> You have taken the idea that reparations are right

Not quite. I am arguing for reparations as a form of devil's advocacy (relevant: https://news.ycombinator.com/item?id=44364746). What I've been doing in this thread is questioning your (and others') unwavering loyalty to finance obligations regardless of whether they span centuries to where there's no overlap whatsoever between those who agreed to the obligations, those who are paying for it, and those who are receiving it. You do not bat an eye at this, and you seem somewhat exasperated at needing to explain it, asserting the apparent obviousness of it. But when it comes to material human suffering and the legacies of injustice that can still be felt and witnessed today, the idea of attempting to remedy this does not compute.

---

Put simply, you are so entirely entrenched in this "don't therefore can't" mentality that you cannot comprehend alternatives. It's like when people cannot comprehend hypotheticals: What if you didn't work here? But I do. Yes, but what if? But I do work here. Societies could, if they wanted to, see past injustice as something contemporary society has an obligation to resolve... we don't do this because we've chosen not to, not because it's impossible to do so. And the choice to do so or not is a moral decision. Ditto with choosing to prioritise financial obligations over remedying human suffering. I'm sorry that you are unable to see this. I'm not going to entertain this conversation further.

Correct, the difference is that one gave money to slave owners, and the other is compensating the descendants of slavery (and its ongoing legacies) for the crimes against humanity committed against them.

Got it, human suffering is less important than debt

Not saying it's a good idea but the choice will always be there, and the decision not to do it is nonetheless still a choice. And so coming full-circle back to reparations, why don't we want societies to correct past wrongs? Why is honouring two-century old debt so world-shatteringly important, but fixing two-century old injustice (and its ongoing legacies) scoffed at?