48 replies to this topic

[Chris_F]

It seems like there was some hype for it a few years ago that has sort of diminished. I've just started examining it and I'm pretty interested in it now. I searched the forums but I only found a few threads that made any reference to it, and they were all 2 years old. I'm interested to know if there is anyone here using Go and whether or not there is realistically any chances of it being practical for game development.

[saejox]

rust is better

but there is no need for both, imo.
c++11 has all the features i need.

[King Mir]

Go 1 was released in march, the first stable version. So it's more practical now than it's ever been.

I haven't played with Go myself, but I think it's lack of OOP and generics makes it inferior to alternatives. OTOH, I do think their channels are a superior form of thread communication in many cases.

[Chris_F]

... I think it's lack of OOP

What?

Go has support for objects, methods, encapsulation, polymorphism, and a form of inheritance through embedding. How then does it not support OOP? Classes + rigid type inheritance hierarchies are just one implementation of OOP, and apparently one that Google thinks is inefficient.

Go's concept of interfaces is the main reason, next to it's concurrency model, that makes me interested in it in the first place.

[saejox]

Go 1 was released in march, the first stable version. So it's more practical now than it's ever been.

I haven't played with Go myself, but I think it's lack of OOP and generics makes it inferior to alternatives. OTOH, I do think their channels are a superior form of thread communication in many cases.

Rust has classes and templates.

but it doesnt matter. world really does not need any more system programming languages.
they all does the same. one can argue that C++ has nothing over C.

[Chris_F]

but it doesnt matter. world really does not need any more system programming languages.
they all does the same. one can argue that C++ has nothing over C.

Yes, I suppose you could argue that, but I wouldn't. People wouldn't be developing new systems languages if they didn't think there were deficiencies in the current set of commonly used programming languages. Just for example, horrendously slow compile times. But the list is a mile long so I'll leave it at that.

Edited by Chris_F, 16 July 2012 - 01:40 AM.

[Inferiarum]

Just went through the go tour and i have to say the language is really attractive. Class inheritance is overrated anyway, and the focus on interfaces leads to better software design in my opinion.

I also like the concurrency syntax.

edit: Concerning game programming, I guess it is not the best idea to use a language (almost) no one else uses. You would have to write (almost) everything from scratch.

Edited by Inferiarum, 16 July 2012 - 01:13 PM.

[smr]

I have more than a passing interest in it, but I am not really going to play with it until there is a decent set of tools and a working debugger. Goclipse is a work in progress, and when it's most stable I'll probably toy around with Go.

[kunos]

I love it and hope it will mature enough to be my language of choice in the future. For now I am writing the race server of my new game in Go. I love its simplicity, I don't like "eat all you can" languages that try to include any feature from any language into a unmanageable mess that requires company "guidelines" (which turn out being a long list of "dont do this and don't do that") to be used in a team. I think Rob Pike can put this into words much better than I can hope to do:

http://commandcenter...ally-more.html

I think Go's main feature IS simplicity, here it is the language, here it is the code format, learn it in 2 weeks, and now let's get work done.. so I wouldn't like to see things like Generics, Overloading and so on come into the language, even if they are things I constantly use in C++.

I hope they stick with it, don't go after any of the Linq / Dynamic / Generic things but instead work on the compiler to make it FAST (runtime).

Edited by kunos, 16 July 2012 - 01:51 PM.

[return0]

What do you mean 'wont go after Linq'? Linq is just functions on data sets.

[Telastyn]

I'm always interested in hearing more about programming language features, though I've heard from others that the lack of generics is a large pain point. That and the interface OO tends to lead to a lot of downcasting. Nothing that is insurmountable, but it seems from the sidelines as if it's not mature.

[zippoxer]

I'm always interested in hearing more about programming language features, though I've heard from others that the lack of generics is a large pain point. That and the interface OO tends to lead to a lot of downcasting. Nothing that is insurmountable, but it seems from the sidelines as if it's not mature.

