Do they want the vinyl itself or do they want the cover art and so forth?

I'd say it's varied & most often a combination of multiple things.

- They want the cover art

- They want a physical token representing an artist they like

- They want to financially support the artist in a direct way

- They speculate they might get a player someday (much akin to book buyers leaving books on their shelves unread for years on end)

1 of the above might be the primary driver for any given buyer but I'd assume all of the above play some part in their motivations.

Makes me wonder if bands produced something like a Displate wall hanging (no promotion intended) whether that would satisfy the same itches.

For my part, there's something visceral about owning a piece of "physical music", as it were, even if I never play it.

They want the expense without the inconvenience?

Anecdotal data from my Gen-Z daughter, currently a college freshman, is that they want the cover art. Her dorm room walls are decorated with vinyl albums in frames where they cannot be listened to.

I'm not sure I'd go so far as to claim it was definitely written by AI (after all, LLMs tend to write the way they do because it reflects their training material), but it does have a large number of suspicious constructions that suggest it could have been:

- "Look, I’m going to say something that might sound crazy...."

- But here’s the thing: there’s nothing stopping us...

- Emdashes. I don't believe that alone they are a tell for AI any more than they are a tell for the cultured, but in combination with other things, maybe.

- The question/answer style.

- The "It's not X, It's Y" construction.

This is all in the first sections.

I agree. The entire "The Path Forward" and "The Bottom Line" breakdowns at the bottom gave me the same impression.

I think it’s a mix of human and LLM writing

I concur with Nick, and the last time I programmed Java professionally was late 2024, with all of the latest and greatest frameworks (obviously not my choice) and tooling (which, to be fair to the Java ecosystem, is second to none).

The experience after having spent over a decade primarily doing Go, Rust and Erlang (with a smattering of TypeScript, C#, Python, Swift, C, C++ etc) was the final push over the line to leave that employer.

Yes - Go is both a simpler language than Java which does not lend itself to (nor does the ecosystem tolerate) the kind of architectural malpractice that enterprise Java typically becomes.

There are approximately no use cases that would get me to run a CLI written in Java on my machine, especially if it required having a JVM installed. There's just no reason for it.

The rounding error there is Pkl, which is at least built using Graal Native Image, but (IMO) would _still_ have better adoption if it was written in something else.

That said, if the Java community wanted to port reasonable tooling to their platform, I'm sure Claude could do a reasonable job of getting a decent chunk of BubbleTea and friends bootstrapped.

Assuming JVM installation is not required (to which I agree, it shouldn't be), why would you care which language a CLI tool is written in? I mean, do you even know whether a given binary is implemented in Go, Rust, etc.? I don't see how it makes any meaningful difference from a user perspective.

> Pkl, which is at least built using Graal Native Image, but (IMO) would _still_ have better adoption if it was written in something else.

Why do you think is this?

It makes a difference in size, in how arguments tend to be handled, and so forth.

As for why Pkl was in Java: it was originally built to configure apps written in Java, and heavily uses Truffle. Pkl is a name chosen for open sourcing, it had a different name internally to Apple before that which made the choices a little more obvious.

> That said, if the Java community wanted to port reasonable tooling to their platform, I'm sure Claude could do a reasonable job of getting a decent chunk of BubbleTea and friends bootstrapped.

There's a poster upthread who seems to have done what you're describing: https://github.com/WilliamAGH/tui4j

So... they aren't keywords.

Swift does indeed have a lot of keywords [1], but neither Task or MainActor are among them.

[1]: https://github.com/swiftlang/swift-syntax/blob/main/CodeGene...

Replying to someone talking about keywords with a list of something that's not keywords, then retreating to "you are an Apple bootlicker" when someone points that out, is not a good look.

EDIT: Seems like newer versions of Xcode change the Swift language defaults here, but that is just the IDE, not the language (and Swift Package Manager does not appear to do the same!)

I'd argue the default is that work _does_ move across system threads, and single-threaded async/await is the uncommon case.

Whether async "tasks" move across system threads is a property of the executor - by default C#, Swift and Go (though without the explicit syntax) all have work-stealing executors that _do_ move work between threads.

In Rust, you typically are more explicit about that choice, since you construct the executor in your "own" [1] code and can make certain optimizations such as not making futures Send if you build a single threaded one, again depending on the constraints of the executor.

You can see this in action in Swift with this kind of program:

    import Foundation
    
    for i in 1...100 {
      Task {
        let originalThread = Thread.current
        try? await Task.sleep(for: Duration.seconds(1))
        if Thread.current != originalThread {
          print("Task \(i) moved from \(originalThread) to \(Thread.current)")
        }
      }
    }
    
    RunLoop.main.run()

Note to run it as-is you have to use a version of Swift < 6.0, which has prevented Thread.current being exposed in asynchronous context.

[1]: I'm counting the output of a macro here as your "own" code.

> I wanted something more like Akka

https://github.com/apple/swift-distributed-actors is more like Akka, but with better guarantees from the underlying platform because of the first-class nature of actors.

Replacing hyperscalers with other hyperscalers born off the back of open source contributors is not exactly progress.

How is it not progress? You have full access to the code, you can use it yourself however you'd like, and the copyrights expire.

They just ask you not to compete with them for a few years.

How is that any way comparable to AWS?

Perfect truly is the enemy of good.

In this case, perfect murders good and locks you in the dungeon of eternal bad so you can think endlessly about perfect. It also stabs any good that comes along while crying about perfect.

> They just ask you not to compete with them for a few years.

No Open Source license actually permits this - by definition of Open Source.

Also the notion that copyright "expires" is ludicrous - we only just saw work from the 1920s enter the public domain (and source is no different to that). Laundering via AI clearly does not count, either.

> Markets can't decide "families can have only one child"

Sure they can. Just make it unaffordable to do anything else.