• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Chris_F

Does any interest in the Go language still exist?

48 posts in this topic

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

Share this post


Link to post
Share on other sites
rust is better :)

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

Share this post


Link to post
Share on other sites
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.
1

Share this post


Link to post
Share on other sites
[quote name='King Mir' timestamp='1342421726' post='4959480']
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.
[/quote]

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

Share this post


Link to post
Share on other sites
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
1

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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:

[url="http://commandcenter.blogspot.it/2012/06/less-is-exponentially-more.html"]http://commandcenter...ally-more.html[/url]

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
2

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
[quote name='Telastyn' timestamp='1342484882' post='4959818']
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.
[/quote]

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

Share this post


Link to post
Share on other sites
Try the [url="http://tour.golang.org/"]Go tour[/url], it will teach you general programming lessons too.
1

Share this post


Link to post
Share on other sites
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.
1

Share this post


Link to post
Share on other sites
[quote name='Telastyn' timestamp='1342650380' post='4960681']
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.
[/quote]

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 [img]http://public.gamedev.net//public/style_emoticons/default/rolleyes.gif[/img] , and prettier than the real code that would take pointers instead of values.
0

Share this post


Link to post
Share on other sites
[quote name='kunos' timestamp='1342683267' post='4960829']
They specifically decided not to include it in the language, the irony is that there are built in functions that expose a "generic" behaviour
[/quote]

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:
[quote]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!).
[/quote]
(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 [url="http://godashboard.appspot.com/project"]open source libraries[/url] will never be easy again.
0

Share this post


Link to post
Share on other sites
[quote name='zippoxer' timestamp='1342688615' post='4960851']
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 [url="http://godashboard.appspot.com/project"]open source libraries[/url] will never be easy again.
[/quote]

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

Share this post


Link to post
Share on other sites
[quote name='zippoxer' timestamp='1342688615' post='4960851']
... operator overloading is a nightmare when reading code, even more than macros:
[quote]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.
[/quote]
[/quote]

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

[quote]
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
[/quote]
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.

[quote]
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!).
[/quote]
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).
0

Share this post


Link to post
Share on other sites
[quote name='zippoxer' timestamp='1342688615' post='4960851']
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.
[/quote]

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
0

Share this post


Link to post
Share on other sites
[quote name='Codarki' timestamp='1342693407' post='4960876']
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).
[/quote]

Yes, overloaded operators should be simple and when done properly massively [i]improve[/i] 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.
0

Share this post


Link to post
Share on other sites
Beyond smart pointers and vector types, I have never personally seen a use for operator overloading that I didn't think was inappropriate or unfortunate.

If I designed a language I think I might include OpenGL like Vec types and bignums as built-ins and then leave operator overloading out. Edited by Chris_F
0

Share this post


Link to post
Share on other sites
Yeah operator overloading is nice to have. Java's .equals and .compareTo methods are annoying to use. Also if you ever want to write a class that behaves like a primitive type with a slight addition, it's messy without operator overloading.

The one alternative to operator overloading like c++ is concepts/kinds like in Haskell. Then you could allow operators to be used only to mean one thing, but can write classes that work like primitive types by implementing the same Concept.
0

Share this post


Link to post
Share on other sites
[quote name='kunos' timestamp='1342467979' post='4959705']
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).
[/quote]
both link and generics are compile time and thus have ZERO performance issues. they do have tremendous impact on writing code fast, and writing it correct. typesavety rocks.

where you need to go outside of typesavety (especially common in the webworld with json and that crap), dynamic is there for you. it is, again, language sugar that typically is nothing more than a nice dictionary.

so languages helping you code properly and easy are stupid, then? maybe that's the reason nobody cares much about go. those who actually want to do stuff don't consider languages that help a developer a bad thing.
0

Share this post


Link to post
Share on other sites
[quote name='davepermen' timestamp='1342765569' post='4961194']
[quote name='kunos' timestamp='1342467979' post='4959705']
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).
[/quote]
both link and generics are compile time and thus have ZERO performance issues. they do have tremendous impact on writing code fast, and writing it correct. typesavety rocks.
[/quote]

what I meant is.. if the Go dev team is concentrated on designing and writing generics, they cannot concentrate to improve the quality of compiled code.
And I think performance should be the entire point in Go. If you add generics and all the other stuff and make it a C#/Python clone what's the point in using Go anyway?
Right now the performances are better than python but they are behind .NET... they should spend all the energy to fix this fact.

There is an interesting thread on the golang-nuts group about the user case for having generics.. at the end, with only some exceptions, all those case are perfectly managed using Go's interfaces and duck typing... so dismissing a language because it doesnt have this feature is pretty close minded IMO and totally missing the point. If you want a language with EVERYTHING and I mean EVERYTHING then take D... again, Go's motto is less is more , and having been coding in Go both in production and hobby code for more than a couple of months now I can say it is a breath of fresh air, everything is so simple, but simple in a different way.. it's simple because the language is so small and well thought out that you _NEVER_ find yourself fighting it.
0

Share this post


Link to post
Share on other sites
[quote name='Chris_F' timestamp='1342749307' post='4961133']
Beyond smart pointers and vector types, I have never personally seen a use for operator overloading that I didn't think was inappropriate or unfortunate.

If I designed a language I think I might include OpenGL like Vec types and bignums as built-ins and then leave operator overloading out.
[/quote]

Off the top of my head: complex numbers, quaternions, dual numbers (automatic differentiation! best when combined with generics), dual complex numbers/quaternions, modulo arithmetic...

[quote name='davepermen' timestamp='1342765569' post='4961194']
both link and generics are compile time and thus have ZERO performance issues.
[/quote]

Except that the Go developers seem to care more about compile time performance than anything else so far.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0