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

31–40 of 224 posts

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

#31

Post by FenugreekAcerb »

Cshelton wrote: post #27
skj wrote: post #11

Earlier quoted context omitted.

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 an…

This is why I posed the original question. Treating somebody "differently" is discriminatory. We should deal with those that look funny at women and not treat women in a special manner.

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

#32

Post by pjmlp »

martijn_himself wrote: post #29
panamafrank wrote: post #24

Earlier quoted context omitted.

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?

As heads up when talking about Unity3D, please be aware of the pre-historic .NET runtime they still are shipping versus what Xamarin and Microsoft deliver.

So always take the JIT/GC complains in Unity3D context with that caveat in mind.

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

#33

Post by pjmlp »

vardump wrote: post #28
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 interface…

Hopefully Java will get value types around version 10, but that is still quite far away.

In the meantime, Azul and IBM JVMs JITs are able to optimize "value types" if the classes follow certain patterns or with some annotation help.

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

#34

Post by leaveyou »

vardump wrote: post #28
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 interface…

Could you explain what essential things JVM does better than Go at this point ? Does it stop the world less ? Or does it do more things in parallel ? Thanks

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

#36

Post by armitron »

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 Rob Pike. If there's a guy with the king midas touch of shit, it's Pike.

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

#37

Post by ebbv »

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 make it into my top 10 concerns when designing a language or library.

In my mind a lot more thought and consideration should be put into solutions for problems that are going into core libraries. Stuffing cute hacks into the core libraries willy nilly leads you to PHP. The consequences of which I deal with daily.

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

#38

Post by ebbv »

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?

The problem then is what whitespace do you keep and what do you ditch? The default behavior you want is to maintain everything inside. But I agree the - tag seems like a really inelegant hack.

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

#39

Post by arthurbrown »

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…

Funny that you mention Jinja.

This is actually a feature that's been in Jinja forever that I've always wanted in Go's text/template

http://jinja.pocoo.org/docs/dev/templates/#whitespace-contro...

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

#40

Post by aikah »

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…

> Go as a completely unnecessary move-along-now-nothing-to-see-here project

I don't like Go type system, but it handles concurrency quite nicely. It's fairly easy to learn and to use so I can see why managers chose it. And it's backed by Google so it can give a sense of safety and it can be used as an argument to sell the language. So it's a bit unfair to say it's unnecessary. It can help when performance is a concern and one doesn't want to go down to C or C++ for some reasons.

Post reply on HN