61–70 of 224 posts
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…
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…
cf http://www.perl.com/pub/2001/01/tt2.html
> If these tags are replaced with [%- -%] then the preceding or following linefeed is suppressed.
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…
Bikeshedding about text/template really is just bikeshedding about text/template moreso than Go qua Go.
How the Go GC does comparing with the JVM one ?
JVM's gc is most likely significantly better. On the other hand golang's gc needs to collect less objects, in some cases orders of magnitude less. If you compare a slice of structs with 1000 elements, it'll be one object (and allocation) in golang. Equivalent array in JVM requires the array itself + 1000 Objects, 1001 allocations. In this case, golang has lot less object graph to gc. Of course slice of 1000 interface…
Both of these can dramatically reduce GC pressure too.
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…
> Java? Lots of JEE/App server issues to consider
Why? Why not just package as an assembly, scp it up to a server, fire up Netty in a main-class and call it a day (this is basically all Play Framework does)?
It's going to be faster/simpler in every way than any Ruby/Nginx stack you can imagine. No need to fight with matching cores to processes per deployment, no unnecessary proxies or additional services to watch/manage.
Sure you can go crazy. Or maybe even need to for some use case, but even in that scenario you can bet your business on the fact that it'll still be a far simpler solution than the comparable dynamic stack.
Not that I'm advocating Java exactly. I just feel like if deployment/server-issues are an issue, compared to a dynamic stack with similar throughput, then you've done something horribly horribly nightmarishly wrong. ;-)
I'm wondering how it holds up without compaction and in the face of fragmented heaps.
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).
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 there.
I'm spending some of my weekend moments playing around with more GL stuff based on what I've learned from reading this project, and it's quite fun. Build times are right up there where you'd expect, too -- seconds or less! (The first build takes a few moments for running gcc for the c bindings to GL, but after that, those cache nicely.) A 1-second turnaround for recompiling a whole game is an incredible breath of fresh air.
And of course, I shipped my demo game to a friend on a mac the same day I started writing. I'm on a linux. Not bad.
Earlier quoted context omitted.
JVM's gc is most likely significantly better. On the other hand golang's gc needs to collect less objects, in some cases orders of magnitude less. If you compare a slice of structs with 1000 elements, it'll be one object (and allocation) in golang. Equivalent array in JVM requires the array itself + 1000 Objects, 1001 allocations. In this case, golang has lot less object graph to gc. Of course slice of 1000 interface…
Go is also better about allocating on the stack (vs heap) and provides a very solid pool implementation (sync.Pool). Both of these can dramatically reduce GC pressure too.
So the golang pool is good for the case where you have GC heavy but non-latency sensitive operations, but not the more general performance sensitive problems.
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).
Given that a Go 1.6 GC will still take about 4ms, you have 12.7ms to generate a frame, which can be too limiting for some CPU-intensive games, but is perfectly acceptable for many games.
(In Go 1.5, a GC was much more likely to make you drop a frame, as it could easily average 40ms.)
On the other hand, there are less high-quality libraries in Go than in C++ or in JS. That may be the most limiting factor.
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).