The lack of generics is not a sign of immaturity... The Go team intentionally left out generics and many other features. Once you give Go a try, there's a chance you'll understand how leaving so many "great" features out can make a programming language greater.

The average application I write takes me far less time to write and bugs to fix in Go than in C#/Java, with all it's lack of overrated features.

[zippoxer]

Try the Go tour, it will teach you general programming lessons too.

[Telastyn]

I'm not saying lack of generics is a sign of immaturity. I'm saying that the near constant annoyance using the language that I've heard from people I very highly respect who have lots of experience with lots of languages makes me think that the language hasn't had enough development time to address these annoyances.

It is not terribly surprising given how old it is; programming languages have a _really long_ feedback loop compared to other software.

[kunos]

I'm not saying lack of generics is a sign of immaturity. I'm saying that the near constant annoyance using the language that I've heard from people I very highly respect who have lots of experience with lots of languages makes me think that the language hasn't had enough development time to address these annoyances.

It is not terribly surprising given how old it is; programming languages have a _really long_ feedback loop compared to other software.

They specifically decided not to include it in the language, the irony is that there are built in functions that expose a "generic" behaviour. But the debate is still on, the 2 main things that come up seem to be generics and "proper enums".

My only real problem with the language is the missing operator overload, I write a lot of math in my software and I am forced to go from C++:

auto result= f * 1.2f + vec3f(10.0f, 0, 1.0f) * anotherVector;

to something like:

result := f.MultFloat32( 1.2f).Add( (Vec3f{10.f, 0, 1.0f}).Mult(anotherVector))

Which is.. ahem... inconvenient , and prettier than the real code that would take pointers instead of values.

[zippoxer]

They specifically decided not to include it in the language, the irony is that there are built in functions that expose a "generic" behaviour

