Try out: "Write an OpenAPI specification for $deviceYouJustMadeUp."

Have you giving your writing to people to see if they want to read it?

> jq

Add xmlstarlet for anything that has to do with xml.

All people in a company need to do deep work to make it count.

Because if you are able to concentrate and find a solution for a problem, you also need other people to concentrate and understand your solution.

> In my humble estimation, making art is vastly more difficult than the huge majority of computer programming that is done.

That is only because the vast majority of computer programming that is done is not very good.

Using GitUp on the Mac as a client. It allows you to select a commit and press Options-S to reset your branch to this commit, it allows you to squash etc.

And best of all it keeps a backup of your entire repository so you can undo whatever git command you just did.

> but in practice there’s cases where it’s treated more like an unchecked exception in Java, i.e., “I can’t recover from this so _I’m_ going to give up but _you_ can keep going.”

Java has a supertype for unrecoverable problems like out-of-memory-errors. It's called "Error", a subtype from Throwable. Exceptions are also Throwables, but they are NOT errors.

There's nothing unrecoverable about Error exceptions. If one thread hit a bug and threw StackOverflowError, it's not a reason to kill the entire application or even thread itself, just unwind stack, show some error and continue processing next task. The only tricky situation I'm aware of is OutOfMemoryError, because it can affect other threads. I'd prefer to restart the server. But again it's just because typical code allocated heap all the time. One can write code carefully without heap allocations and this code will work just fine with OOM errors thrown around.

> How are you going to convince people that your project is "disruptive" if you aren't willing to embrace a younger, edgier tech stack?

Easy: Use Kotlin, which is extremely hip and compiles to the JVM. You can use the JVM then, and mix in java-support should you need it.

> Java is one of the few ecosystems that provides a software distribution ecosystem that doesn't allow distribution of sources alongside binaries.

This is wrong, source distribution is a standard in maven.

> Gradle literally cannot be built from source[1] because it relies on a binary cache of dependencies held by Gradle to build Gradle.

This is wrong as well as pointed out in the thread.

> As a consequence, the Java ecosystem has become a security and maintenance nightmare that other ecosystems simply aren't. As bad as Nodejs is, it doesn't do this.

This is almost hilarious. I'm working at a company at the moment guiding security updates for java and node.js backends. The java backends are not an issue. The node.js backends are almost impossible to upgrade, the javascript-frontends are even closer to impossibility.

1. Because they confuse Java with the standard hibernate/springboot backends that are used everywhere in the industry. Hibernate/springboot is the reason why there are so many monoliths out there that are almost impossible to refactor.

It's not Javas fault, it's Springs fault.

2. They believe Java is slow, but fail to realize that the JVM has actually one of the most optimized runtimes under the sun and can be fast than (unoptimized) C in many cases.

Long story short: Because they have no clue about Java and follow advice without researching it first.