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

191–200 of 224 posts

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

#191

Post by notacoward »

cyphar wrote: post #168
notacoward wrote: post #144

Earlier quoted context omitted.

At risk of sounding like a Go advocate when generics come up, the lack of interfaces doesn't bother me because interfaces themselves are a bit of a hack. When you have inheritance, object variants, generics, and a strong template/macro system, what's left for interfaces to do? I'd much rather have all of these other things than interfaces alone.

The fact that you can create an online interface and an unrelated library (which you didn't write) can have structures that implement your interface automatically is pretty useful (and cool) IMHO.

Fair point, but much of that benefit is lost without decent support for those third-party implementations to be loaded dynamically. So Nim is missing one piece, but those other features I mentioned can get you very close to the same place. Go is missing the other piece, with no really good way to make up for it. That problem's not even solvable as long as Go's runtime makes no provision for interfacing to code that doesn't play by its own (ever-changing, undocumented) rules about things like goroutines and GC. I know which shortcoming I'd rather live with.

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

#192

Post by nvader »

GreaterFool wrote: post #186

How about adding a flag to the bloody compiler to allow me to compile my code with unused bits? I refuse to touch Go until that happens. Go is the asshole of programming languages. It forces you to put code in deeply nested annoying directories vim foo.go vim ../../../github.com/blahblah/moreblahblah/blah.go sigh But that I could live with. But constantly commenting the code out (which of course leads to commenting o…

You can use the _ signifier to mark imports as optional during development: use

    import _ "net"
Make sure you don't check such lines of code in to your repo, because there is a concrete benefit to having the language enforce this import strictness.

But the person who would check in code with unused _ imports, would probably abuse a hypothetical "allow unused imports" flag in production. Go is probably not for that person.

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

#193

Post by pjspycha »

jmgao wrote: post #182
geodel wrote: post #157

Earlier quoted context omitted.

Absolutely! They do not mean big GUI based IDE when they say tooling. Infact this is why Go will remain unviable option to .net developers. Go is likely to be much more popular among dynamic languages users and even some Java developers who are tired of enterprisey bloat.

Does go even have any good command-line debuggers? All of the things I've seen either involve insanity like preprocessing your source to inject hooks in between each line of code, or don't actually work.

Delve is an open source debugger for go. And many editors can work with delve such as Visual Studio Code. There is an animated gif of the debugger on the vscode-go page. https://github.com/derekparker/delve https://github.com/Microsoft/vscode-go

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

#194

Post by dang »

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…

> If there's a guy with the king midas touch of shit, it's Pike.

Such personal attacks are a bannable offense on Hacker News. Please don't ever post anything like this again.

Generic programming language flamewar comments are a kind of trolling and also not wanted here.

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

#195

Post by thegeekpirate »

ilya1 wrote: post #184

I'm wondering who is using Go in production outside US? Noticed couple e-commerce companies and Google itself in Singapore. Few Russian companies are doing small infra project. Anyone else seriously investing in Golang?

It's incredibly large in China (Baidu, Qiniu). I apologize since I haven't looked into countries specifically, but to respond to "anyone else seriously investing in Go?", I'll paste it here for you anyways.

Walmart, Apple, Facebook, eBay, Intel, Google, Mozilla, IBM, Microsoft, Red Hat, DigitalOcean, Zynga, Yahoo, BBC, VMware, Uber, GitHub, Getty Images, Twitter, Stack Exchange, Docker, SpaceX, Baidu, Qiniu, Imgur, CloudFlare, Bitbucket, Dell, Twitch, Dailymotion, bitly, Cisco, Verizon, Dropbox, Adobe, New York Times, HP, Canonical, Cloud Foundry, 99designs, BuySellAds, CoreOS, MongoDB, Basecamp, Rackspace, Booking, MalwareBytes, Kingsoft, Iron.io, OpenShift, Heroku, Square, Spring, Tumblr, VMWare, Symantec, Comcast, CBS, SendGrid, Digitally Imported, Pivotal, Couchbase, Koding, Shopify, Shutterfly, MaxCDN, Linden Lab, SolarWinds, IMVU, EMC, Teradata, and I'm sure many more which I'm unaware of, are all using Go to some capacity.

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

#196

Post by pjmlp »

rco8786 wrote: post #138
pjmlp wrote: post #110

Earlier quoted context omitted.

From that list I would only consider the first one. Using sun.* packages or relying in GC behaviour is a way to make Java code not portable across certified JVMs. For example I took part in some projects that were married to IBM JVM, because they were relying on its features.

> relying in GC behaviour You don't really have a choice in the matter. If you're writing high throughput or low latency applications you are dependent on the JVM's GC behavior, period.

Yes, but what I mean is that each JVM has its own list of GC algorithms.

Just as a very basic example, a certified JVM 8 is not required to have G1.

As for high throughput or low latency applications, yeah actually one is dependent on the whole stack, hence why HPFT is already moving into FPGAs.

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

#197

Post by pjmlp »

colin_mccabe wrote: post #177
mike_hearn wrote: post #173

Earlier quoted context omitted.

The first issue is surely an issue with Go as well, if they ever do change the language or std lib in a way that isn't perfectly bug-for-bug compatible? As to upgrade Go I thought you have to recompile everything including all dependencies (I guess there's no stabilised ABI?), so it amounts to the same thing: if one of your dependencies doesn't play nice with the new Go, you can't upgrade. The private APIs thing is i…

The difference is that you can upgrade each Go application to Go 1.6 separately, whereas with Java, once you upgrade the JVM, all of your applications get upgraded at once. While you could technically have two different JVMs installed side-by-side, in practice nobody actually does this because of the operational complexity and the way that Java handles dependencies. Perhaps this will become an issue for Go if people…

Actually we have deployments where the JRE is packaged alongside the application, because in some customers teams have the freedom to choose their JDKs.

However we also have projects where the Java version is married to whatever the Websphere deployment of the day supports.

And on Android, well there is no upgrade at all. Which is yet another reason to use the NDK, even with all the 3rd class developer treatment, at least the C++ compiler gets updated and doesn't depend on the Android version of the target devices.

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

#198

Post by pjmlp »

mike_hearn wrote: post #149
espadrine wrote: post #69

Earlier quoted context omitted.

You have to ensure that the GC never makes you drop a frame. For 60Hz, that means staying below 16.7ms. 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 le…

Interesting fact: Unreal Engine uses a GCd heap (or used to at least) for its core game state, so that means many AAA games use GC. And you can hit 60fps with it. Their secret is they keep the game state heap really small. Like, 50 megabytes, maybe.

They still do

https://docs.unrealengine.com/latest/INT/Programming/UnrealA...

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

#199

Post by pjmlp »

twotwotwo wrote: post #176
espadrine wrote: post #69

Earlier quoted context omitted.

You have to ensure that the GC never makes you drop a frame. For 60Hz, that means staying below 16.7ms. 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 le…

Another weird thing is, the background collection is still using a core (plus somewhat slowing foreground code, with write barriers) when it runs. It's kinda like you have a varying amount of CPU power. One approach is just to program as if you had less CPU, as if there were always a GC running. I suppose if you have some code that isn't smoothness critical (game AI, say), or CPU-affecting detail settings you can twi…

Back in the 80's and early 90's, that type or remark was intended to anyone trying to use Turbo Pascal, C, AMOS, Turbo Basic, Forth, Modula-2.... for game development.

No sane game developer would use anything other than Assembly.

The more things change, the more they stay the same.

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

#200

Post by millstone »

nvader wrote: post #192
GreaterFool wrote: post #186

How about adding a flag to the bloody compiler to allow me to compile my code with unused bits? I refuse to touch Go until that happens. Go is the asshole of programming languages. It forces you to put code in deeply nested annoying directories vim foo.go vim ../../../github.com/blahblah/moreblahblah/blah.go sigh But that I could live with. But constantly commenting the code out (which of course leads to commenting o…

You can use the _ signifier to mark imports as optional during development: use import _ "net" Make sure you don't check such lines of code in to your repo, because there is a concrete benefit to having the language enforce this import strictness. But the person who would check in code with unused _ imports, would probably abuse a hypothetical "allow unused imports" flag in production. Go is probably not for that per…

Most Go developers just use goimports. So really this "unused import" warning is a "you forgot to push the magic fix-it button." (Why didn't it push it for me?)

Or more to the point, if Go can figure out imports, why require them to be explicit at all?

Post reply on HN