Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Compiling a Go program into a native binary for Nintendo Switch

ebiten.org

Post reply on HN
Print view View original

21–30 of 46 posts

Re: Compiling a Go program into a native binary for Nintendo Switch

#21

Post by YawningAngel »

philosopher1234 wrote: post #15
chana_masala wrote: post #12

Earlier quoted context omitted.

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.

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.

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.

Re: Compiling a Go program into a native binary for Nintendo Switch

#22

Post by geodel »

YawningAngel wrote: post #21
philosopher1234 wrote: post #15

Earlier quoted context omitted.

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.

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 implemen…

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.

Re: Compiling a Go program into a native binary for Nintendo Switch

#23

Post by YawningAngel »

geodel wrote: post #22
YawningAngel wrote: post #21

Earlier quoted context omitted.

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 implemen…

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.

> 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.

Re: Compiling a Go program into a native binary for Nintendo Switch

#24

Post by linux2647 »

djur wrote: post #13
hu3 wrote: post #2

Hajime Hoshi is a true gem and the Go ecosystem is incredibly lucky to have him. He was very approachable and friendly when I was toying with game development in Go. I should get back to finishing that game in Ebiten. The tooling alone puts a smile on my face.

Which tooling in particular?

I'm guessing they're referring to Ebiten, a 2D library for game programming in Go: https://ebiten.org/

Re: Compiling a Go program into a native binary for Nintendo Switch

#25

Post by maccard »

philosopher1234 wrote: post #15
chana_masala wrote: post #12

Earlier quoted context omitted.

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.

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.

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 comes to mind), it's OK to criticise go for its shortcomings.

Re: Compiling a Go program into a native binary for Nintendo Switch

#26

Post by philosopher1234 »

maccard wrote: post #25
philosopher1234 wrote: post #15

Earlier quoted context omitted.

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.

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…

>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 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.

Re: Compiling a Go program into a native binary for Nintendo Switch

#27

Post by halpert »

philosopher1234 wrote: post #15
chana_masala wrote: post #12

Earlier quoted context omitted.

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.

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.

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.

Re: Compiling a Go program into a native binary for Nintendo Switch

#28

Post by philosopher1234 »

YawningAngel wrote: post #23
geodel wrote: post #22

Earlier quoted context omitted.

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.

> 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 we…

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.

Re: Compiling a Go program into a native binary for Nintendo Switch

#29

Post by philosopher1234 »

halpert wrote: post #27
philosopher1234 wrote: post #15

Earlier quoted context omitted.

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.

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.

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.

Re: Compiling a Go program into a native binary for Nintendo Switch

#30

Post by necovek »

philosopher1234 wrote: post #15
chana_masala wrote: post #12

Earlier quoted context omitted.

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.

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.

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.

Post reply on HN