Edit: I am genuinely interested in why you think I am a bootlicker but we can't dig into it if you won't actually talk about the particulars of this situation.

I am not an expert but I believe that US regulations require that manufacturers make a range of vehicle types to sell on the US market. You don't need to sell a lot of, say, compact cars - but you need to offer a compact car in order to sell your cash-cow large trucks.

That said, I encourage you to look into the blizzard lawsuit against WoW server emulator makers[1] or the Nintendo lawsuit against Switch emulators[2]. Both cases where teams have built software equivalent to copyrighted products without the direct use of copyrighted assets, but who were nevertheless found to have violated some aspect of IP law. I am not a lawyer and I can't say what would have happened if Atari were to bring such a suit against the OpenTTD project, but I can say with certainty that whatever the outcome it would have disrupted the project and cost an enormous amount. The combination of the IP laws in the US and the realities of our court system mean that the underlying truth often matters less than the burdens of defending yourself against accusations. Atari certainly could be dragging the OpenTTD project through court right now - but they are not and that's good for the project and all of us who have uninterrupted access to OpenTTD.

If you're interested in having an actual discussion please bring some effort to this exchange. What is preventing Atari from dragging OpenTTD through the courts? What is an example of a project fending off a lawsuit from an owner of related IP? How did they do it and why would the OpenTTD project be in that position as opposed to a position such as the ones I've outlined?

[1] https://www.tweaktown.com/news/107476/blizzard-sues-turtle-w...

[2] https://www.polygon.com/24090351/nintendo-2-4-million-yuzu-s...

I gotta disagree with you there! Code that isn't read doesn't do anything. Code must be read to be compiled, it must be read to be interpreted, etc.

I think this points to a difference in our understanding of "read" means, perhaps? To expand my pithy "not gonna read if you didn't write" bit: The idea that code stands on its own is a lie. The world changes around code and code must be changed to keep up with the world. Every "program" (is the git I run the same as the git you run?) is a living document that people maintain as need be. So when we extend the "not read / didn't write" it's not using the program (which I guess is like taking the lessons from a book) it's maintaining the program.

So I think it's possible that I could derive benefit from someone else reading an llm's text output (they get an idea) - but what we are trying to talk about is the work of maintaining a text.

> When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."

> Don't be curmudgeonly. Thoughtful criticism is fine, but please don't be rigidly or generically negative.

> Please don't fulminate. Please don't sneer, including at the rest of the community.

> Please don't comment about the voting on comments. It never does any good, and it makes boring reading.

I don't think downvoting your comment is super useful either but there are elements of how you are interacting that are not related to your argument that you could change to be less likely to be downvoted.

[1] https://news.ycombinator.com/newsguidelines.html

[1] https://www.wiimhome.com/

To be clear I think either option is fine, but those seem like the important aspects of the change. If you are going to spend 10x more on music by buying from artists - you can probably also afford to keep a streaming service. Spotify does suck so go to [1] or Tidal[2]. The thing that matters to artists is getting money. If you're going to radically alter your media consumption habits that's great too but again seems like the real story.

If we are serious about convincing people to use alternatives to highly controlled streaming media I think we should ground our conversations about it in the practical choices that come with making ethical choices.

[1] Qobuz has the highest per-stream pay rate in the industry by like 40%. https://www.qobuz.com/us-en/discover

[2] Tidal is the widely-available service with the second-highest pay rate. https://tidal.com/

Most megacorps do suck - and also it's probably true that the lack of customer support is necessary to offer the products they offer at popular price points. People just don't wrap their heads around the scales involved, generally because the exact numbers are proprietary.

[1] https://www.bitsaboutmoney.com/archive/seeing-like-a-bank/

> critics love the Twitter example. But look closer. Ruby carried them further than most companies will ever reach. They outgrew their shoes. That’s not an indictment… that’s success.

> I’ve never seen a team fail because they chose Ruby. I have seen them fail because they chose complexity. Because they chose indecision.

> GitHub held the world’s source code together for years using Ruby.

There are many examples of companies that used Ruby at one point very successfully but moved on from it once it no longer fit their situation. This isn't a critique of Ruby! But it is agreeing that Ruby can be outgrown and that, if you are looking to start with a language your usecase probably won't ever outgrow, Ruby might not be the best choice.

That said - this response and the critique seem to basically agree. The critique can be summed up as "Ruby doesn't work forever" (and so it should never be used) and this is saying "Ruby doesn't work forever" (which is fine). I could almost understand this post as saying: 'Ruby isn't serious and that's not a problem for anyone who uses it.'

I will say that I found it funny that the original article attacked Ruby for being all the way down at "18th place" (This is inaccurate - it's 14th in 2024) on the SO dev survey - while talking up Scala which is 9 places further down on the survey[1].

[1] https://survey.stackoverflow.co/2024/technology#most-popular...