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

The State of Go: Where we are in February 2016

talks.golang.org

Post reply on HN
Print view View original

81–90 of 224 posts

Re: The State of Go: Where we are in February 2016

#81

Post by malkia »

martijn_himself wrote: post #17

A Golang beginner's question: do these GC improvements make Golang a suitable language/ platform for writing games? EDIT: I realise this is a vague question. I suppose I was wondering if the order of magnitude GC performance in Go is likely to interfere with game loops you might find in reasonably CPU/ GPU intensive Indie games (i.e. NOT Crysis).

To be honest, for 60fps, and now with VR - 120fps and more - it won't be good enough. But... I could be wrong... Lots of games do have additional scripting languages (.gsc in COD games, lua in others, etc., etc.) - these all have garbage collectors. The key to control that is checking your high watermarks (while playing the level), and doing incremental GC.

Whether you can write the whole game in it - I don't know, but it'll be pretty good for tools/editors/pipeline/etc.

Re: The State of Go: Where we are in February 2016

#82

Post by krisdol »

iends wrote: post #57
armitron wrote: post #36

Am I in the minority to think of Go as a completely unnecessary move-along-now-nothing-to-see-here project? (as if we didn't have enough of that already). The only niche I see for it is for those poor souls who are still wasting their time with Python/Ruby but that by itself surely can't lead to great things for the language, especially since it's riding on air. More dense air than Python but air nonetheless. Also Ro…

The value of Go is: 1) Reasonably fast (better than Node at CPU bound tasks, faster than Ruby/Python) 2) Statically compiled 3) Great tooling (except package management, but it's getting better) If you want a reasonably fast statically compiled language, what would you use? Java? Lots of JEE/App server issues to consider TypeScript? I'm a fan, but it's compile time type checking and not runtime type checking. TypeClo…

>If you want a reasonably fast statically compiled language, what would you use?

I'd go for rust.

Re: The State of Go: Where we are in February 2016

#83

Post by martijn_himself »

heavenlyhash wrote: post #67
martijn_himself wrote: post #17

A Golang beginner's question: do these GC improvements make Golang a suitable language/ platform for writing games? EDIT: I realise this is a vague question. I suppose I was wondering if the order of magnitude GC performance in Go is likely to interfere with game loops you might find in reasonably CPU/ GPU intensive Indie games (i.e. NOT Crysis).

I would say "yes", based on this project: https://github.com/thinkofdeath/steven It's a voxel game based on OpenGL. It implements much of vanilla minecraft. Annecdotally, I'd say it performs much better for me than minecraft itself does, at longer view distances, and with essentially no observable GC pauses (of which minecraft suffers quite visibly). Also, a stabler heap size, etc. The capabilities are definitely the…

I can't access that link at the moment but I will have a look at it, thank you. I had exactly the same idea- to play around with bindings to OpenGL and build some demos.

Re: The State of Go: Where we are in February 2016

#84

Post by amelius »

BenoitP wrote: post #2

The Go runtime is really starting to look sexy. 20 ms GC pauses on 200+ GB heaps! I remember a thread discussing a pauseless GC on the dev mailing-list; where Gil Tene, of Azul C4's fame, commented on having a clear policy on safepoints from the beginning was paramount to having a good GC. It looked like the community is very biased towards doing the fundamental things well, and attracting the right people. And on to…

The only thing missing is a good binding to a javascript engine, for code that has to run on both client and server.

Re: The State of Go: Where we are in February 2016

#85

Post by jvehent »

schmichael wrote: post #79

At work (Lytics) 100% of our backend code has been in Go since the beginning over 3 years ago, so slide #6 highlights one of the most things with nearly every Go release: > Changes to the language: None https://talks.golang.org/2016/state-of-go.slide#6 We generally get our entire stack upgraded to the latest release within 1-3 months with little effort. It wouldn't be much more work to be ready to upgrade on release…

This is my experience as well. The only thing that somewhat breaks between Go project is vendoring (or lack thereof). But in comparison to the pain of supporting python applications that must run on everything from 2.6.6 to 3.5, Go is a walk in the park.

Re: The State of Go: Where we are in February 2016

#86

Post by voidlogic »

pcwalton wrote: post #77
voidlogic wrote: post #71

Earlier quoted context omitted.

Have you benched "myPool.Get()" vs "myPool.Get().(*myStruct)" ? I don't think the "type manipulation" is the problem you think it is.

At the x86 level, myPool.Get(Index) is going to be at least as expensive as cmp/jae/mov (3 cycles), and myPool.Get().(myStruct) is going to be at least as expensive as cmp/jae/cmp/jne/mov (5 cycles). So unless you have some way of hiding the latency, the type check is 67% slower by cycle count. The experience of every JIT developer is that dynamic type checks do matter a lot in hot paths.

This is a small fixed cost as compared to the cost of not using the pool. I wasn't suggesting the operation is free.

Re: The State of Go: Where we are in February 2016

#87

Post by ebbv »

masklinn wrote: post #43
ebbv wrote: post #37

Their solution to the template whitespace thing underlines a fundamental difference between what the Go core developers consider to be good language/library design and what I do. To me adding the - to the template tag {{foo -}} to get rid of whitespace on that side of the tag is totally unintuitive and a really kludgy solution. Sure, it's terse and being terse can be nice, but terseness to me probably doesn't even ma…

This change simply draws from Jinja, which has had this feature for nearly 10 years[0]. It's a simple and efficient solution to the problem of trimming whitespace on either side of a template tag, I fail to see what is kludgy about it (and intuitiveness is in the eye of the beholder). In my experience it's clear, simple and doesn't make the template less readable. > Sure, it's terse and being terse can be nice, but t…

> The whole point of this feature is to be terse...

I get that. I don't think you understood my objection, which was that being terse is not as important to me as being elegant and easily understood. {{foo -}} is not clear looking at it what that - is gonna do. You have to already know, or look it up. There is basically no way to know from context what the desired behavior is. That's bad design IMHO.

Re: The State of Go: Where we are in February 2016

#88

Post by ebbv »

jerf wrote: post #63
ebbv wrote: post #37

Their solution to the template whitespace thing underlines a fundamental difference between what the Go core developers consider to be good language/library design and what I do. To me adding the - to the template tag {{foo -}} to get rid of whitespace on that side of the tag is totally unintuitive and a really kludgy solution. Sure, it's terse and being terse can be nice, but terseness to me probably doesn't even ma…

It's worth observing that while text/template may ship with the core code, it's a very, well, library-y library. Get 10 programmers together and ask about text templating and you'll probably get 11 answers. It's very easy to replace it with whatever floats your boat; it's not deeply integrated into anything else, and just ties in to very standard io.Writer interfaces and such. Bikeshedding about text/template really…

That's a fair point, but official libraries should be held to a higher standard, I think.

Re: The State of Go: Where we are in February 2016

#89

Post by kasey_junk »

schmichael wrote: post #79

At work (Lytics) 100% of our backend code has been in Go since the beginning over 3 years ago, so slide #6 highlights one of the most things with nearly every Go release: > Changes to the language: None https://talks.golang.org/2016/state-of-go.slide#6 We generally get our entire stack upgraded to the latest release within 1-3 months with little effort. It wouldn't be much more work to be ready to upgrade on release…

Can you speak to why you were behind latest on the JVM? I can think of less than a handful of breaking changes over the last 15 years. I'd say it was more stable than Go.

Re: The State of Go: Where we are in February 2016

#90

Post by Cyph0n »

jvehent wrote: post #85
schmichael wrote: post #79

At work (Lytics) 100% of our backend code has been in Go since the beginning over 3 years ago, so slide #6 highlights one of the most things with nearly every Go release: > Changes to the language: None https://talks.golang.org/2016/state-of-go.slide#6 We generally get our entire stack upgraded to the latest release within 1-3 months with little effort. It wouldn't be much more work to be ready to upgrade on release…

This is my experience as well. The only thing that somewhat breaks between Go project is vendoring (or lack thereof). But in comparison to the pain of supporting python applications that must run on everything from 2.6.6 to 3.5, Go is a walk in the park.

Python is entirely different; the two languages cannot be compared with regards to backwards compatibility.

Python has been around since the early 90s, while Go was conceived very recently. Sooner or later, the quirks that resulted from designing the language so long ago had to be addressed, and that's why there's Python 3. The same can be seen in Java and Ruby.

Once Go is used actively for ~9 years (Python 2.0 to 3.0) and suffers no changes that break backwards compatibility, we can compare it with Python.

Post reply on HN