6 ms·

Ebiten is actually making me want to get back into Go itself. I'd love to make a cross platform game and it may just motivate me enough to push through my ideol

Ebiten is actually making me want to get back into Go itself. I'd love to make a cross platform game and it may just motivate me enough to push through my ideological biases against Go.

djur 5y ago
I'm not big on Go either but I feel like it's a good fit for hobbyist game development. It's a lot harder to write automated tests for games, so the value of static typing is higher, but most simple game designs don't really benefit from the powerful type systems of a Rust or Haskell (or even a TypeScript). It's one of the cases where Go actually does feel like a "better C".
- chana_masala 5y ago
  > but most simple game designs don't really benefit from the powerful type systems of a Rust or Haskell (or even a TypeScript). I get that feeling too but I have no experience with game development. I wonder what reasons you think so?
philosopher1234 5y ago
I've yet to meet an ideological bias against Go that took into account & understood the practical tradeoffs Go is making. The ones I've seen thus far are dismissive and incurious. But if you've got that, I would love to hear it.
- halpert 5y ago
  To me, Go is just a boring language to write in. It’s target audience is large corporations where individuality is discouraged. I’ve used Go extensively at work, and its lack of expressivity definitely has some upsides on large teams, mainly keeping things simple and understandable. But when I program in my free time for fun, I want to be able to express myself fully.
  - philosopher1234 5y ago
    I agree with you that Go is a boring language. I think in Go's boredom is a path to creating better code than you are pushed towards in other languages, and I enjoy writing Go in my free time because I enjoy learning about API design through interacting with the STL, and because I produce programs in it that I understand much more deeply (and with relative ease) than when I try to use another language. However, Go is not a good language for experimenting with cutting edge language features.
- chana_masala 5y ago
  I actually mostly agree. I just don't really like the aesthetics of writing Go, which I know is a silly reason.
  - philosopher1234 5y ago
    I'm not one to call aesthetics silly. The act of reading and writing programs relies heavily on the programmers emotion, and so I think aesthetics matter greatly. What don't you like about them?
- YawningAngel 5y ago
  I'll bite. I've read all the arguments the creators of golang made for not including generics. They are just as true now as they were when the language was created, and yet generics have now been added. Moreover, they have been added as part of golang 2.0, so any breaking changes that turned out to be needed could have been made now anyway. I think it's pretty reasonable to dislike a language that refuses to implement a basic feature for essentially no reason.
  - geodel 5y ago
    This seems rather clueless. The party line was they have not found a way to implement it in a way that satisfy their requirement. Now they have found a way to do so. So I see no contradiction. Also what breaking changes you are talking about I am not aware of any. Also there is no golang 2.0 yet.
    - YawningAngel 5y ago
      > The party line was they have not found a way to implement it in a way that satisfy their requirement. Now they have found a way to do so. So far as I'm aware, every mainstream language, including golang, that's addressed this question has chosen to solve it by monomorphising generic functions. This implementation was well understood when golang was first released, and it isn't remotely plausible that the authors were not aware of it. > Also what breaking changes you are talking about I am not aware of any. Also there is no golang 2.0 yet. An argument given at the time was that committing to an implementation of generics would potentially put golang in an awkward position similar to Java's wherein if the implementation turned out to be bad, the language would be stuck with it anyway for backward compatibility reasons. I am simply pointing out that, since both golang 2 and generics have been discussed roughly contemporaneously (generics landing shortly, golang 2 having first been discussed in 2019 and therefore presumably to happen at some point soonish), any initial implementation of generics would not have particularly constrained what the golang team is now doing.
      - philosopher1234 5y ago
        There will be no Go 2 with breaking changes, it is just a marketing term for go with generics. I'm not fully clued in on the technical challenges with generics, but frankly you don't seem to be either. I know that there has been much ink spilled on the go-nuts mailing list and the issue tracker, as well as 3+ prior attempts at implementing generics, so I don't think it's fair to dismiss the go team's concerns out of hand. Also, even if you were right and the go team simply said one day "we wont add generics lol" that would still be a very shallow reason to dislike the language. After all, that is only one of many aspects of the language, with a specific set of tradeoffs. The rest of the language can hold great value even if it doesn't look like the Hacker News Approved Language.
