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

21–30 of 224 posts

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

#21

Post by mrweasel »

masklinn wrote: post #9
mrweasel wrote: post #4

{{range . -}} {{.}} {{end -}} This seems like a bit of a hack to be honest. Would anything break if {{range .}} {{.}} {{end}} worked as expected?

It would become unusable for general-purpose text templating[0], and would either break interspersing dynamic text ("this is {{ name }}" with name=Bob would be rendered as "this isBob") within static text or would need a semantic understanding of HTML. And even then the presence or absence of whitespace in HTML does have rendering impacts (though I don't remember one offhand — aside from linebreaks — it's been a long…

I just think that a simpler solution would be to always ignore the first line break after the range begin and end tags. I can't really see the case where that would cause an issue, if you REALLY do need the "extra" line break just put it inside the range.

Whitespaces shouldn't be touched, just parse them though and don't process them.

That would make the templates look more like those of Django and Jinja2, which most seem comfortable with.

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

#22

Post by masklinn »

mrweasel wrote: post #21
masklinn wrote: post #9

Earlier quoted context omitted.

It would become unusable for general-purpose text templating[0], and would either break interspersing dynamic text ("this is {{ name }}" with name=Bob would be rendered as "this isBob") within static text or would need a semantic understanding of HTML. And even then the presence or absence of whitespace in HTML does have rendering impacts (though I don't remember one offhand — aside from linebreaks — it's been a long…

I just think that a simpler solution would be to always ignore the first line break after the range begin and end tags. I can't really see the case where that would cause an issue, if you REALLY do need the "extra" line break just put it inside the range. Whitespaces shouldn't be touched, just parse them though and don't process them. That would make the templates look more like those of Django and Jinja2, which most…

> Whitespaces shouldn't be touched, just parse them though and don't process them.

That's what html/template does by default, the point of the addition is this can be inconvenient as you may want whitespace for source readability but can't have whitespace in the output.

> That would make the templates look more like those of Django and Jinja2, which most seem comfortable with.

The behaviour outlined here is the same as jinja's: output text nodes as-is by default (whitespace and all), specify `-` to trim whitespace on the corresponding side of a template item.

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

#23

Post by masklinn »

Sir_Cmpwn wrote: post #20
masklinn wrote: post #9

Earlier quoted context omitted.

It would become unusable for general-purpose text templating[0], and would either break interspersing dynamic text ("this is {{ name }}" with name=Bob would be rendered as "this isBob") within static text or would need a semantic understanding of HTML. And even then the presence or absence of whitespace in HTML does have rendering impacts (though I don't remember one offhand — aside from linebreaks — it's been a long…

Whitespace inserts a text node in the DOM. I think.

Whitespace is text, yes?

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

#24

Post by panamafrank »

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

yes and no, while the previous GC pauses wouldn't have really affected anything the size of a hobby game, the improvements are welcome. The bigger problem with Go regarding game development is operator overloading and interfacing with C, the latter being a pain when it comes to memory management.

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

#25

Post by rhodysurf »

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…

Oh wow thanks for pointing out gonum! Definitely going to be playing around with this.

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

#26

Post by FenugreekAcerb »

skj wrote: post #11
FenugreekAcerb wrote: post #3

Why is there a "women who go" and not a "men who go"? EDIT: Just to be clear, I don't have nothing against women. I just think that treating them "differently" is not the solution. The moment you treat them differently you are discriminating.

Because when a man goes, no one looks at him funny.

Why someone should look funny at a woman?

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

#27

Post by Cshelton »

skj wrote: post #11
FenugreekAcerb wrote: post #3

Why is there a "women who go" and not a "men who go"? EDIT: Just to be clear, I don't have nothing against women. I just think that treating them "differently" is not the solution. The moment you treat them differently you are discriminating.

Because when a man goes, no one looks at him funny.

Yes, but at the same time, Women are tired of being treated like they're special. All of my friends who are women and engineers(or similar) would much rather be called an "engineer", not a "woman engineer". They HATE that. Treat them as equals. By giving them all these special titles and groups, the message somewhat becomes, "hey, you can't really compete with us, so we have you special groups where you can thrive and feel good about yourself." Actually talk to the majority of women out there, they don't want that. They want to compete in the same field as men.

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

#28

Post by vardump »

siscia wrote: post #12

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 interfaces or pointers faces the same 1001 issue in golang as well.

You could emulate same gc load cost in JVM at cost of runtime performance by storing the objects in a byte array and [de]serialize as needed, but that's neither idiomatic or acceptable solution most of the time.

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

#29

Post by martijn_himself »

panamafrank wrote: post #24
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).

yes and no, while the previous GC pauses wouldn't have really affected anything the size of a hobby game, the improvements are welcome. The bigger problem with Go regarding game development is operator overloading and interfacing with C, the latter being a pain when it comes to memory management.

Would these GC improvements put Golang in the same league as C# (which is widely used for game development e.g. Unity3D, the .NET runtime has a GC) or can these comparisons not be made?

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

#30

Post by pjmlp »

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

It all depends on which games people intend to write.

Apparently younger generations are unaware that C was seen as a managed language in the 80's and early 90's, with compilers not generating good enough code for game development.

In the 90's I have seen lots of Turbo Pascal and C code where the functions where plain wrappers for inline Assembly.

So unless you intend to write Crysis in Go, there are lots of games you can write with it.

Post reply on HN