4 ms·

> Agree that the language has to be analyzed under the original design goals to be fair. I mean if you're analyzing languages in a void, I guess, but we're not

> Agree that the language has to be analyzed under the original design goals to be fair. I mean if you're analyzing languages in a void, I guess, but we're not. We're looking at languages as tools to solve programming programs. And almost nobody has the problems that Go was designed around, so the original design goals are kind of irrelevant. I mean, how many of you have worked on a million line codebase? If you haven't, why would you care that compiling millions of lines quickly was a design goal for Go? Yes, smaller codebases are also faster to compile, but partial compilation works just fine for that in other languages.

lifthrasiir 2y ago
I should note that I do see merits of "unfair" analyses, in fact they are probably as important as fair analyses. It's just that such analyses would inevitably cover what designers originally didn't even think of, so such analyses should ideally be considered sort of bonuses instead of main criticisms.
- kerkeslager 2y ago
  Huh? If a design is bad because the designers didn't think of something, it's bad. "They didn't think of it" isn't an excuse in any way, it's 100% irrelevant. Again, if Go had stayed an internal language to Google, I wouldn't have any criticisms of Go. But when they decided to release and market it as a general purpose language, the fact that it wasn't originally designed as a general-purpose language becomes relevant only as the cause of a whole bunch of problems. And more to the point, people considering using it as a general-purpose language should not consider its original purpose, they should consider the purpose they intend to use it for. I really don't get where you're coming from here. Are you just trying to be nice to the original devs or something? I'm not criticizing them for choices that probably made sense in the context of Google, I'm criticizing the language itself as it is used today, and I'm criticizing the choice to use Go for purposes it was never designed for. I mean take a step back for a second and look at the big picture of this discussion. Would you really Go for a project if a modern language like Gleam or Rust was a better fit for your needs out of some sense of "fairness" to Go? If not, why is "fairness" even part of this conversation?
  - lifthrasiir 2y ago
    > If a design is bad because the designers didn't think of something, it's bad. What if designers chose to not think about something because that would be irrelevant to their goals however? ;-) It is worthwhile to look back why we criticize programming languages in the first place. You are absolutely true that current users of given programming language have rights to criticize languages for the current uses, regardless of original intents or designs. But we also want to see better programming languages that are more suitable for given domain---this does assume that we will never be able to build a single language for all uses but that should be reasonable enough. Both criticisms matter and by not distinguishing them you are possibly filtering at least one of them out. Maybe I'm thinking in this way because I'm a programming language designer in my heart and so sympathic to Go developers---that doesn't change my claim that both criticisms should be treated equally.
    - kerkeslager 2y ago
      > What if designers chose to not think about something because that would be irrelevant to their goals however? ;-) Again, I'm not criticizing the designers, I'm criticizing the language as it applies to the goals of pretty much everyone in this thread. And, I'll add, I very much doubt that the original designers' goals were benefitted by not having generics in the language initially. That's just such an obvious mistake.
      - lifthrasiir 2y ago
        Was that what you are thinking I'm advocating for? To be clear I agree that the initial lack of generics did weaken original goals. (Even more so because I wrote Rust much more than Go anyway.) I don't agree that such lack is a major deficiency for original goals however, because built-in parametrized types do cover the majority of use cases and higher-level programming envisioned by Go designers needs less generics in general [1]. [1] Assuming that you are not going all in specific design patterns from functional programming, of course.
        2y ago

lifthrasiir 2y ago

I should note that I do see merits of "unfair" analyses, in fact they are probably as important as fair analyses. It's just that such analyses would inevitably cover what designers originally didn't even think of, so such analyses should ideally be considered sort of bonuses instead of main criticisms.

kerkeslager 2y ago
Huh? If a design is bad because the designers didn't think of something, it's bad. "They didn't think of it" isn't an excuse in any way, it's 100% irrelevant. Again, if Go had stayed an internal language to Google, I wouldn't have any criticisms of Go. But when they decided to release and market it as a general purpose language, the fact that it wasn't originally designed as a general-purpose language becomes relevant only as the cause of a whole bunch of problems. And more to the point, people considering using it as a general-purpose language should not consider its original purpose, they should consider the purpose they intend to use it for. I really don't get where you're coming from here. Are you just trying to be nice to the original devs or something? I'm not criticizing them for choices that probably made sense in the context of Google, I'm criticizing the language itself as it is used today, and I'm criticizing the choice to use Go for purposes it was never designed for. I mean take a step back for a second and look at the big picture of this discussion. Would you really Go for a project if a modern language like Gleam or Rust was a better fit for your needs out of some sense of "fairness" to Go? If not, why is "fairness" even part of this conversation?
- lifthrasiir 2y ago
  > If a design is bad because the designers didn't think of something, it's bad. What if designers chose to not think about something because that would be irrelevant to their goals however? ;-) It is worthwhile to look back why we criticize programming languages in the first place. You are absolutely true that current users of given programming language have rights to criticize languages for the current uses, regardless of original intents or designs. But we also want to see better programming languages that are more suitable for given domain---this does assume that we will never be able to build a single language for all uses but that should be reasonable enough. Both criticisms matter and by not distinguishing them you are possibly filtering at least one of them out. Maybe I'm thinking in this way because I'm a programming language designer in my heart and so sympathic to Go developers---that doesn't change my claim that both criticisms should be treated equally.
  - kerkeslager 2y ago
    > What if designers chose to not think about something because that would be irrelevant to their goals however? ;-) Again, I'm not criticizing the designers, I'm criticizing the language as it applies to the goals of pretty much everyone in this thread. And, I'll add, I very much doubt that the original designers' goals were benefitted by not having generics in the language initially. That's just such an obvious mistake.
    - lifthrasiir 2y ago
      Was that what you are thinking I'm advocating for? To be clear I agree that the initial lack of generics did weaken original goals. (Even more so because I wrote Rust much more than Go anyway.) I don't agree that such lack is a major deficiency for original goals however, because built-in parametrized types do cover the majority of use cases and higher-level programming envisioned by Go designers needs less generics in general [1]. [1] Assuming that you are not going all in specific design patterns from functional programming, of course.
      - 2y ago