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

131–140 of 224 posts

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

#131

Post by aikah »

notacoward wrote: post #113
iends wrote: post #57

Earlier quoted context omitted.

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…

> If you want a reasonably fast statically compiled language, what would you use? Nim. More similar to Go than most languages are to each other, but Nim has (a) more modern features, (b) better compatibility/integration with C libraries, and (c) an amazing macro system. The only thing in Go's favor is the size of its community/ecosystem, which seems to be an accident of timing and most definitely not about inherent q…

Nim doesn't have interfaces. The amount of plumbing required to implement them is ridiculous. It has generics though. My point is how can recent OO languages miss this kind of stuff when designing their type system ? Crystal looks like a better bet, unfortunately it doesn't run on Windows.

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

#132

Post by ssmoot »

iends wrote: post #115
ssmoot wrote: post #65

Earlier quoted context omitted.

Please keep in mind I may have completely misinterpreted your comment. > 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…

Sorry, I used to work at IBM and in my mind Java is WebSphere and a lot of suffering. Certainly, there are other simple ways to use the Java stack with things like Play. DropWizard, etc. But there is certainly a lot more complexity around tooling and deployments and such in the Java ecosystem than either Go or Node.js (although I can't say I'm a Java expert, so it could just be I'm just wrong).

I can totally understand that. Feels a bit unfair to paint an entire platform with the same brush if you haven't tried the more modern alternatives though.

This is a full HelloWorld web-server in Spray: http://scastie.org/14680

Play can get you to Hello World even easier:

  $ brew install typesafe-activator
  $ activator new my-first-app play-scala
  $ activator run
That's going from an off-the-shelf Mac with only homebrew installed to running your first Play app. To deploy it just run the `dist` task instead, and copy the generated .zip file to a server. Unzip it and run `./bin/my-first-app`. The only dependency you have on that system is Java.

Stick a load-balancer in front and you're good to go.

It's light-years beyond anything I've ever experienced on any other platform on the *nix side of things. Especially since it's also so much faster than any other platform I've worked with (decade old c# doesn't count).

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

#133

Post by wstrange »

rlonstein wrote: post #44
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…

> 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 has a fast VM, great tooling, a sane package management system, and a lot of deployment options. Server side libraries are still lacking, but the situation is improving.

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

#134

Post by FooBarWidget »

pcwalton wrote: post #76
dantillberg wrote: post #16

The concurrent map access checks in Go1.6rc1 have already uncovered one such bug in my code. Love it! Oh, and I've already made use of the whitespace-stripping in text templates, too! :) One thing I was worried about from the focus on reducing maximum GC pause times (i.e. latency) was that this might negatively affect GC throughput . For example, maybe the pauses are shorter but there are many more of them. The proje…

Aggressive GC latency improvements, like the ones Go is making, virtually always negatively affect throughput. For example, Azul C4 has lower throughput than HotSpot (at least per the numbers cited in the paper). There's no free lunch in GC.

But I would argue that most people who use Go, use it to write user-facing server apps, or at least server apps in which response time is an important metric. I don't know anybody who uses Go to primarily write batch jobs where throughput matters more than latency.

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

#136

Post by 15155 »

aikah wrote: post #40
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 concer…

Devil's advocate:

> but it handles concurrency quite nicely

So does Erlang/Elixir, Haskell, Clojure.

> And it's backed by Google so it can give a sense of safety

How is Dart doing in this department?

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

#137

Post by blakeyrat »

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.

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

#138

Post by rco8786 »

pjmlp wrote: post #110
kyrra wrote: post #101

Earlier quoted context omitted.

Issues I've seen with JDK upgrades over the years (that I can think of right now): * when "enum" keyword was added, if you had a variable named enum you had to rename it. * If you use any of the sun.* packages you always ask for trouble on major upgrades. * GC changes over the years can change how your program runs (latency changes, OOM issues). This probably applies to Go as well.

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.

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

#139

Post by blakeyrat »

iends wrote: post #57
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…

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…

Great tooling? Does Go have any quality IDEs with integrated debuggers yet?

I feel that open source developers mean something entirely different with the phrase "great tooling" than developers used to Visual Studio would mean. :)

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

#140

Post by tossableacct11 »

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

So I wondered that as well and did some Googling.

Found a blog post by Joel Webber, who I have not heard of, but he was working on a minecraft clone and had some advice on avoiding GC and memory layout:

http://www.j15r.com/blog/2015/01/25/Game_Development_in_Go

Also found an engine, Azul 3D, and they made this claim:

https://azul3d.org/doc/faq.html#what-about-the-garbage-colle...

Then there is termloop, which is a terminal based engine:

https://github.com/JoelOtter/termloop

Fun for indie game stuff.

So, yeah. There's that.

Post reply on HN