- maccard 5y ago
  I write golang, and am a big fan, however it lacked/lacks some features that i would expect in a modern language. - Lack of generics(coming very soon) was a huge problem for a long time and resulted in masses of duplicated code, and shonky reimplememtations rather than battle tested reusable implementations. - Lack of sum types, which is particularly frustrating with go's error handling model (which I happen to be a fan of, mostly). The state of a return value depends on another return value in many cases. There is nothing in the language stopping me from using the value returned from a function that has returned an error. Even c++ has a (half baked) solution for this with optional. - go's error handling has a major issue; it forces my model to be able to represent invalid state (see above). Because go doesn't let me have a sum type, I'm forced to return a "valid" return value alongside the error value, which means that state has to be representing in my code. - repetition. Contrary to best practices in every other programming language, the advice given for go on so is frequently "its not that much work to implement the X yourself". Now instead of using an existing well supported library I'm maintaining my own X. - cgo. Performance is terrible, its completely unique compared to every other FFI style system (e.g. see dotnet), and it doesn't work with MSVC. > that took into account & understood the practical tradeoffs Go is making. Just because the language had made decisions because of tradeoffs doesn't make it immune from criticism. If it's OK to criticise c++ for not breaking backwards compatibility (vector<bool> comes to mind), it's OK to criticise go for its shortcomings.
  - philosopher1234 5y ago
    >Just because the language had made decisions because of tradeoffs doesn't make it immune from criticism. If it's OK to criticise c++ for not breaking backwards compatibility (vector<bool> comes to mind), it's OK to criticise go for its shortcomings. I never said it was immune to criticism. I think most of the criticism is misguided. >- go's error handling has a major issue; it forces my model to be able to represent invalid state (see above). Because go doesn't let me have a sum type, I'm forced to return a "valid" return value alongside the error value, which means that state has to be representing in my code. I recognize that this does not perfectly map to your mental model, but why is this a major issue? I think major issues are those that cause practical problems. I also think there is a question of what the cost, in terms of developer cognitive load, would be of adding more advanced modeling features to go. It's a bit like saying "that tire isn't perfect because it can pop, so lets use a metal tire instead". Sure, you fix one issue, but you create others. >- repetition. Contrary to best practices in every other programming language, the advice given for go on so is frequently "its not that much work to implement the X yourself". Now instead of using an existing well supported library I'm maintaining my own X. This is too vague to evaluate. There is a point at which repetition becomes a problem, and there is a point at which repetition is cheaper than having an abstraction. I don't think it can be evaluated in general. > cgo. Performance is terrible, its completely unique compared to every other FFI style system (e.g. see dotnet), and it doesn't work with MSVC. I agree on the factual level that it would be nice if cgo didn't have so much gc overhead. If this is meant to be evidence that go is a bad language, I would disagree.
- necovek 5y ago
  You seem to ask for "ideological bias" and then discount all the brought up examples as "impractical" at the same time. For example, I may dislike a language simply because it has no significant white-space: I just like a programming language to display nicely, for my definition of "nicely". I do understand practical tradeoffs of significant whitespace, yet I still like it: those are not in opposition with each other.
  - philosopher1234 5y ago
    Your definition of nicely and it’s origin can be examined. We can also question what it means for a programming language to be good or bad.
    - necovek 5y ago
      This thread started off with > ...my ideological biases against Go which you turned into a question of whether Go is a good or bad language. That was never brought up. An idealogical bias against Go could be that it was conceived by Google, and that you reject to support increasing Google's influence on the world. This has nothing to do with Go being technically good or bad.
      - philosopher1234 5y ago
        Ok, sure, my terminology could have been more accurate, but I’ve been having perfectly functional conversations with everyone else, so I’m not sure what you’re getting at.
        necovek 5y ago
        None of it seems to have been "functional conversations with everyone else", but instead you asking questions after "ideological biases" were brought up and then dismissing all the answers as irrelevant because they are not clearing any of your "practical" bars. That was at least my impression, and I fully admit that I may have gotten it wrong (I have no skin in this game, I am just portraying what your "conversations" looked like from the sidelines).