The Go standard library has thousands of lines of codes and not one use of container/*. The lack of generics is an imaginary problem. The lack of operator overloading too. In fact, operator overloading is a nightmare when reading code, even more than macros:

In general, I have to admit that I’m a little bit scared of language features that hide things. When you see the code
i = j * 5;

… in C you know, at least, that j is being multiplied by five and the results stored in i.
But if you see that same snippet of code in C++, you don’t know anything. Nothing. The only way to know what’s really happening in C++ is to find out what types i and j are, something which might be declared somewhere altogether else. That’s because j might be of a type that has operator* overloaded and it does something terribly witty when you try to multiply it. And i might be of a type that has operator= overloaded, and the types might not be compatible so an automatic type coercion function might end up being called. And the only way to find out is not only to check the type of the variables, but to find the code that implements that type, and God help you if there’s inheritance somewhere, because now you have to traipse all the way up the class hierarchy all by yourself trying to find where that code really is, and if there’s polymorphism somewhere, you’re really in trouble because it’s not enough to know what type i and j are declared, you have to know what type they are right now, which might involve inspecting an arbitrary amount of code and you can never really be sure if you’ve looked everywhere thanks to the halting problem (phew!).

(from http://www.joelonsoftware.com/articles/Wrong.html)

When you actually write programs in Go, you'll realize that all these decisions made by great programmers from the Go team have a really good reason. I'll abandon Go if it will ever support generics and operator overloading. Because then, reading the standard library or the open source libraries will never be easy again.

[kunos]

When you actually write programs in Go, you'll realize that all these decisions made by great programmers from the Go team have a really good reason. I'll abandon Go if it will ever support generics and operator overloading. Because then, reading the standard library or the open source libraries will never be easy again.

+1

Just to clarify I wasn't complaining about operator overloading because I understand the rationale behind the decision to keep them out, they can hide a very costly operation behind a simple "+" , yes it makes my code uglier but it also makes it more explicit... and there it is one more thing that a junior developer will not have to learn before starting doing and understanding real code.

[Codarki]

... operator overloading is a nightmare when reading code, even more than macros:

In general, I have to admit that I’m a little bit scared of language features that hide things. When you see the code
i = j * 5;

… in C you know, at least, that j is being multiplied by five and the results stored in i.
But if you see that same snippet of code in C++, you don’t know anything. Nothing.

If i = j * 5 does something unexpected in C++, that programmer should be fired.

The only way to know what’s really happening in C++ is to find out what types i and j are, something which might be declared somewhere altogether else. That’s because j might be of a type that has operator* overloaded and it does something terribly witty when you try to multiply it. And i might be of a type that has operator= overloaded, and the types might not be compatible so an automatic type coercion function might end up being called

The types are int. Most likely the type information is right next to the expression. If the type of j is not int, and you want to multiply it with 5, then you overload an operator. If the type of i is not int, and it must be assignable from int (or whatever type the j is), then assignment operator must be overloaded. Also, implicit conversions are very commonly avoided.

Now whatever 'witty' C++ example you can imagine (which doesn't do something unexpected, like logging the result over a netword), try to think how you would do the same functionality without operator overloading.

And the only way to find out is not only to check the type of the variables, but to find the code that implements that type, and God help you if there’s inheritance somewhere, because now you have to traipse all the way up the class hierarchy all by yourself trying to find where that code really is, and if there’s polymorphism somewhere, you’re really in trouble because it’s not enough to know what type i and j are declared, you have to know what type they are right now, which might involve inspecting an arbitrary amount of code and you can never really be sure if you’ve looked everywhere thanks to the halting problem (phew!).

Public interface for the types should be enough, no need to check the implementation code.
I'd say if there is inheritance, and overloaded operators for derived and base classes, the design might be shaky.
If you need to know the real derived type of polymorphic variable, you are violating liskov substitution principle and abusing inheritance.

Sure, you can abuse everything in C++ and say 'see the language is bad', you can abuse regular functions by naming them all 'Fred_X' with a number. IMO that doesn't warrant a language that keeps you in safe-jacket. Bad programmers should be fired, and nobody (hopefully) does intentionally cryptic code.

Usually overloaded operators contain the most simple and bugfree code. Using them provides very simple syntax. If they are the cause of unexpected effects or source of bugs, then whoever wrote them is at blame (and should be fired).

[l0calh05t]

When you actually write programs in Go, you'll realize that all these decisions made by great programmers from the Go team have a really good reason. I'll abandon Go if it will ever support generics and operator overloading. Because then, reading the standard library or the open source libraries will never be easy again.

Meh. When generics are supported I will become interested in Go again. Generics are absolutely vital. Heck, Go's map is already a generic type, so obviously there is some necessity there. But we aren't allowed to create any. Right.

What also annoys me to no end though is that they routinely trade run time for compile time. Great the compiler is fast, but the programs are slow (and fraggin huge). But in any real world application, the number of program executions should be far higher than the number of compiles. If execution speed is unimportant, I might just as well stick with Python.

Not to say everything is bad about go. The concept of interfaces is very nice. Also love the defer statement. And a bunch of other stuff too. But no generics = no thanks.

Edited by l0calh05t, 19 July 2012 - 05:01 AM.

[l0calh05t]

Sure, you can abuse everything in C++ and say 'see the language is bad', you can abuse regular functions by naming them all 'Fred_X' with a number. IMO that doesn't warrant a language that keeps you in safe-jacket. Bad programmers should be fired, and nobody (hopefully) does intentionally cryptic code.

Usually overloaded operators contain the most simple and bugfree code. Using them provides very simple syntax. If they are the cause of unexpected effects or source of bugs, then whoever wrote them is at blame (and should be fired).

Yes, overloaded operators should be simple and when done properly massively improve readability. The main issue I personally see when looking at C++ is that the standard library itself abuses operators (iostreams...) creating a bad example for new programmers and leading them to abuse operator overloading as well.