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

51–60 of 224 posts

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

#51

Post by fixermark »

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.

Personally, it's replaced Python and Ruby for my web development. I like the compile-time typechecking and the ability to annotate structs and then use those annotations as direct rules for serializing data via XML / JSON serializers. The compile-time typechecking means I don't need 100% coverage to make sure I haven't typo'd a variable name somewhere.

But if you weren't using Python or Ruby for your web development, YMMV.

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

#52

Post by mwsherman »

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…

Based on Rick’s talks, this is the sort of trade-off choice one deliberately makes. Reduced throughput can be understood as amortized GC.

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

#53

Post by pjmlp »

martijn_himself wrote: post #50
pjmlp wrote: post #32

Earlier quoted context omitted.

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.

Thanks. Whilst I was aware that Unity3D was shipping with an ancient version of Mono (and more or less consequently with an ancient version of C#), I wasn't aware there were a lot of JIT/GC related complaints against it.

I have dual feelings with regard to Unity guys.

On one side they did a great job increasing the visibility of C# among game developers, which tend to only switch languages when the OS and console SDKs push them to do so.

On the other hand, they spread the feeling that C# is bad for game development among developers that don't understand "language != implementation" and take their Unity's experience as how C# implementations performs in general.

However I also should say that they are aware of it and planing to improve the situation after their IL2CPP compiler stabilizes.

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

#54

Post by deskamess »

hamax wrote: post #47
deskamess wrote: post #35

On FF 44.0: - The header is cut off - Slide 20 gives an error when running [c: template: redefinition of template "list"] - Stable sort example does not seem to work. Gives same output as regular sort

From the third slide: > Most of the code examples won't run except locally and using Go 1.6. > The playground still runs Go 1.5.

Ah... thanks. I think I rushed past the preamble slides and missed that.

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

#55

Post by aardvark179 »

pjmlp wrote: post #33
vardump wrote: post #28

Earlier quoted context omitted.

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.

Yeah, and they can collect the unreachable objects in the array when no references exist to the array itself.

From the QCon talk linked to in the slides it sounds like the Go GC is benefiting from the reduced number of objects being allocated and the fact that those objects can never move. Makes things a lot simpler if you can get away with it, but I can imagine a reference into an array, and the inability to move objects could combine in bad ways if you're unlucky.

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

#56

Post by leaveyou »

loganekz wrote: post #49
leaveyou wrote: post #34

Earlier quoted context omitted.

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

Although Go's GC is tunable to some extent, the open source HotSpot JVM are already has multiple GC implementations that you can choose based on your use case and further tune. There is also work being done in the OpenJDK project for a GC that can collect > 100GB heaps in [1] http://openjdk.java.net/jeps/189 [2] https://www.azul.com/products/zing/

From this "work being done in the OpenJDK project for a GC that can collect > 100GB heaps in https://talks.golang.org/2016/state-of-go.slide#37 https://github.com/golang/proposal/blob/master/design/12800-...

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

#57

Post by iends »

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. TypeClojure? Too obscure.

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

#58

Post by zellyn »

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…

As I understand it, you would have seen the performance hit going from 1.4 to 1.5.

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

#59

Post by mlvljr »

sdegutis wrote: post #42
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…

Yeah, you're in the minority. Technology is more or less a popularity contest. I've seen plenty of really good programming languages that simply die out because they don't have high-profile personalities behind them. And there's plenty of "meh" or even terrible languages that make it big because the hype is strong with this one. It's not great but at the end of the day, bits are bits and bytes are bytes, most program…

>> I've seen plenty of really good programming languages

Interesting, could you name some here?

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

#60

Post by softawre »

sdegutis wrote: post #42
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…

Yeah, you're in the minority. Technology is more or less a popularity contest. I've seen plenty of really good programming languages that simply die out because they don't have high-profile personalities behind them. And there's plenty of "meh" or even terrible languages that make it big because the hype is strong with this one. It's not great but at the end of the day, bits are bits and bytes are bytes, most program…

Brainfuck wants a word with you
Post reply on HN