Ebiten is actually making me want to get back into Go itself. I'd love to make a cross platform game and it may just motivate me enough to push through my ideological biases against Go.

djur 5y ago

I'm not big on Go either but I feel like it's a good fit for hobbyist game development. It's a lot harder to write automated tests for games, so the value of static typing is higher, but most simple game designs don't really benefit from the powerful type systems of a Rust or Haskell (or even a TypeScript). It's one of the cases where Go actually does feel like a "better C".

chana_masala 5y ago
> but most simple game designs don't really benefit from the powerful type systems of a Rust or Haskell (or even a TypeScript). I get that feeling too but I have no experience with game development. I wonder what reasons you think so?

philosopher1234 5y ago

I've yet to meet an ideological bias against Go that took into account & understood the practical tradeoffs Go is making. The ones I've seen thus far are dismissive and incurious. But if you've got that, I would love to hear it.

halpert 5y ago
To me, Go is just a boring language to write in. It’s target audience is large corporations where individuality is discouraged. I’ve used Go extensively at work, and its lack of expressivity definitely has some upsides on large teams, mainly keeping things simple and understandable. But when I program in my free time for fun, I want to be able to express myself fully.
- philosopher1234 5y ago
  I agree with you that Go is a boring language. I think in Go's boredom is a path to creating better code than you are pushed towards in other languages, and I enjoy writing Go in my free time because I enjoy learning about API design through interacting with the STL, and because I produce programs in it that I understand much more deeply (and with relative ease) than when I try to use another language. However, Go is not a good language for experimenting with cutting edge language features.
chana_masala 5y ago
I actually mostly agree. I just don't really like the aesthetics of writing Go, which I know is a silly reason.
- philosopher1234 5y ago
  I'm not one to call aesthetics silly. The act of reading and writing programs relies heavily on the programmers emotion, and so I think aesthetics matter greatly. What don't you like about them?
YawningAngel 5y ago
I'll bite. I've read all the arguments the creators of golang made for not including generics. They are just as true now as they were when the language was created, and yet generics have now been added. Moreover, they have been added as part of golang 2.0, so any breaking changes that turned out to be needed could have been made now anyway. I think it's pretty reasonable to dislike a language that refuses to implement a basic feature for essentially no reason.
- geodel 5y ago
  This seems rather clueless. The party line was they have not found a way to implement it in a way that satisfy their requirement. Now they have found a way to do so. So I see no contradiction. Also what breaking changes you are talking about I am not aware of any. Also there is no golang 2.0 yet.
  - YawningAngel 5y ago
    > The party line was they have not found a way to implement it in a way that satisfy their requirement. Now they have found a way to do so. So far as I'm aware, every mainstream language, including golang, that's addressed this question has chosen to solve it by monomorphising generic functions. This implementation was well understood when golang was first released, and it isn't remotely plausible that the authors were not aware of it. > Also what breaking changes you are talking about I am not aware of any. Also there is no golang 2.0 yet. An argument given at the time was that committing to an implementation of generics would potentially put golang in an awkward position similar to Java's wherein if the implementation turned out to be bad, the language would be stuck with it anyway for backward compatibility reasons. I am simply pointing out that, since both golang 2 and generics have been discussed roughly contemporaneously (generics landing shortly, golang 2 having first been discussed in 2019 and therefore presumably to happen at some point soonish), any initial implementation of generics would not have particularly constrained what the golang team is now doing.
    - philosopher1234 5y ago
      There will be no Go 2 with breaking changes, it is just a marketing term for go with generics. I'm not fully clued in on the technical challenges with generics, but frankly you don't seem to be either. I know that there has been much ink spilled on the go-nuts mailing list and the issue tracker, as well as 3+ prior attempts at implementing generics, so I don't think it's fair to dismiss the go team's concerns out of hand. Also, even if you were right and the go team simply said one day "we wont add generics lol" that would still be a very shallow reason to dislike the language. After all, that is only one of many aspects of the language, with a specific set of tradeoffs. The rest of the language can hold great value even if it doesn't look like the Hacker News Approved Language.
