I know lots of people hate on them, but honestly I usually don't mind too much. It does change the mental model for pricing: instead of being based on dev costs, it's based on value. If I use the software for a long time, then it's presumably more valuable, and therefore it makes sense for it to cost more overall (if you assume a value-based pricing model).
It probably wasn't, but it felt like it was. And what I mean by it is: "people worked on the software, that took time, we should pay them for that time."
My sense is that a big part of why people don't like subscription models is that they figure, "I have to pay every month/year, but the developers don't actually have to write new features in that time." I think that mindset implicitly prices the software based on the cost to the company of developing it. I'm suggesting that another mindset is, "if I use this for 10 months instead of 1 month, then it's worth ~10x as much to me (relative to if I'd only used it 1 month), so it makes sense I'd pay ~10x more for it."
I was looking at it less from the business's perspective, and more from the emotional perspective of the buyer.
I agree with "people worked on the software, we should pay them for that". :-) But I don't think "time" is the best way to think about it. It's still a question of how much you value the product. If you buy a music album, it's irrelevant how long the recording of the album actually took. What matters is if the songs are good.
IMO the problem with "subscriptions" is obvious: in most cases, the term is merely a euphemism for "rental". There are some developers who allow you to buy a perpetual license with a certain time limit on software updates, but that seems to be a minority of the subscription model. Whereas the majority of subscription software simply stops working as soon as you stop paying. That's rental.
Rental is almost always a bad deal for consumers, except in the short term. If you go on a 2 week vacation, you obviously want to rent a car in the new city, not buy a new car and try to sell it 2 weeks later. But leasing a car indefinitely is typically a worse deal financially than buying a car.
Consumers want to own the products they buy, but increasingly, software developers want to prevent consumers from owning any software, forcing them to rent indefinitely. That's why consumers are upset, with good reason. It's a loss of control.
A big part of this is the App Store, which caused a race to the bottom and is hostile to upfront paid software in a number of ways.
For those who don't know, IntelliJ IDEA also has this. (I'm not affiliated with them at all, but I do love their IDEs.)
Personally, I tried it once and was too weirded out — I've lived with the side panels for so long that it feels wrong without them there, minimized and providing a nice little frame for my thoughts.
[]any isn't "any slice", but rather "a slice of some type, and that type could be anything."
It's not just a detail of the underlying runtime; there are very real, semantic problems that would occur if two(s) compiled. Consider what would happen if instead of just returning its input, two([]any) modified it:
func two(s []any) {
s[0] = "hello"
}
That's certainly allowed. Now imagine you had:
someInts := []int{1, 2, 3}
two(someInts) // this won't compile
It's a good thing that second line doesn't compile, or your []int would contain a string element.
