The State of Go: Where we are in February 2016 • Hacker News Board

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

#221

Post by BuckRogers » Fri, Feb 05, 2016, 10:08 AM UTC

wstrange wrote: post #133

rlonstein wrote: post #44

Earlier quoted context omitted.

> Am I in the minority to think of Go as a completely unnecessary move-along-now-nothing-to-see-here project? Ignoring your broadside of insults, I keep asking myself the same thing after working with it: What is so compelling about Go? It's better than C, but we already have good choices in that area. I feel like there's a bandwagon effect around the language.

I see Go as having a nice niche for "systems" code that is above C, but more low level than say python. I think that is why we see it used in docker, kubernetes, etc. The ability to distribute binaries is quite handy for containers. I am surprised that people want to use Go for web apps though. For whatever reason, Dart seems unpopular with the HN crowd, which is shame because it is a super productive language. It ha…

> I am surprised that people want to use Go for web apps though.

This. I'd put it under consideration for where I'd pick Java (an increasingly limited space now for myself), but I really do not think it competes directly with Python/Ruby or C-ABI compatible compiled languages like Rust. It's on an island like Java. As a result, you're going all-in with Go, but netting a much smaller ecosystem than Java's. I prefer to not go all-in with either.

If I were to reach for Go for webapps, I'd be just as if not more inclined to look at Swift as it matures.

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

#222

Post by mike_hearn » Fri, Feb 05, 2016, 1:04 PM UTC

colin_mccabe wrote: post #212

mike_hearn wrote: post #207

Earlier quoted context omitted.

Experience with C/C++ is exactly why people tend to value compaction. I've absolutely encountered servers and other long-lived apps written in C++ that suffer from heap fragmentation, and required serious attention from skilled developers to try and fix things (sometimes by adding or removing fields from structures). It can be a huge time sink because the code isn't actually buggy and the problem is often not easily…

Well, I can only say that your experience is different than mine. I worked with C++ for 10 years, on mostly server side software, and never encountered a problem that we traced back to heap fragmentation. I'm not sure exactly why this was the case... perhaps the use of object pools prevented it, or perhaps it just isn't that big of a problem on modern 64 bit servers. At Cloudera, we still mostly use CMS because the v…

Ouch, not even upgrading to JDK8? That's not really a new JVM anymore now.

G1 has improved a lot over time. What I've been writing was based on the assumption of using the latest version of it.

Yes, full stop-the-world GCs are painful, but they'll be painful in any GC. If Go runs out of memory entirely then I assume they have to do the same thing.

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

#223

Post by bshanks » Fri, Feb 05, 2016, 5:36 PM UTC

What do people think of Go's new(ish) vendoring?

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

#224

Post by blakeyrat » Mon, Feb 08, 2016, 7:45 PM UTC

blakeyrat wrote: post #137

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

There are a heck of a lot games written in C#, which is not only interpreted, but probably has a less-tuned GC. Including heavy-processors like Kerbal Space Program. If KSP works in C#, you can write a game in Go no problem.

Did I get down-voted because some OTHER person started a dumb argument about interpreted vs. compiled in my thread? Awesome.