maccard 5y ago
I write golang, and am a big fan, however it lacked/lacks some features that i would expect in a modern language. - Lack of generics(coming very soon) was a huge problem for a long time and resulted in masses of duplicated code, and shonky reimplememtations rather than battle tested reusable implementations. - Lack of sum types, which is particularly frustrating with go's error handling model (which I happen to be a fan of, mostly). The state of a return value depends on another return value in many cases. There is nothing in the language stopping me from using the value returned from a function that has returned an error. Even c++ has a (half baked) solution for this with optional. - go's error handling has a major issue; it forces my model to be able to represent invalid state (see above). Because go doesn't let me have a sum type, I'm forced to return a "valid" return value alongside the error value, which means that state has to be representing in my code. - repetition. Contrary to best practices in every other programming language, the advice given for go on so is frequently "its not that much work to implement the X yourself". Now instead of using an existing well supported library I'm maintaining my own X. - cgo. Performance is terrible, its completely unique compared to every other FFI style system (e.g. see dotnet), and it doesn't work with MSVC. > that took into account & understood the practical tradeoffs Go is making. Just because the language had made decisions because of tradeoffs doesn't make it immune from criticism. If it's OK to criticise c++ for not breaking backwards compatibility (vector<bool> comes to mind), it's OK to criticise go for its shortcomings.
- philosopher1234 5y ago
  >Just because the language had made decisions because of tradeoffs doesn't make it immune from criticism. If it's OK to criticise c++ for not breaking backwards compatibility (vector<bool> comes to mind), it's OK to criticise go for its shortcomings. I never said it was immune to criticism. I think most of the criticism is misguided. >- go's error handling has a major issue; it forces my model to be able to represent invalid state (see above). Because go doesn't let me have a sum type, I'm forced to return a "valid" return value alongside the error value, which means that state has to be representing in my code. I recognize that this does not perfectly map to your mental model, but why is this a major issue? I think major issues are those that cause practical problems. I also think there is a question of what the cost, in terms of developer cognitive load, would be of adding more advanced modeling features to go. It's a bit like saying "that tire isn't perfect because it can pop, so lets use a metal tire instead". Sure, you fix one issue, but you create others. >- repetition. Contrary to best practices in every other programming language, the advice given for go on so is frequently "its not that much work to implement the X yourself". Now instead of using an existing well supported library I'm maintaining my own X. This is too vague to evaluate. There is a point at which repetition becomes a problem, and there is a point at which repetition is cheaper than having an abstraction. I don't think it can be evaluated in general. > cgo. Performance is terrible, its completely unique compared to every other FFI style system (e.g. see dotnet), and it doesn't work with MSVC. I agree on the factual level that it would be nice if cgo didn't have so much gc overhead. If this is meant to be evidence that go is a bad language, I would disagree.
necovek 5y ago
You seem to ask for "ideological bias" and then discount all the brought up examples as "impractical" at the same time. For example, I may dislike a language simply because it has no significant white-space: I just like a programming language to display nicely, for my definition of "nicely". I do understand practical tradeoffs of significant whitespace, yet I still like it: those are not in opposition with each other.
- philosopher1234 5y ago
  Your definition of nicely and it’s origin can be examined. We can also question what it means for a programming language to be good or bad.
  - necovek 5y ago
    This thread started off with > ...my ideological biases against Go which you turned into a question of whether Go is a good or bad language. That was never brought up. An idealogical bias against Go could be that it was conceived by Google, and that you reject to support increasing Google's influence on the world. This has nothing to do with Go being technically good or bad.
    - philosopher1234 5y ago
      Ok, sure, my terminology could have been more accurate, but I’ve been having perfectly functional conversations with everyone else, so I’m not sure what you’re getting at.
      - necovek 5y ago
        None of it seems to have been "functional conversations with everyone else", but instead you asking questions after "ideological biases" were brought up and then dismissing all the answers as irrelevant because they are not clearing any of your "practical" bars. That was at least my impression, and I fully admit that I may have gotten it wrong (I have no skin in this game, I am just portraying what your "conversations" looked like from the sidelines).